Matrix is a federated protocol. For reference, email is also a federated protocol. This means that the way Matrix (and email) work is though two tiers: client-to-server interactions, which you will likely be more familiar with, and server-to-server interactions, which server administrators will be the most familiar with.
Every Matrix user address takes the following form:
@username:homeserv.er. This is the case because all of this information is necessary:
@denotes that this is a user, and not something else.
#is used to denote rooms, and
+is used to denote communities.
usernameis, predictably, the user’s unique identifier on their home server. Only one user may have a given username on each server. That is, if your address is
@email@example.com, there may very well be another
balthazaron another server, e.g.,
@firstname.lastname@example.org. To summarize, it’s just like with email.
- After the colon (
:), we have your homeserver’s hostname. This tells other Matrix servers where to forward messages addressed to you, as they cannot deliver them all the way by themselves. Once your homeserver receives the forwarded messages, it will deliver them to you directly. You will not really notice this happening, except as a difference in responsiveness if you join a room hosted on another homeserver or chat with someone who has a different homeserver. For the curious, email works the same way when sending mail.
An Illustrated Guide
This being a quick guide, let’s proceed with some visual aid. Black arrows are potential connections where nothing is being sent at the time. Red arrows are active connections with data moving across them.
First off, take a look at the shape of this network. This shape is a reliable mental image of federation. There is no network center, but there are some important nodes that have more connections that others: the homeservers. Clients have the fewest connections, each only connecting to his own homeserver.
Next, let’s look at what happens when two people on the same homeserver, Alice and Amos, have a chat. If you ignore all the other servers and clients, then the network consisting of Homeserver A, Alice, and Amos is a centralized one. This highlights the nature of federation as a middle-ground between centralization and peer-to-peer.
Now, more interesting, Alice catches up with Ben, who uses Homeserver B. You can see here that their homeservers are passing messages back and forth to connect the two.
Finally, the jackpot, a room with members from all three homeservers on our diagram. Alice, Ben, and Cody are in a room together.
You should now have a big-picture understanding of what it means when one says that a network or protocol is federated.