Federation in Web3: Matrix, ActivityPub, and the Future of Decentralized Communication

There is a technology that has worked reliably for over five decades, that billions of people use every day, and that almost nobody would call revolutionary: email. Yet email is perhaps the most successful federated system humanity has ever built. No single company controls it. No central server needs to be running for it to work. Anyone can operate their own mail server and still communicate with everyone else. The protocol — SMTP, first specified in 1982 in RFC 821 — is an open standard that requires no one's permission.

And yet, the tech industry has spent the last twenty years doing everything it can to destroy this model. Slack, Discord, Microsoft Teams, WhatsApp — each of these platforms is a closed island. They cannot talk to each other. If you want to send a Discord message to someone on Slack, it is simply impossible. We traded the open, federated model of email for more comfortable but closed silos. And for most people, that was an acceptable deal.

For DAOs, it is not.

Why Federation Is Existential for DAOs

A Decentralized Autonomous Organization that runs all of its communication through Discord has a fundamental architectural problem. The organization is decentralized, but its nervous system is not. Discord can lock the server, change the API terms, or simply go down. In January 2023, a Discord outage left dozens of DAOs unable to function for hours — no governance discussions, no coordination, no votes. Decision-making power suddenly no longer rested with token holders but with the system administrators of a company in San Francisco.

This is not an edge case. It is a design flaw. If an organization understands itself as decentralized, its communication infrastructure must be decentralized too. Not for ideological reasons, but for purely practical ones: a single point of failure in communication is a single point of failure in governance. And a DAO without functioning governance is not a DAO — it is just a group of people with tokens.

Email as Blueprint — and Its Limits

If federation is so important, why not simply take email as our model? The answer lies in what email cannot do. SMTP was designed for asynchronous, point-to-point communication. There are no native group rooms, no real-time communication, no structured threads, no permission management. Mailing lists are a workaround, not a feature. Email is the equivalent of a mailbox in a world that needs conference rooms.

Email also has an identity problem. Your email address is tied to your provider. If you switch from Gmail to Proton Mail, you change your identity. You cannot take your address with you. In a DAO, where reputation and identity are often built over years, this is unacceptable.

So we need something that combines the strengths of email federation — open standards, decentralized control, interoperability — with the requirements of modern communication: real-time messaging, encrypted group rooms, structured permissions, portable identities. And this is exactly where Matrix and ActivityPub enter the picture.

Matrix: The Operating System for Federated Real-Time Communication

Matrix is an open standard for decentralized, real-time communication. The protocol was launched in 2014 and takes an ambitious approach: every conversation is a replicated data room distributed across multiple servers. When you create a room on your homeserver and someone from another homeserver joins, the two servers synchronize the entire state of the room. There is no primary server. Every participating server holds a complete copy.

This architecture has far-reaching consequences. First: resilience. If one server goes offline, the other servers in the room can continue communicating. The failed server catches up once it comes back online. Second: sovereignty. Every organization can operate its own homeserver and retains full control over its data. Third: end-to-end encryption. Matrix supports E2EE natively via the Megolm protocol, meaning that not even server operators can read messages.

For DAOs, it is particularly relevant that Matrix has a fine-grained permission system. Power levels determine who can send messages, invite members, or change room settings. This essentially corresponds to what DAOs need for their governance: graduated rights tied to roles rather than individuals. Theoretically, a Matrix room could be configured so that power levels are directly coupled to on-chain governance — whoever holds tokens automatically receives the corresponding permissions.

But Matrix also has weaknesses. Synchronizing large rooms across many servers is resource-intensive. Synapse, the reference homeserver implementation, is known for consuming considerable amounts of memory and CPU. The newer Dendrite implementation promises improvement but has not yet reached the same maturity level. And federation always means complexity: who is responsible when a spam server joins the network? How are conflicts in room state resolution handled when servers have different versions of the truth?

ActivityPub: The Social Fabric of the Decentralized Web

