Beyond Mastodon and Bluesky - Toward a Protocol-Agnostic Federation

You’ve heard of stuff like Twitter, Facebook, and Instagram. Make an account on one, and it only works there. You can’t send a DM to your friend on Twitter from Facebook Messenger. You can’t browse your friend’s Instagram feed from Twitter. Each one is closed off from the others. If you want to view things on a centralized platform, you need an account there. If you want to move your account from one to the other, you’re out of luck. If you’re banned, goodbye to everything you’ve posted, all your connections.

It didn’t have to be this way. It doesn’t have to be this way. There is hope for a more connected future.

In the beginning, there was FidoNet

Of course, there were things before it, and you could argue that any of them are better starting points. You could go all the way back to the Big Bang and the original federation: the entire cosmos. I’m not. FidoNet sounds like a social network for dogs, and I like dogs. It was also huge.

Early computer-connected communities communed on Bulletin Board Systems (BBSes). Some cool person would put a modem in their computer, people would dial in and do the same things we do online in 2023, and disconnect.

People shared photos. People talked. There were chat rooms. There was commerce: people traded and sold like they do on Craigslist or Facebook Marketplace. There were trolls, miscreants, and curious pseudonymous characters just as there are today on centralized platforms.

There was much screeching, ee-awwing, and rejoicing.

FidoNet solved two big problems:

1. Phone calls cost money
2. A single BBS was limited in reach

At its peak, FidoNet had over 40,000 systems. I can’t find a source for user numbers, but I wouldn’t be surprised if it was at least a million. That was big back then. It still runs today, though the network is significantly smaller.

FidoNet worked by forwarding messages between BBSes. The network tried to optimize paths to limit phone call fees, taking advantage of free local calls when possible. Some probably had dedicated always-on lines like a T1, but a simple dial-up modem was most accessible, so most numerous. How FidoNet accomplished this feat of networking evolved with the available technology and shifting fee structures, and it’s out of scope for this article.

Enter The Fediverse

The Fediverse is both an idea and a set of competing protocols. Platforms and tools are built on top of these protocols: the Twitter-like Mastodon, the Instagram-like Pixelfed, the YouTube-like Peertube, the Reddit-like Lemmy. The list is large and growing. The current most popular protocol is ActivityPub (AP for short), both due to its use by the popular Mastodon project and because it’s a genuine W3C standard. It’s what all the aforementioned platforms run on.

Broadly, most notions of federation work similar to FidoNet.

• Servers are independently run and funded.
• Anyone can run their own server however they like.
• Messages move between these servers over a shared protocol.

ActivityPub is closest, complete with a concept of inboxes and outboxes. It’s minimal in what it specifies. This minimalism is both a strength and weakness: any platform can decide how to go about its business without worrying about other platforms. But that’s not so great if you’re working on a new platform where you expect users will want to talk to other federated platforms.

One big hole, at current, is the lack of standard migration logic. You might be stuck if you pick the wrong platform or instance (server). There’s no reason ActivityPub can’t support this, but it’s a whole new level of complication, and work is still underway to develop it. Until then, there’s the Move activity–the Activity in ActivityPub!

Mastodon can migrate most things, but not currently posts. This matters more or less depending on who you ask. Firefish is compatible with Mastodon and largely fills the same niche, and it supports full migrations. Even from Mastodon!

That is…as long as your server doesn’t vanish or summarily execute your account while you’re asleep. Most gripes about Mastodon and ActivityPub center around this. Anyone who’s been around long enough has seen or experienced a server disappearing. Or they’ve watched as a feud between servers escalated into a defederation before anyone could export their follows. Not a great experience.

Bluer Skies

Bluesky’s AT Protocol aims to solve this by adding another element above their server concept: the Big Graph Service, or BGS. These collect, index, make searchable, and relay posts between connected instances (PDS, or Personal Data Server). BGSes are like the big nodes in FidoNet that took advantage of the declining cost of calls with duration to collect large batches of messages to distribute them in large chunks to smaller local BBSes over long calls.

It’s not clear how the BGS approach works in the event your server goes away, and I think it’s still under development. This will all shake out as Bluesky finishes and publishes its federation concept. But the point is: some degree of whole account portability is a core part of the protocol. You can already link an account to a domain you own, as I have. Even though my account is viewable on the bsky.app PDS, the “kyefox.com” part is forever linked to a domain I control. You might have to look up kyefox.com on your server in the event that link is broken in the future, but it should come up if I’ve moved to another PDS. I should be able to simply point a DNS record on my domain somewhere else if I move servers even if something keeps me from moving my posts. Even if there’s no server left to move from.

The Protocol-Agnostic Approach

