What Exactly Is Federation, Anyways?

Table of Contents

Federation, the driving name behind decentralized and self-hosted software. But what is ‘federation,’ really? Well, there’s the really complex answer, and the simple answer. The simple answer is that federation is when multiple unrelated instances of a piece of software are capable of communicating and sharing between one another. The long answer, well, if you want to see that, then…

Federation is a bit of a hot topic at the time, as serious nerds (like myself) start looking towards self-hosted (meaning, run by myself) alternatives for software and solutions that previously just didn’t have that option. Some examples include:

• XMPP (Jabber), decentralized chat
• Matrix, decentralized chat (that also had some inspiration from XMPP)
• Nextcloud (when enabled), file sharing, conversations, and other functionality defined by extensions (‘apps’).
• PeerTube, a self-hosted YouTube alternative
• Pixelfed, a self-hosted Instagram alternative
• Mastodon, probably the one name you’ve heard when it comes to federation, basically a self-hosted Twitter.
• Email. No, I’m not kidding. Email is technically a federated network.

Really, federation is just, well, decentralization with extra features. Decentralized software is where, in effect, anyone can run their own instance, there is no one ‘central’ location. Take for example, using Nextcloud vs. Dropbox. There is no one single Nextcloud, but there is a single Dropbox. Federation expands on decentralization by allowing all these instances the ability to natively talk to other, remote instances. Using Nextcloud as an example again, just allowing me to run my own makes it decentralized. Allowing me to share a file to a user on another public instance is what makes it federated. There’s, to the user, little distinction between remote instances and local instances, just that remotes usually need a domain in them. For example, I could share a project I’m working on with, say, joe, which would be a local user, or [email protected] which would ping joe on the Nextcloud instance at example.com with my sharing request.

Fediverse

Now, I can’t talk about this without mentioning the Fediverse. The Fediverse (Federation Universe) is the collective name for a list of software that allows federation over a common communication standard, one like ActivityPub, OStatus, or Zot, as well as the individual instances of those pieces of software. Not all federation is part of the Fediverse. Matrix and XMPP are ‘federated,’ but by not using those standards, they’re not part of the Fediverse. However, Nextcloud allows remote sharing of files by sending ActivityPub communications between both instances, meaning that this is part of the Fediverse.

Protocols

You know, as long as I’m here, let’s go over some of those protocols. The four ones for the Fediverse are ActivityPub, the Diaspora protocol, OStatus, and Zot. ActivityPub seems to be the most common, by far.

ActivityPub

Based on Pump.io’s ActivityPump protocol, ActivityPub, meant to supersede OStatus, and it was developed by the World Wide Web Consortium (W3C). ActivityPub has both a client-to-server component, for creating and updating content, and a server-to-server component, for federation. Taking a quick look at the specification, AP (as I’m calling it now) is primarily a standard HTTP based protocol that facilitates the transmission of objects between actors. Each actor has an inbox and an outbox, where attempting an HTTP GET on your inbox will show any objects that have been addressed to you, and POSTing to your outbox will cause that object to be sent to the given actor. AP makes use of ActivityStreams as its payload, which is a JSON-LD (JSON for Linked Data), which is just an extension to plain JSON. In effect, that means that AP communications are just sending JSON that conforms to a given schema, but there’s nothing really special about it, no weird formatting. Different, well activities can be performed by actors, like Create, Update, Follow, Like, Block, etc. To facilitate actual federation, servers can POST to an actor’s inbox on another server.

That’s basically the entire protocol, the rest is just up to the ActivityStreams payloads, and whatever else on top of them the actual application servers have added.

Diaspora (diaspora*)

Diaspora is a decentralized social network, but the specifics of it aren’t important here. What is important is that its federation protocol has seen use by a few other platforms, and is one of the protocols that’s part of the Fediverse. Diaspora makes use of a XML-over-HTTP protocol, meaning that it’s byte-for-byte less efficient than a JSON-based payload. Their federation protocol is only meant for server-to-server communications, and facilitates sending of entities from one server to another, with each entity meaning something significant. Some example entities include Comment, Like, Message, StatusMessage, and Profile.

Unlike ActivityPub, which has the ability to cryptographically authenticate received data from a server, Diaspora federation requires it, using something called Magic Signatures (from something called the Salmon protocol), thus making keeping an RSA key on every server more-or-less required. Diaspora also allows, as part of the specification, encrypting private messages between users, which takes the entire XML payload, encrypts it, and then wraps that in a very simple JSON payload. Wait, why are they using JSON now instead of XML?? Either way, by specification, both these two points are defined, and I assume that means that other software using the protocol is also similarly equipped to handle it.

Unlike ActivityPub, the actual specification is pretty rigid, probably because it wasn’t originally meant to be an open standard, it’s specific to one platform. As such, while I have no doubt that it can be extended because of how the XML is structured, the protocol itself isn’t designed for that in the same way that ActivityPub or OStatus is.

OStatus

While a few places do still use OStatus, it’s been officially superseded by ActivityPub. OStatus as a standard is a bit of a conglomeration, describing how a number of smaller other protocols can be used in conjunction with one another for the purpose of federated microblogging (‘microblogging’ basically being the technical term for what Twitter is, short status posts).

For the actual protocols in use, it’s a mixture of Atom (RSS), ActivityStreams (where have I seen that before?), WebSub (publish/subscribe semantics over the web), and Salmon (user interaction / commentary using extensions to Atom). There’s really not much to say about this one, I can kinda see why it was replaced with something that seems to actually be self-contained.

Zot

Zot is a protocol for decentralized communications, that’s not tied to any one app (like the Diaspora protocol), and uses JSON-over-HTTP. The current version is Zot version 6, A.K.A. Zot/6, A.K.A. Zot6. Zot enforces message signatures like Salmon (and Diaspora) does, and has a few interesting properties. Unlike other protocols, Zot allows for ’nomadic’ identities — users not permanently tied to one domain. Take Matrix as an example. if I’m @someuser:example.com, I can’t just migrate to @someuser:other.site.com, because it’s a different domain, it’s a completely different user ID, it’s just not possible. Zot allows this.

Zot also doesn’t define an actual payload format, allowing for several. Zot6 introduced support for ActivityStreams serialization. In theory, this means that Zot can be a sort of ‘vendor agnostic’ standard, able to transform the payload format into whatever the receiving end can handle. Zot also allows for message encryption, much like Diaspora does, but Zot doesn’t start out with the basis for such being only for private messages between users.

In conclusion, federation is a cool concept. The ability for one instance of something, to theoretically be able to talk to any other instance, anywhere when requested is neat. Now, I’m not going over the serious logistical requirements of doing such, even if the most common protocols for that are relatively simple. But regardless, it’s a big plus for tinkerers that just like running their own stuff for reasons of ‘because I can’ (me), or for the more privacy-focused who don’t trust centralized systems, but still want to be able to actually interact with each other, something that without federation is not possible unless everyone is on the same instance.

One final post-script. Yes, I made mention that email is technically federated, and I’ll elaborate on that for just a little bit. Email, as a communications channel, is not tied to a central authority, and uses a distributed store of public information to allow for independently-run instances to find each other, and message them, just by starting with their domain name. By looking for the DNS MX record for a domain, an email system (as it’s officially called, an MTA, Mail Transfer Agent) can find the corresponding MTA for the recipient domain, in order to establish a connection and send over the message that a user on domain A wanted to send to a user on domain B. It’s literally, by the letter of the definition, a federated system, just one that we don’t tend to think about as a federated system.