the scapegoat dev

Developing for the fediverse: some personal guidelines


Moving to Mastodon

One of my resolution for 2023 is to write software for the fediverse.

Many things changed for me in 2022—one of the most positive developments was that I started writing opensource software again. I also came back to Twitter after a decade off social media, found some incredible people and content, and migrated to right before things got crazy. I can't appreciate the effort the hachyderm crew is putting into their mission enough.

There have been a tremendous amount of heated debates in the few months I've been on mastodon: around content warnings and alt-text, the lack and importance of quote tweets, the technical leadership of the mastodon project, the dissonance between "oldtimers" and "newcomers," the whiteness of the Fediverse, the sizes of instances, the politics of defederation, the role of commerce and professional networks... It is all so LOUD and ANGRY and LOUD LOUD LOUD ANGRY ANGRY, and I can't think when things are LOUD and ANGRY.

To feel confident enough to contribute software in such a fraught environment, I needed to do a lot more research. My brain needs to derive what I will work on, starting from first principles. I have to think and reflect and refine and write and communicate to gain the clarity I require before I put pen to paper and IDE to source code.

This is the first blog post in what I think will be a very long series. As I took notes this week (I am slowly entering them into my obsidian vault), it became clear that I had too many ideas, too many holes in many knowledge, too many questions to ask. I have repeatedly started drafting blog posts that tried to cover everything I wanted to address, but I was getting nowhere. Instead, I will follow some advice I got recently: "just write and publish. No one cares about your blog anyway," and see where things go.

This first article examines what I think needs to be at the forefront of my work for the Fediverse: the users. From there, I hope to derive some concrete product design principles, as well as more concrete ideas of things to build and in what order.

Please note that what follows might sound at times like prescriptions—rules I would want to establish or behaviors I would like others to adopt. They are not—I am only speaking for myself. I often use "we" as a pronoun because I know that my contributions as a developer will not exist in a vacuum and that I will operate as part of a community. What that community will look like is still very unclear to me.

Furthermore, this is a work in progress; I expect future revisions as I find my way through past discussions, political and philosophical texts, culture studies research, existing source code and technical talks, standards, and other documents.

Building convivial tools

I am a search, tools, and backend nerd. Currently, I work in retail, building backend systems for fulfillment, purchasing, selling, customer support, inventory management, content management, marketing analytics, and so forth. The software I design and build impacts many people's daily lives. I think that searching, archival, distribution of data, and automation of intellectual work are some of the most impactful, transformative affordances that computers have brought to humanity.

While the company I work for operates within the context of capitalism, it is self-owned and bootstrapped; the work-life balance is excellent, and as the principal engineer and a close friend of the owners, I have a lot of leeway in technical leadership. Leaving aside the fact that the capitalist system is alienating by definition (a topic I am not competent to talk about), there is still a lot of room within it for designing more humane software (in fact, the fact that the system is inherently alienating puts an onus on developers, the ultimate cogs in the technocratic oppression machinery, to operate very carefully and consciously exercise their privilege).

The software I am interested in writing for the Fediverse centers around:

As you can imagine, these are touchy subjects.

I have always loved building software for users, but it is only recently that I started formalizing what that entailed. Every system we build (as developers) impacts humans in some way (we wouldn't build it otherwise). I call these humans users, for lack of a better term. Building and designing software should, from an ethical perspective, respect a user's rights. That is quite hard for me to formalize, so I boil it down to "make their lives better in a way that they can communicate with me." Only through communication with users will I know if I am building something good.

To improve people's lives, software shouldn't just make specific tasks easier (I am focusing on practical software)—it also needs to enhance a user's agency—not diminish it. Users should feel that they have been listened to, understand what the system is doing and that they can control it. A recent book I have been reading that showcases these principles in a supply chain context is Augmented Lean by Natan Linder and Trond Undheim.

While I am not knowledgeable enough (for now!) to properly study Ivan Illich's Tools for Conviviality, the concepts I have gathered from my various attempts at reading it seems to align with what I am trying to express.

A federation of users

Building software for conviviality, for the user, is not just the right thing to do; it is also a powerful engineering principle. Building something that doesn't make things better for users is usually a wasted effort. Furthermore, building a lousy product usually leads to even more misguided projects to fix its inadequacies.

Now, this all sounds great, but what does that mean?

It means that before thinking about features, APIs, protocols, programming languages, and even UX design, projects need to be centered around the user. This means that we have to start by identifying who the users are, what they want and how they will be impacted.

In the context of the fediverse, I am keeping a list of all the possible users I can think of. Here are some key users:

Note that these are "user roles." A single individual is a combination of any of these user roles, and the roles they embody can change over time. Furthermore, there are a lot of subdivisions here, which again overlap in various ways. You can communicate primarily with your group of friends; you can be a member of multiple communities; you can be a marginalized user that faces discrimination; you can be active in a professional context. You can be a mobile client developer, a project maintainer, a library developer, or involved in the design of protocols. At an even lower level, each individual has preferences, political views, opinions, and abilities.

Each of these roles can be empowered or harmed by:

I think that the Fediverse is a unique design landscape because features here are much broader than just software features. Because it is a global social media platform, the design landscape involves codes of conduct, moderation guidelines, DevOps practices, community practices (hashtags and quote-toots, for example), bug trackers, forums discussing new features, media reports, research, cybercrime, commercial use-cases, etc... Furthermore, it is a gigantic system (in the systems thinking sense), a fractal network of networks, full of feedback loops and just ready to create emergent behavior. If we learned anything from the past decade, it is that social media is not trivial.

In the fediverse, everybody has responsibilities

This also means that to respect everybody's agency, every individual has to shoulder a set of responsibilities, not just developers.

Here are a few of them I can think of:

Finally, there will always be different (and sometimes conflicting) ideas of what the fediverse should be. That is both its strength and its biggest downside. These conflicts were quite apparent in the debate around quote tweets. To productively discuss the evolution of the fediverse, there needs to be an understanding that the goal should be for many solutions to cooperate, not figuring out the one true and only way. Anybody who worked on a standards committee, in fact, anybody who worked on a project with more than one person, will know that to reach a consensus, compromises have to be made. And by definition, compromises are going to leave everybody dissatisfied; the goal is to make everybody just happy enough to stay on board.

What's next

Now that I have laid out who I think the users are, I will focus on what user-centric product thinking for the Fediverse could mean concretely. I also hope to start interviewing different users (moderators, individual users, developers) to understand how others use (or want to use) the Fediverse in general and mastodon in particular.