While Matrix is optimized for real-time communication, ActivityPub takes a different approach. The protocol, ratified as a W3C standard in 2018, was designed for social interactions: posts, comments, likes, shares. If you know Mastodon, Lemmy, or PeerTube, you know ActivityPub. It is the protocol that powers the so-called Fediverse.

The architecture differs fundamentally from Matrix. Where Matrix relies on replicated rooms, ActivityPub is based on the Actor model. Every user (or organization) is an Actor with an Inbox and an Outbox. Activities — a post, a follow, a like — are exchanged as JSON-LD objects between Actors. There are no shared rooms, no state synchronization. Instead, it is a message flow: I send something to your Inbox, you process it however you like.

This makes ActivityPub more lightweight than Matrix, but also less suited for structured real-time communication. Where it excels is in what it was designed for: public discourse, announcements, community building across server boundaries. A DAO could publish its governance proposals as ActivityPub posts that are commented on and discussed by members across different instances — without everyone needing to be on the same platform.

However, ActivityPub's identity model has a weakness that is particularly relevant in the web3 context: identities are tied to instances. If you are @user@mastodon.social and your instance shuts down, you lose your identity. This is the same problem as with email — and for DAOs that depend on sovereign identities, it is a serious obstacle.

The Identity Question: Where Web3 Can Make a Difference

And here things get philosophically interesting. Both Matrix and ActivityPub have the problem of server-bound identity. In both protocols, your identity is ultimately an address on a server that someone else operates. This is a fundamental contradiction to the web3 principle of self-sovereign identity.

The solution is — at least conceptually — obvious: cryptographic identities that exist independently of any server. A DID (Decentralized Identifier) anchored on a blockchain could serve as a bridge. You authenticate with a Matrix homeserver or an ActivityPub instance using your DID. When you switch servers, you take your identity with you. Your reputation, your connections, your permissions — everything is preserved.

This is not pure theory. There are already experiments in this direction. Matrix is working on a concept called "Portable Identities" that aims to address exactly this problem. In the ActivityPub ecosystem, there are proposals to use DIDs as Actor identifiers. But we are still far from a production-ready solution.

Federation as a Design Principle, Not a Feature

What frustrates me about the current discussion is the tendency to treat federation as an optional feature — something you can bolt on after the core functionality is in place. This is a misunderstanding. Federation is not a feature. Federation is an architectural decision that permeates the entire system. It affects the data model, identity management, conflict resolution, performance architecture, and the permission system. You cannot retroactively federate a centralized system, just as you cannot retroactively make a building earthquake-proof.

At Just Tech Solutions, we grapple with this question intensively — not least in the context of our work on CommonGround, a community platform that takes federation seriously as a design principle. The challenge is to combine the strengths of both worlds: the structured real-time communication of Matrix, the social networking of ActivityPub, and the sovereign identity of web3.

This is not a trivial problem. But it is a solvable one. The protocols exist. The standards exist. What is missing is the integration work — and the willingness to see federation not as a compromise, but as a prerequisite.

Looking Ahead

When I look five years into the future, I see two possible scenarios. In the first, we have repeated the mistakes of Web2: a handful of DAO platforms have emerged, each with its own closed ecosystem. DAOs are decentralized in governance but centralized in communication. The promise of decentralization remains unfulfilled.

In the second scenario, we have learned the lesson of email — but this time, we got it right. Federation is the standard. DAOs operate their own communication servers, connected via open protocols. Identities are portable and cryptographically secured. No company can cut off a DAO's communication because there is no central authority that could.

The difference between these two scenarios will not be decided by technology — the technology already exists. It will be decided by design decisions being made today. Every tool that a DAO chooses for its communication is a vote for one of these two scenarios.

Email has proven that federation works at planetary scale. Matrix and ActivityPub have proven that modern, rich communication can be federated. Web3 has created the tools for sovereign identity. The question is not whether decentralized communication is possible for DAOs. The question is whether we have the courage to build it.