the scapegoat dev

Developing for the fediverse: individuals' fundamental rights



This is the second post in my series about [[Developing for the fediverse]], in which I try to lay out a series of personal guidelines for writing software for the Fediverse. Please read the first entry in which I explain why I want to center my work around users and who these users might be:

In this second entry, I derive a set of fundamental rights individuals using my software should have.

Please note that most of these topics are new to me and that I only speak for myself. I will undoubtedly revise these guidelines as I gain better knowledge and experience. I also use the term we at times, which might imply that I propose guidelines for others to follow. This is not the case—I use we because I know that my software won't exist in a vacuum, and I hope that people will contribute.

An individual's fundamental rights

While I was centering "users" in my previous article (which could maybe better be understood as "user roles"), the rights I am outlining here are centered around individuals—an actual person interacting with the Fediverse. An individual can hold a lot of different user roles: they could be participating as a private person, an instance administrator, and a community leader. While these different user roles come with varying responsibilities and prerogatives, individuals' rights take priority in all cases. I will use "user" and "individual" interchangeably for the rest of this text, as I will rarely use the product design concept in this article.

As with any definition of rights, this quickly gets complicated. While I wish, as a programmer, that I could establish clear, unambiguous rules that can be checked, this will always be more of a set of guidelines than a list of points to be checked off.

Agency over one's data

The most important right in the Fediverse is an individual's agency. By agency, I mean the right to give informed consent and to withdraw said consent at any point.

User should have agency over:

One of the most immediate problems the Fediverse currently faces is that it is hard to understand what happens with one's data. I gave up on understanding what replies, hashtags, and direct messages I am seeing and when despite having experience with building distributed systems. Should I include a reply in this thread because A follows B, but no one on my instance does? Or is it because instance C has backlogged sidekiq queues? Or maybe D has been defederated without notice... Is this hashtag used? Or has no one on this instance followed community members using it yet?

If a user cannot understand how a system works, they won't be able to give informed consent to any of its conditions.

A user should be able to understand, with confidence:

This doesn't mean it is the role of developers, instance administrators, and moderators to cater to an individual's every wish. It means that a user should, at any point in time, understand how their instance operates and consent to it. As a developer, this means that I can't just push new features that would undo agreed-upon terms, but instead should build it so that users can opt-in at their leisure. When features that impact these rights are introduced, users should be given enough notice to opt out (or change instances).

Agency over one's social network

While it is reasonably easy to understand what "data" means, defining an individual's social network is much more complicated. It stands for what an individual uses the Fediverse for. Some people use the fediverse to be part of a community (for example, I use the Fediverse in part to participate in the #ActuallyAutistic community). Some people use it to stay in touch with a close group of friends. Some people use it to follow artists and content creators because they enjoy their content. Some people use it to further their professional network. Some use it for activism. All of these uses are valid and should be encouraged—they can coexist as long as an individual's agency is not impacted.

Individuals have the right to maintain their social network even when withdrawing consent they previously gave. This means that a user should be given enough notice in the case of defederation, moderation, software changes, or guidelines changes to maintain their follower list and preserve the data they created. It also means explaining why members of a user's network might not be reachable anymore, either due to defederation, software incompatibilities between instances or clients, or technical issues...

While it might not be a big deal for techies accustomed to the vagaries of distributed systems, missing out on the hot topic of the weekend that all your buddies are joking about (because you didn't know your instance's queues were backlogged) is going to be a problem for my non-technical friends.

When considering new software features, what one's agency over their social network exactly entails quickly becomes muddy. Social media's "social" impact is emergent, and new features—or even slight UX changes—can profoundly impact its entire social fabric. This is the source of heated debates (one just needs to consider the discussion around quote-toots, search indexes, and timeline algorithms). Because people have different opinions on how to use the Fediverse, and because the Fediverse, by definition, is a public good, we must find ways for different feature sets to coexist while preserving a user's agency over their social network.


Some of these differences will be impossible to reconcile, at which point instances will de-federate. De-federation is the fundamental mechanism that allows the Fediverse to function as a decentralized network. It makes it possible to hold instances accountable to the rules they proclaim to enforce. If a new instance openly announces rules incompatible with another instance's choices, it will get blocked immediately. However, suppose an instance announces compatible rules but does not enforce them consistently (or at all), either because it is acting in bad faith, because of bigotry, or purely because it is not run competently. In that case, it can be threatened with de-federation (and ultimately blocked).

However, de-federation profoundly impacts users of an instance because it disrupts their social network. For example, it took me a few weeks to realize that some friends I was following weren't just silent but invisible because their instance defederated from mine, a fact neither they nor I was aware of. We just wouldn't read each others' toots, even though we were replying to the same threads (!). To give users agency (I want my messages to reach these people) and preserve their social network (having friends vanish is pretty disruptive and unacceptable to most people), de-federation needs to be more transparent.

Users should be given a heads-up that their instance will be de-federated if only to allow them to decide to move (instead of them one day realizing their social network got disrupted). These decisions can profoundly impact people's lives and disproportionately affect those who rely on social media to be part of a community.

What's next

In the next post, using these rights as a guiding principle, I will examine the concrete design constraints they could entail by running through a few potential feature ideas.