Decentralized vs. Federated
Posted
I often see the terms decentralized and federated used somewhat interchangeably. So I wanted to provide a simple explanation and example of the difference.
Federated means that multiple instances can operate on the same logical objects. For example, I can add an email to your inbox even if my instance is kevincox.ca and your instance is gmail.com. Decentralized additionally requires that those objects can exist independently of any particular instance. For example anyone can download ipfs://QmVG7MtnRoVFfmM6XY4mkiQJpdJoyRLfHdsNfgSAM4y5xs even if my instance is long gone.
As an example I will be using Matrix Rooms and Lemmy Communities. From an abstract point of view these are similar things. Users can subscribe to get updates, post top level items, reply in discussion threads and there is a permission system to control who can do what. However, there are some important differences because Matrix Rooms are decentralized and Lemmy Communities are federated.
Let’s consider Lemmy Communities. A Lemmy Community has an ID like !technology@lemmy.ml. technology is the community ID and lemmy.ml is the instance that runs the community. Since Lemmy is federated any user can subscribe and interact with this community no matter what instance they belong to.
In Lemmy, (like most federated systems) all modifications go via the owning instance. This means that if lemmy.ml goes down the !technology@lemmy.ml community grinds to a halt. You can still read past discussions if your instance has them synchronized locally, but no one can post new content. (Well maybe people on your instance can see it, but it won’t reach other instances until lemmy.ml comes back online). So while any Lemmy user on any Lemmy instance can participate in any Lemmy Community, that community is still “owned by” and dependent on its instance.
Matrix Rooms are quite different. A Matrix Room doesn’t “belong” to any instance. It is true that the room ID does contain an instance name, for example !sCCUGSrsfFwuPlMnhw:matrix.org. But it is best to consider this as an ID namespace. It just ensures that IDs don’t collide. Even if matrix.org went offline that room would be fully functional to everyone else in that room.
Element—the most popular Matrix client—doesn’t even let you connect via the room ID if it is unknown to the instance. You need to use a room name, or a via= parameter like matrix:r/sCCUGSrsfFwuPlMnhw:matrix.org?via=matrix.org. This says “If you don’t know about this room matrix.org can probably help you out”. When clients generate links they will usually attach via= parameters for severs currently involved in the room. This way a link like matrix:r/sCCUGSrsfFwuPlMnhw:matrix.org?via=matrix.org&via=mozilla.org can continue to be used even if matrix.org goes offline. The room can continue uninterrupted without its original sever.
You can also create additional names for a room. So I can register #blog-example:mozilla.org to point at the room that has matrix.org in its ID. If you try to join this room your client will ask mozilla.org about its blog-example alias. Then your client can join the room. These aliases are federated, not distributed. So if mozila.org goes down that name will stop working. But you can continue to connect to the room by names hosted on other servers or by ID if you know at least one server participating in the room.
The advantage of distributed protocols is that the objects are not tied to any particular server. Objects can continue to be used while the original server is offline; either temporarily or permanently. I suspect that this will be an issue for services like Lemmy. ActivityPub is a good protocol and made sense for more 1-on-1 relationships such as following people, replying and sending messages. However, the downsides become clear for objects that have much less attachment to any particular server such as Lemmy Communities. In many ways the server that a community is hosted on doesn’t matter, you can read, post and comment from any other server. But the reliability and longevity of the community is tied to original instance. I’m sure we will see issues where large communities—likely with a majority of members on different servers—will die because the server hosting it goes offline.
In general decentralization is better than federation. For example Matrix would do well to decentralize user accounts (there are some proposals in flight). Imagine if I could read and send messages from a different server if my main server goes offline. My username would just become one alias to the underlying account that can outlast any number of instances going offline. Decentralization is powerful.