Decentralized vs. Federated
Tags: decentralization, federation
Published: 2023-07-24 22:54:09

---
title: Decentralized vs. Federated
published: true
date: 2023-07-20 22:00:00 UTC
tags: Decentralization,Federation
canonical_url: https://kevincox.ca/2023/07/20/decentralized-vs-federated/
---

<main style="--width:min(36em,100%);display:grid;grid-template-columns:1fr var(--width) 1fr;overflow:auto;padding:0;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><p style="box-sizing:border-box;grid-column:2;margin:.4em">I often see the terms <em style="box-sizing:border-box;margin:0">decentralized</em> and <em style="box-sizing:border-box;margin:0">federated</em> used somewhat interchangeably. So I wanted to provide a simple explanation and example of the difference.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">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 <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">kevincox.ca</code> and your instance is <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">gmail.com</code>. Decentralized additionally requires that those objects can exist independently of any particular instance. For example anyone can download <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">ipfs://QmVG7MtnRoVFfmM6XY4mkiQJpdJoyRLfHdsNfgSAM4y5xs</code> even if my instance is long gone.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">As an example I will be using <a href="https://matrix.org/" style="box-sizing:border-box;margin:0;text-decoration:underline;-webkit-text-decoration-color:gray;text-decoration-color:gray">Matrix</a> Rooms and <a href="https://join-lemmy.org/" style="box-sizing:border-box;margin:0;text-decoration:underline;-webkit-text-decoration-color:gray;text-decoration-color:gray">Lemmy</a> 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.</p>
<aside style="background:#333;box-shadow:4px 4px 8px #000;box-sizing:border-box;color:#fff;grid-column:2;margin:.2em 1em .6em"><p style="box-sizing:border-box;margin:.4em"><strong style="box-sizing:border-box;margin:0">Note</strong>: While Matrix Rooms are decentralized not all aspects of the protocol are. For example Matrix user accounts are federated.</p></aside><p style="box-sizing:border-box;grid-column:2;margin:.4em">Let’s consider Lemmy Communities. A Lemmy Community has an ID like <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">!technology@lemmy.ml</code>. <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">technology</code> is the community ID and <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">lemmy.ml</code> 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.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">In Lemmy, (like most federated systems) all modifications go via the owning instance. This means that if <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">lemmy.ml</code> goes down the <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">!technology@lemmy.ml</code> 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 <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">lemmy.ml</code> 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.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">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 <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">!sCCUGSrsfFwuPlMnhw:matrix.org</code>. But it is best to consider this as an ID namespace. It just ensures that IDs don’t collide. Even if <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">matrix.org</code> went offline that room would be fully functional to everyone else in that room.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">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 <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">via=</code> parameter like <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">matrix:r/sCCUGSrsfFwuPlMnhw:matrix.org?<b style="box-sizing:border-box;margin:0">via=matrix.org</b></code>. This says “If you don’t know about this room <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">matrix.org</code> can probably help you out”. When clients generate links they will usually attach <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">via=</code> parameters for severs currently involved in the room. This way a link like <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">matrix:r/sCCUGSrsfFwuPlMnhw:matrix.org?via=matrix.org&amp;via=mozilla.org</code> can continue to be used even if <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">matrix.org</code> goes offline. The room can continue uninterrupted without its original sever.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">You can also create additional names for a room. So I can register <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">#blog-example:mozilla.org</code> to point at the room that has <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">matrix.org</code> in its ID. If you try to join this room your client will ask <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">mozilla.org</code> about its <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">blog-example</code> alias. Then your client can join the room. These aliases are federated, not distributed. So if <code style="background:#000;border:1px solid #555;border-radius:.3em;box-sizing:border-box;color:#fff;margin:0;padding:0 .2em;white-space:pre-wrap">mozila.org</code> 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.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">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.</p>
<p style="box-sizing:border-box;grid-column:2;margin:.4em">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.</p></main>