E-mail is another federated system used by almost everyone. It uses multiple protocols.

• POP3 to get messages to the user’s client
• IMAP to get messages to and from the user’s client
• SMTP to move messages between servers

This makes for lower stakes when making changes to a protocol. Fastmail can promote JMAP, its proposed improvement to IMAP, and only make waves in the server-to-client world while SMTP continues merrily along without a worry in the world. You can still check your email on Fastmail through IMAP, too.

It also makes for easier integration. I can make a little client to download emails, and nothing else, with only knowledge of POP3. IMAP adds a lot of complexity a simple email download doesn’t need to worry about. This is less of an issue today with most programming languages supplying libraries to communicate with all standard internet services. This is not currently the case with ActivityPub or AT, but independent efforts for various languages are underway.

Mix and Match

The obvious question is: why not just AT? It does everything ActivityPub does and solves the big problem! Let’s just toss AP, right?

Not so fast. Like it or not, ActivityPub is already a real standard with numerous popular working implementations with millions of users and tens of thousands of nodes between them. Burn time throwing it out to replace it with AT, and you risk some centralized platform racing in to scoop up all the people looking for a home as existing centralized platforms turn to garbage and collapse.

That time and energy could be better spent making a more flexible multi-network federation with portable identities and non-destructive moderation so most of the gripes that send people back to centralized systems are moot. With this approach, you could even build in support for migrating from the centralized platforms so people don’t lose anything in the migration.

Instead, we can do like Mastodon did early on: support two protocols, then phase out the old one slowly and carefully if needed. OStatus, Mastodon’s first protocol (originally from the GNU Social platform which merged with several older platforms), is still around, but numbers prove the merits of the new protocol even if it’s easy to issue credible technical arguments against ActivityPub.

Maybe AT will take over and truly obsolete AP. Maybe another protocol will pop up to supplant both. Maybe the development effort behind Tumblr’s announced ActivityPub support will come out of mothballs and materialize. And that’s the beauty of this approach. You aren’t stuck with a choice. The Federation can grow and evolve independent of the underlying technology.

• Let AT talk to AP at the instance level.
• Use something like AT’s BGSes to provide a platform and protocol agnostic migration path.
• Extend Mastodon’s existing HTML tag based verification method with personal domains as handles ( the @ user names most platforms seem to prefer) from AT.
• While we’re at it, toss IMAP and POP3 in there for fun and hook it up to FidoNet and Gopher.

Someone will inevitably write a bridge program so implementers don’t even have to think about it. Pick the protocol you like. Write for AT, pipe it into the bridge, and AP comes out. Write for AP, pipe it into the bridge, and AT comes out. BGSes are the ideal point to handle this. They could even smooth the transition process if a new protocol enters the field. Developers could even write plugins to support new protocols, calling back to multi-protocol messengers like Pidgin that supported all the proprietary protocols like AIM’s OSCAR and TOC, plus IRC and XMPP.

Mix and match, and the whole is greater than the components. And if one or another proves superior long term, phase out the losing protocols. Sorry, OStatus faithfuls. I think niche is your destiny. But maybe the bridge will support you anyway.

That’s where protocol-agnostic federation shines: you don’t have to “beat” each other. There’s no real competition. You hook your hot new platform in and already have a user base. Or connect your weird little goblin of a network with three people and talk to people outside.

Prediction

This article is the reboot of something I wrote around 2018 and republished in 2020 titled “ActivityPub could be the future.” Five years on, my conclusion holds: Mastodon and ActivityPub might not be the thing, and now Bluesky, but federation is here to stay. What I’ll add is that the different notions of federation will have to work together to remain viable against the internet’s tendency to gather around centralized, debt-burdened platforms that inevitably collapse and leave hundreds of millions of people stranded.

I’m probably directionally right on social media heading toward a protocol-agnostic situation with bridges and Big Graph Servers or something else handling communication and migration on a layer between protocol and platform.

But I’ve read too many old blog posts from the 2000s and 2010s to think I got the protocols or even the platforms right. Most likely no one in 2040 will know what Mastodon or Bluesky are even if the next thing is inspired by what they started, in the same way most people on federated social networks have never heard of GNU Social. Those old posts rattled off names of apps and tools that were hot then, but nobody’s heard of now in 2023. Just think of the name “Firefish.” It sounds fine and reasonable to people who Get It, but in 20 years it’s going to sound as weird a name for a platform as all those app names and concepts those old blog posts rattled off.

I mean, come on. PubSubHubbub? Let’s be glad it’s called WebSub now. A much more serious name no one will snicker at for any reason.

More to come. This was getting a bit heavy at almost 2000 words, and all the things I didn’t get to here could each be their own equally large article.