Developing for the fediverse: some personal guidelines
TL;DR
- I am outlining a set of personal guidelines for the Fediverse software I want to write in 2023
- This is the first entry in what will become a long series of blog posts
- Users should be at the center of every technical decision
- Users mean not just people using Mastodon for communication but everybody involved: administrators, moderators, community leaders, committees, institutional and commercial users, developers, activists, researchers, etc...
- I would love to hear some feedback! I am @mnl@hachyderm.io
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 hachyderm.io 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:
- discovery (both of users and content). This means searching and archiving content, along with algorithms for timeline organization (discovery of users, messages and communities)
- tooling for managing one's data. Here again, I am interested in archival and searching, as well as tools to control how far user-created data spreads (filtering rules, blocking users)
- tooling for moderation (archival, searching, filtering, blocking, you got it)
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:
- individual users
- moderators
- administrators
- instance "owners"
- developers
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:
- implementing (or not implementing) new features
- maintaining (or not maintaining) existing features
- deploying (or not deploying, or rolling back, or not rolling back, or deploying too quickly) new features
- documenting (or not documenting) new features
- communicating (or not communicating) about new features (even before they are built)
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:
- Developers are responsible for the following:
- individual users (UX, accessibility, allowing them to migrate, making anything related to data agency opt-in)
- instance admins (proper release announcements, not rolling out security fixes along with new features)
- other developers (building welcoming developer communities, compatibility towards other projects)
- moderators (not building features that will significantly increase moderation workload, not providing necessary tools for proper moderation)
- Instance admins are responsible for the following:
- individual users (provide a minimum quality of service to allow users to have agency over their data and social network, for example, backup, deletion, migration)
- moderators (communicating about instance status, new software rollout)
- developers (providing meaningful bug reports and feedback, being actively and productively involved in release management and quality assurance)
- All users are responsible for the following:
- being good citizens (not harming other people, basically)
- being respectful of admin/moderator/developers' time and effort (providing good bug reports, being respectful and understanding of developer's time). These people are humans. They have a right to their mental health; they have a right to make mistakes; they have a right to have a different opinion; they have a right not to know everything.
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.