From Open(?) Source(?)
Jump to navigation Jump to search

About this worksession

During this session we will be doing a collective exploration of the Fediverse (federation+universe) through discussion, hands-on workshops and speculative writing.
The architecture behind the Fediverse is a decentralised network of servers running open-source, social networking software. In contrast to the centralised infrastructure of corporate social networks, the federated social web lives and communicates across a variety of servers running several types of software.

This model has implications on various levels: privacy, social, political, economic, cultural etc. Together we will dive into these issues and (re)imagine the potential of alternative social media.

Link to pad of the day: https://pad.vvvvvvaria.org/fediseminar-091220

What is the Fediverse?

Centralized, Decentralized and Distributed Networks

Fediverse - portmanteau for the words "Federation" + "Universe"

The architecture behind the federated social web is a decentralised network of servers running open-source, social networking software.
In contrast to the centralised infrastructure of corporate social networks, the federated social web lives and communicates across a variety of servers running several types of software.

Different communities create and maintain instances with their own set of rules and ideals. Users can thus choose not only which software but also which instance best suits them. Many of these software projects and instances are actively investing time into rethinking governance models, inclusivity, accessibility, participation and codes of conduct that underline anti-abuse measures.

The development of the federated social web is an ongoing process, with many unanswered concerns, unsolved complexity, nuances, discussions, debates and disagreements. As the existence of alt-right Mastodon fork gab.com proves, the federated social web is not an inherently emancipatory project.

Further reading

How does the Fediverse work?

Fed Up! poster developed by Lídia Pereira, Artemis Gryllaki and Bohye Woo. Large version.

Each software (e.g. Mastodon, PeerTube, PixelFed) may run on as many servers (instances) as there are communities willing to install and maintain them. Inter-communicability between them is achieved through the implementation of one or more communication protocols (e.g. OStatus, diaspora, Zot and ActivityPub). To communicate, software projects need to share at least one communication protocol.

Case study: ActivityPub

ActivityPub is a decentralised social networking protocol published by the W3C Social Web Working Group. It is an official W3C recommended standard that provides both a server-to-server federation protocol for delivering notifications and subscribing to content and a client-to-server protocol for creating, updating and deleting content.
For its vocabulary, ActivityPub uses ActivityStreams, a specification which represents potential and completed activities using the JSON format. Within the context of ActivityPub, these activities refer to social networking interactions. In ActivityPub, a user is an "Actor" and has both an inbox, in which they receive messages, and an outbox, through which they send messages.
For example, user Justin wants to send user Britney a message. The message is POSTed to their outbox. Here's how this action might look like as an ActivityStreams object:

{"@context": "https://www.w3.org/ns/activitystreams",
"type": "Note",
"to": ["https://chatty.example/britney/"],
"attributedTo": "https://social.example/justin/",
"content": "What is your opinion on denim?"

Further reading:

How large is the Fediverse

Screenshot of Fediverse visualization fediverse.space

15 Protocols
51 Projects
8463 Nodes
4,094,915 Users

Further reading:

What is the history of the Fediverse?

The history of the Fediverse is complex and full of nuance. Here is a short summary we have compiled to the best of our abilities:
According to a "People's History of the Federation" and "A Quick Guide to the Free Network", this is an history that begins with the StatusNet platform being established around 2008. The protocol implemented in order to achieve communication between servers and projects was OStatus. Eventually StatusNet split into pump.io and GNUSocial, the latter which was forked into postActiv. In 2016, the now popular microblogging project Mastodon joined the Fediverse game.

Running parallel to these developments, the macroblogging social network Diaspora appeared in 2010. While Diaspora has its own federation protocol (diaspora), macroblogging social networking projects such as Friendica, Hubzilla and Socialhome have also implemented it. Of these, Friendica and Hubzilla have also implemented the OStatus and ActivityPub protocols.

Nowadays, the Fediverse is expanding as more and more of these projects are implementing ActivityPub as one of their federation protocols. However still limited by how the protocol is implemented by the project's developers, these developments allow for the federated constellation to grow and promise to offer users a bigger choice, not only regarding which software to use - Pleroma, Mastodon or both? -, but also regarding which instance/s (i.e.: servers running the software) to sign up for.

Aymeric Mansoux and Roel Roscam Abbing write in their Seven Theses On The Fediverse and The Becoming Of FLOSS

Earlier attempts to create federated social media platforms came from Free/Libre and Open Source Software (FLOSS) communities. They traditionally had an interest in providing libre alternatives to existing closed source and proprietary software. As such, these projects were originally promoted as similar in function to the corporate platforms but made with FLOSS. As they were mostly articulated around the openness of protocols and source code, these software platforms catered to a limited audience of users and software developers, who were largely concerned with issues typical of FLOSS culture.

Further Reading

Social understanding of privacy

According to Aymeric Mansoux and Roel Roscam Abbing, the Fediverse is moving from a technical towards a social understanding of privacy. What this means, is that instead of putting their focus on solutions like E2E encryption, Fediverse communities place more of their attention on the development of strong moderation tools, granular options for post visibility, content warnings, the possibility to block other instances (i.e. gab.com, the alt-right Mastodon fork). Many of these features have been proposed and developed by the members of historically marginalized communities who see in the Fediverse an opportunity to create safer spaces that cater to different needs of diverse groups.

Trust is an important concept to keep in mind in this context: although most Fediverse servers use encryption during transport of users' messages, server administrators have the ability to read them should they choose to do so.

Furthermore, while most Fediverse instances are against the business model of corporate social networking platforms, which centers around the processing and selling of user data in the form of tailored audiences, nothing prevents third parties from scraping and monetizing publicly accesible data on the Fediverse. Nonetheless, this also means that, provided you trust your instance, there should not be any internal processing and monetizing of your private data and metadata on the part of your instance's administrators.

The topic of privacy is complex, and the discussion on social and technical solutions continues. For the most part, Fediverse communities recognize that privacy needs much more than a technical fix, and they respond to these concerns by developing social-based means of ensuring protection.
As was mentioned in the Feditation video by Lídia Pereira, this is how the radical potential of the federated social web expands beyond its technical infrastructure. Many of its earlier inhabitants, belonging to historically oppressed minorities, found within the federated social web a promising safer alternative to corporate social media, whose scale and profit-driven business model will never offer enough protection to their most vulnerable users.


Fedidrama (or Fediverse drama) can start like this:
- “Person A said something racist!”
- “Person B is transphobic!”
Before you know it, an argument between 2 people spreads into branches and threads, escalating so much that it's impossible to ignore. The bad old internet arguing behaviours seem to continue with glory, also in the Fediverse.

Sometimes, it’s initiated by a difference in beliefs or values: something as innocuous as preferring Captain Kirk over Captain Picard could turn into an arduous holy war between two frustrated grown-ass adults.
(Sean Tilley, 2020, ''Understanding Fediverse Drama'')

The tiring process of endless flaming leads people to log on a lot less or decide to leave an instance (or even the Fediverse). Flame wars can also lead to a total division between two communities. The drama has not only to do with a disagreement between ideological values and identities but often carries tales of past drama between factions. In the race of winning the battle, opponents may organise raids, hang screenshots of old misbehaving in old forums etc.

Every instance with a number of users can be regarded as a community. Thus, the huge division and sometimes incompatibility in identities, values and urgencies among instances is logical.

Many of these communities have their own characters, mythos, and power symbols to tell a story about who their leaders are, and those stories are revised and redistributed by people of all sorts, in positive and negative ways.
(Sean Tilley, 2020, ''Understanding Fediverse Drama'')

A lot of users have left platforms like Twitter, or Facebook, to find online spaces that can host more fruitful conversations, trust and security. Apart from all the achievements of the Fediverse, such as the diversity in content, software, servers, and the intercommunication among instances, the ways people behave online has not radically changed.

How can Fedidrama be avoided? Probably it is inevitable to have some drama in every online community (leading to silencing, blocking etc). However, there are some points of improvement:
-Tooling: building (and improving) tools to filter what everyone can see or don't see when joining an instance, seems crucial. The ability of users to partially control their timelines could help diminishing drama situations.
-Policy: successful federation among instances is possible when they share a base of similar values. Having an agreement on what behaviours are acceptable and what aren't, helps interconnected communities to collaborate and support each other.
-Administration: can help ensure that the agreed policies are enforced. The work of moderators is to deal with complaints and reports or to take measures to protect members of a community before a bad incident happens (e.g. communities vulnerable to harassment).
-Individual behaviour: When talking about self-organised communities, it is always helpful to bring empathy, understanding and patience on our interactions. Peoples ideas are not monolithic, so no-one should expect to agree on every point with others.

Further Reading


Open-source projects often follow specific 'governance models'. What this means is that they operate according to rules and processes that determine how contributions happen, why and by whom. There are several governance models in use in open-source, among which are 'do-ocracy', founder-leader (aka Benevolent Dictator for Life), corporate-backed, foundation-backed, etc.

The most engaged users on the Fediverse not only engage with reporting bugs, but are also starting to inspect and contribute code, engage in discussions and suggestion of new features, etc. Increasingly, Fediverse communities are challenging conventional governance models. The consequence is that, according to Aymeric Mansoux and Roel Roscam Abbing,

"(...) several long-standing FLOSS projects have been pressured to adopt accountability structures and migrate to community-oriented forms of governance such as co-ops or associations."

In his contribution to the "Fed Up!" issue of the Pervasive Labour Union, Funkwhale's main developer, Eliot Berriot, wrote: "Alternative tech in itself is required, but not enough to build an alternative service". According to Berriot, failing to acknowledge the importance of governance models and not engaging with the extrinsic/intrinsic power structures within a community project could possibly mean that federated alternatives are not sustainable in the long run. To illustrate this point, the Funkwhale developer communities are signatories of the Post-Meritocracy Manifesto, a document putting forth constructive proposals to move beyond the meritocratic model, one of the founding principles of the open-source movement. Meritocracy has consistently shown to benefit those with privilege, in detriment of underrepresented communities in technology. This is why the Manifesto asks: 'What does a post-meritocracy world look like?'

Further reading:

The Post-Meritocracy Manifesto
Understanding Open-Source Governance Models (Red Hat)

Codes of Conduct

To manage a community, and even more, an online one is a difficult task. It requires both a collective understanding of how people wish to co-exist and interact together, as well as finding ways to deal with conflict. Today most Free/Libre and Open Source projects have adopted a Code of Conduct, in order to define and apply informal rules to their networks. CoC can be published as user guidelines, community rules, collaboration protocols, community covenants, group pacts, collective agreements.

CoC aim to help the interaction between members of a community. They set expectations for users, stating the values of a group, declaring which behaviours are allowed or discouraged. CoC are very different from Terms of Service, as they are non-legal documents. They are community approaches that deal with internal and exterior malpractices, related to different privileges, power positions and experiences of diverse users.

CoC don't follow specific views on morality, on the contrary, they can be highly diverse.

  • ComicsCamp.Club is a Mastodon instance focused on art, comics and narratives. Like most Mastodon communities, there is a Code of Conduct that sets guidelines for user-behaviours. The CoC of this instance reminds the members to participate in a positive or supportive manner, critique work only when requested, it provides advice when a discussion becomes hostile etc. According to one of the administrators of ComicsCamp.Club:
Codes of Conduct are definitely a common practice on Mastodon, due to the nature of many different communities and people trying to curate their own experience.
(Interview conducted by Rita Graça for the research project Networks of Care, 2020)
  • CounterSocial is a fork or heavily customized deployment of Mastodon, that blocks entire countries, such as Russia, China, Iran, Pakistan or Syria. This instance asserts that blocking countries aims to keep their community safe by not allowing nations known to use bots and trolls against the West. This may appear as a dubious approach, but inside Mastodon, each community is independent to create their guidelines, choosing who to invite and block from their network.

The consequences of not following a CoC are also decided by the community. They are usually dealt with in private, with moderators making use of warnings, blocking, banning. While some groups have zero-tolerance policies, others take on more forgiving proposals – “If the warning is unheeded, the user will be temporarily banned for one day in order to cool off.” (Rust Programming Language, 2015).

Codes of conduct are not only documents but labour intensive routines that imply human effort and involve the community. For actual interventions to happen, people need to constantly interact with the written rules. The bodies gathered around Codes of Conduct are responsible for activating and enforcing them (Snelting, 2018).

Examples of CoC

Further reading

Examples of Projects


The Green Fediverse is a project whose goal is to raise awareness about the sustainable development of the Fediverse. One of its most notable efforts is the development of a list containing all the available green instances, as a way to promote them.

Relevant links:

Federated Networks Association

The Federated Networks Association (Feneas) is a non-profit organisation registered in Finland. Feneas aims not only to spread knowledge about the federated social web but also to financially help the communities and projects involved in its development.

Relevant links:

Discover different software

Screenshot from https://fediverse.party/

Extra Reading


Hands-on workshop (Activity 1)

Imagine your own (Activity 2)