Decentralized Social Networks

Comparing federated and peer-to-peer protocols

Jay Graber
Stories from the Decentralized Web
9 min readJan 9, 2020


Or, centralized, federated, and peer-to-peer

Efforts to decentralize social networks hope to structurally change the balance of power in favor of users by giving them the ability to change services easily and control their identity and data. Calling a network “decentralized” only defines it by what it is not — it is not dependent on a single set of servers run by one company. What it actually is can look like many different things. Federated and peer-to-peer (p2p) protocols are different approaches to designing networks that structurally empower users.

Traditional social applications like Twitter, Facebook, and Instagram operate on a client-server model. As the user, all your interactions go through a single company’s servers. In a federated network, users are still interacting with a server, but anyone can run a server that interoperates with others in the network, giving users more providers to choose from. In a p2p network, there is no distinction between clients and servers. Every user’s device can act as both, making them functionally equivalent as peers.

This post will provide an overview of some of the most popular federated and peer-to-peer social network designs. I’ll dive into detail on ActivityPub and ssb, and cover how their main implementations address the hard problems of identity, moderation, and monetization. A quick comparison to Matrix and Aether will describe how some alternative approaches work. At the end of each section I’ll list the main pros and cons of federated and p2p models. Blockchain-based social networks will be addressed in a follow-up post.

Federated protocols

Federated networks let users pick a server to sign up with, which gives them access to the entire network spread out across many different servers. This gives users more choices for applications, policies, and community cultures. Email is an example of a federated protocol that everyone on the internet uses. Gmail is a popular email application, but if you use a different provider you can still communicate with anyone with an email address.


ActivityPub is a federated protocol that defines a set of interoperable social network interactions through specific APIs. Any server that implements this protocol can communicate with the rest of the network.

Mastodon, built on ActivityPub, is a popular federated alternative to Twitter with around 2.2 million users. Prior to Mastodon, projects like GNU social and Diaspora tried and failed to get federated social networks to scale. Mastodon succeeded in large part because it created a familiar user interface that looked and behaved like Twitter, allowing users who were dissatisfied to find a new place to land with minimum effort.

Home feed on Mastodon


Users create an account on a server (an “instance”), but can communicate with users on other instances. The entire constellation of instances that can interoperate is called the “Fediverse”. A full username is a user’s handle plus the name of the instance the user belongs to, for example: 

Account credentials are managed by the user’s instance, so if users forget their password, they can ask for a password reset.


Each instance sets its own moderation policies, either through the unilateral decisions of an admin, or through some sort of collective vote. Admins can ban entire instances, cutting off their visibility. If an instance gets banned by many others, its users can still talk with each other, but they will be isolated from the rest of the Fediverse. This happened to, which set up an instance.


Federated social networks require both hosting and development costs to maintain. Each instance is funded by its own administrator and community. Mastodon’s development is funded through a Patreon run by the main developer. It currently brings in about 70k a year, which supports him working on it full time, and covers hosting costs and a moderation team for the instance.

Another federated protocol: Matrix

Matrix is a protocol designed more for chat than for social networks, but it is worth mentioning because it has achieved a federated chat experience with good UX at scale, and has done valuable work on improving identity and moderation. The protocol currently has around 11 million users who use a variety of clients. It is developed by the company New Vector which raised an $8 million series A in 2019. Matrix has a more flexible identity solution than most decentralized protocols — users have a Matrix user id, but can also use 3rd party ids. A Matrix account links to ids such as email addresses, social accounts, and phone numbers. A globally federated cluster of trusted identity servers verify and replicate the mappings. The Matrix team has also been working intensively on tools for moderation, detailed here, and plans to release a p2p implementation soon.

Pros and Cons of Federation

Federated networks provide a familiar user experience, since users do not have to bear full responsibility for their account credentials, and can interact with content the way they’re used to. Users get to choose between different services in the same network that suit their needs better without having to adapt to a drastically different way of doing things.

Yet federated servers also inherit some of the same downsides as centralized servers. Servers are dependent on admins who are usually individuals or organizations with fewer resources than large social media companies. Server admins might abuse their power or shut down the service because they can’t keep up with costs. Governments that block access or demand backdoors to centralized services could easily do the same to federated servers. Depending on the implementation, user identities may be bound to servers, which means users lose their connections and data if they migrate. Privacy protections vary — Mastodon does not currently encrypt content, so all messages, including private ones, are potentially visible to the server admin.

P2P protocols

P2p protocols let users communicate directly with each other, as all devices in the network are peers, both requesting data and responding to requests. Some nodes may have special roles, like public bootstrap nodes that help new users get connected to the network, but every node is still functionally equivalent. This design gives users the most control, but also the most responsibility.


Ssb, or secure-scuttlebutt, is a distributed gossip protocol designed for social sharing. Every node has a partial view of the network, which makes it hard to get a count of how many total users there are, but according to a network crawl run by a developer in Nov 2019, there are around 16,000 nodes on ssb. Users are distributed across a few different client apps that work on desktop (Patchwork) and mobile (Manyverse, Planetary).

Home feed on Patchwork, a desktop client for ssb

Every user has a public/private keypair which is used to sign posts, verifying their authenticity. Each post is appended to the last, in an append-only log establishing chronological ordering from the very first. Because every post is chained to the last, there’s currently no way to delete or edit posts. When you follow a user, you will begin to store and sync their posts. An ssb application is constantly sharing data with other nodes in the background while you use it.


In ssb, users are identified by public keys. My public key is:


Users can pick a human-readable nickname that is associated with their key, but nicknames are not unique since there is no global registry. Others can mention me by my nickname @arcalinea, but someone else could also use the same name.

Key management is one of the biggest challenges, as users inevitably lose and forget their passwords. Users are in complete control of their identity. That means if they lose their cryptographic key, they can permanently lose access to their account. Keys are also currently stored on devices, which makes it impossible to sign in to one account across multiple devices — a basic feature of social networks users have come to expect.

To attempt to address the problem of key management, a project in the ssb ecosystem, Dark Crystal, has implemented a social key recovery system. It splits keys into shards to store with family and friends who can be trusted to help reconstruct a lost key.


At the ssb protocol level, there is a “flag” feature to send a strong negative signal about bad actors. There is no global moderation, and no specialized moderators. Applications built on top of ssb allow users to “block” and “ignore”. A block in ssb functions more strongly than a block in centralized networks because it means that blocked users no longer have their data passed through those nodes. If enough people block a user or group of users, their part of the network will become cut off from the rest.


Maintainers of p2p networks do not have to pay for hosting costs, since there are no servers and the network naturally grows in capacity as new users join. Developers who want to work on more than a volunteer basis need to find their own funding. The ssb ecosystem is supported through a variety of grants, donations, income from side projects and consulting, and a few companies that have raised money to build applications on ssb.

Another p2p protocol: Aether

Aether is a Reddit-like p2p social network. Instead of an append-only log, its data structure is a DAG (directed-acyclic graph), and it makes posts ephemeral. You can edit and delete posts, and they automatically get dropped after a period of inactivity, unlike ssb, which stores every post. The p2p version is supported through funding from the self-hosted Aether Pro version. It has a strategy for multiple device logins — you can store and sync encrypted keys from a remote backend. Each sub-community has its own moderators, which communities elect or impeach themselves.

Pros and Cons of P2P

P2p networks place users fully in control of their data and identity. The data layer is functionally separate from the application view, so users can seamlessly switch between apps while keeping all their accumulated posts and connections. The capacity of p2p networks naturally scales with demand, since new users add resources to the network and don’t just consume. P2p networks are maximally resilient and censorship-resistant. Because p2p networks don’t need servers, applications can continue working even if the rest of the internet is down, as long as there is a local connection between two devices on the network. Accounts all have cryptographic keypairs, so private messages are easy to support — ssb provides end-to-end encrypted private messages.

However, the flip side of control is the burden of responsibility. There’s no service that can help recover a lost or stolen password. Moderation relies on bottom-up methods that have not been tested at scale, which leaves these networks vulnerable to the same kinds of abuse found on centralized sites. The p2p functionality of storing data or running gossip protocols in the background can consume a disproportionate amount of resources on a user’s device. P2p networks do not have global “like” or “share” counts, and some do not allow users to edit or delete posts. This behavior can be surprising and illustrates how features and performance users have come to take for granted can be challenging to replicate in a p2p network. Amplifying the technical challenge, the web is also built around the assumption of a client-server model, so networks attempting to be fully p2p must go very low level and deal with issues like NAT traversal.

Some disadvantages of federated and p2p protocols may be overcome in the future. Research and development on key areas like key management, identity, and moderation will help significantly improve usability. One barrier is that current implementations continue to be under-resourced — all the projects listed above have found some funding through donations, grants, or venture capital, but none have developed sustainable business models.

Another barrier is that decentralized protocols are inherently slower to evolve than centralized applications, because making protocol updates and getting all clients on board requires community coordination. Standards bodies like the W3C tend to emerge to coordinate updates, otherwise over time incompatibilities between implementations will split the network.

As it stands right now, centralized applications are easier to build, faster to iterate, and more straightforward to monetize, but a passionate community of people keeps working on decentralized alternatives because these technical architectures change the relationship between users and platforms, giving users more options.

You can find me on Mastodon, Matrix, and SSB:
SSB: @arcalinea

I’m also on Aether as @arcalinea, although it’s organized by topic, not users.

If you use another decentralized social network that you’d like to mention, feel free to write about it in the comments.

Thanks to gozala and the many people on Mastodon and ssb who read and gave feedback on this post!