#?.info

I just compared AT and ActivityPub and you can take a look at my thoughts in my prior post. But I thought it might be worth asking the question “How do we know a federated protocol can survive.”

Experience isn't good on this one. Since the Internet became popular, there have been multiple federated systems that were introduced, became popular, and then died for whatever reason. They include:

• Usenet – was only ever semi-open. All but dead.
• Email – Went from open to semi-open. Crippled.
• IRC – All but dead.
• XMPP – All but dead.
• RSS – All but dead.
• “The Web” – under threat and becoming more centralized.

In fact, other than email and the web, virtually every single once-popular federated system has ended up being killed.

So what killed each?

Usenet bulletin board services

Usenet first: Usenet was actually not federated enough for most people. It became easier to set up a BBS on a website than it was to set up a newsgroup moderated the way you wanted it. Sure, there was alt., but a lot of ISPs intentionally blocked some or all of alt. because it was considered an unmoderated wasteground. Larger ISPs also had problems keeping their NNTP servers running – at the time scalability was a new art in the Internet age that few people were familiar with. As if to add insult to injury, spammers had no problems – despite the semi-open nature of Usenet – posting crap all over newsgroups.

Usenet's federated successor is arguably Lemmy, but Lemmy is overshadowed by the proprietary website Reddit, which served as Lemmy's use model.

Conclusion: Usenet was too restricted forcing people to use alternatives, and was unable to cope with spam.

Email

Email didn't die but it is crippled. An unlikely but possible scenario right now is for Google and Microsoft to team up and close off all federation except to each other, in the name of killing spam. It'd work too! Google and Microsoft together own most email through their public email offerings, and services like Office 365. The major issue would be some Microsoft customers still manage their own email – but that's slowly being migrated to Office 365 in the name of ease of management, and a concerted push by Microsoft would push everyone over the edge and force this to happen.

Like I said, unlikely, but only because regulators would take an interest. The question you should ask though is not “Why are you an idiot proposing Microsoft and Google would do this?” but “How did we get to a point where this is possible?”

Answer: Spammers and idiot responses to spam. Spammers overwhelmed email servers early on in the public Internet. System administrators started creating more and more crazy rules, from blocking IPs used by long gone spammers, to blocking ISP customers because supposedly we'd only ever want to send emails via the ISP relays. ISPs started blocking port 25 making it impactical to be part of the federated email system, and, one thing lead to another, and now two companies “own” most email. That's not healthy.

Conclusion: Federated email is threatened by poor technical choices leading to difficulty managing spam and further poor technical choices that lead to a de-facto centralization of email to deal with the first set of poor technical choices. Spam is bad, but dealing with spam must be done carefully.

Internet Relay Chat (IRC) Real time group and personal messaging

IRC largely failed due to overloaded servers and a protocol that just wasn't scalable. It broke up early on into multiple networks, and by all accounts those networks have continued to split. Proprietary chat systems started to move into IRC's space, and people generally preferred them because they were less clunky. Today IRC's federated successor is supposed to be Matrix, though for a variety of reasons it hasn't taken off. Despite Matrix nodes storing a history of every single conversation that occurs on its part of the network, Matrix is considered far more stable and secure than IRC was. But it's far from clear it has the feature set people want from a chat system in 2025, and it's too slow.

IRC, like Usenet, was only semi-federated, servers in each network have to be approved of by others in that same network. But this doesn't appear to be the cause of any damage here.

Conclusion: IRC was built upon poor technical choices and access to it was limited to clients that weren't always user friendly.

XMPP Instant Messaging

XMPP started as an attempt to define a non-proprietary standard for instant messaging. The system was initially successful with Google building Google Talk on XMPP, and some existing instant message services such as AOL's AIM and Yahoo's YIM creating XMPP gateways.

And then they decided they didn't need it and each company closed off XMPP federation and what little was left allowed non-proprietary chat clients to connect to accounts. But you couldn't IM your friend on Google from AOL any more.

Why they disconnected from XMPP looks mostly to be because of misjudgements from the companies involved. Most thought they could “win” an “Instant messenger war” by not federating, but that's not how it works, and instead that generation of instant messaging as a whole became less popular than IRC and Usenet, with services like Slack and Discord reinvigorating the concept years later. Another possible explanation was that XMPP might have helped keep the concept alive, but it just wasn't helping enough, with very few people actually communicating between different services.

Conclusion: An early application that was probably too ahead of its time, and it's unclear it was easy to use given the apparent little use federation had at the time by end users even when it was available.

RSS Feeds

RSS was, actually, successful with a sizable amount of the blogosphere. The basic concept was every blog had a “feed” and you could use clients to subscribe to that feed. You could usually read the full blog entries via your RSS client, and if you couldn't, or you wanted to see if you could leave a comment, you could just visit the page directly on the publisher's website.

RSS feeds didn't stop being published, Instead, a more insidious thing happened. The most popular RSS reader on the Internet was a service called Google Reader. It worked from your web browser, was clean and easy to use, and everyone loved it.

Unfortunately blogs were considered competition for social media, and Google killed Google Reader in an attempt to shore up Google Plus, their exciting new social network service. Google actually did more than kill Reader, they broke virtually every part of their system trying to graft support for Google Plus onto it, which means there was a certain amount of schadenfreude felt across the Internet when Google Plus died because nobody wanted it. Unfortunately killing Google Plus didn't kill Google's attitudes, and Google has never been the same since. And no, they didn't bring back Google Reader.

Conclusion: RSS “died” because almost everyone relied upon one proprietary client to use it, from a fair-weather friend.

“The Web”

For now, the web remains open despite constant efforts from ISPs to restrict what people can use their Internet connections for, and from mobile “apps” which attempt to replace websites. However, large corporate entities do have an oversized influence on the web right now.

Conclusion: None, yet.

Conclusions

I would suggest testing the strength of federation with the following measures:

1. Is it genuinely open? Can anyone just join in? Or is it ultimately controlled by a small group of server administrators who won't allow people in without permission?
2. Does it have the tools to manage and restrict abuse, especially spam?
3. Are multiple clients available? Are they easy to find?
4. Is it a mature concept? Do we know it's actually what users want, or is it a clone of something simple that was successful but nobody's quite sure if that's the right way of doing things?
5. Are the majority of users using federation? Or could a node stop federating without most users being affected?

Using the conclusions

These are just notes at this point, points for you to think about. Looking in particular at ActivityPub and AT Protocol – let's call the AP based microblogging network “Mastodon” and AT Protocol based on “Bluesky” for now, although both names are misleading:

Test 1: Openness

Mastodon is completely 100% open. There are no gatekeepers in terms of creating new nodes and adding users to those nodes.

Bluesky is dejure open but not defacto open. The critical problem are relays, which are expensive to manage and maintain, and are critical to ATP working. In fairness, as long as one entity runs an open ATP Relay the entire network remains “open”. But as of right now only one company manages one (Bluesky.) Additionally those configuring relays currently make the decision as to which PDSes to pull from. Just because you stand up a PDS doesn't mean Bluesky's relay (even now, when it is “open”) will automatically start reading it, and there's no protocol as of yet to advertise the existence of PDSes for relay operators to automatically use.

Test 2: Does it have the tools to manage and restrict abuse, especially spam?

Mastodon has several tools to help with spam, and mostly uses a “follow” model for normal content. However, it has the ability to send messages to specific users. In theory, concerted attempts by spammers to send spam to specific users would succeed and make the network far less usable. There's a high risk administrators would start whitelisting nodes rather than blacklisting abusive nodes. Mastodon administrators arguably need to look for easier ways to federate abuse notifications and blocks.

Unlike email once an administrator has been notified that an instance is sending spam, they have easy means to prevent that spam from reaching users who haven't read it yet. So the situation isn't as bad as email or Usenet, but it's still bad.

Bluesky does have the ability to deal with spam although there are ideological reasons why they might not do so in the beginning. Specifically Bluesky's relays are able to avoid PDSes known to send spam, and Bluesky's wider architecture (not just the AT Protocol specified part) allows AppViews to similarly run “algorithms” that, among other things, can filter spam. This is good, but it remains theoretical that it can work, and ideologically Bluesky's designers do not like filtering and blocking and moderation in general.

Test 3: Are multiple clients available? Are they easy to find?

Mastodon has a plethora of clients and servers available and access is not restricted in the slightest. Clients include web clients, mobile apps, and whatever is built into the server. The Mastodon implementation of, uh, Mastodon (heh) even has a published client protocol allowing third parties to easily make custom user interfaces for generic Mastodon servers.

Bluesky likewise has a plethora of App Views and PDSes available. As App Views and PDSes form the basis of the interface Bluesky users have to the Bluesky network, this covers the bases.

Test 4: Is this a mature concept?

Arguably the concept itself is. Twitter was created in 2006, and continued to grow and remained popular until its closure by Elon Musk about two years ago when it was replaced by the neo-nazi microblogging network X. It has spawned multiple successful clones.

Mastodon's implementation, however, is considered lacking. It lacks a global search, and tools to highlight posts and comment upon them (called “Retweet with comment” on Twitter), for example, have been intentionally avoided because of concerns about abuse and promoting dunking on people.

Bluesky has a fuller, richer, implementation of the basic concepts that fits what Twitter looked like two years ago. Some of these are arguably harmful, such as black-box algorithmic views vs chronological.

Bluesky is definitely an implementation of a mature concept. Mastodon's is close but not necessarily what people who want “Twitter but federated” want.

Test 5: Are the majority of users using federation?

In Mastodon's case, yes. I don't think there's a way to use Mastodon where you don't end up following at least one person on another server. Most users are following users on multiple servers. They're federating. Yay.

Right now almost all Bluesky users are using Bluesky (the corporation's) implementation – their servers, their clients, etc. So the chances are very few Bluesky users are actually federating at all.

Final conclusions

Mastodon's main weakness is in not providing the product people are looking for. It federates well and is well protected against corporate takeovers, but the lack of discoverability harms it. It also needs to address spam and abuse before it reaches a large enough size that spammers seriously target it.

Bluesky's main weakness is that almost its entire userbase is using infrastructure provided by just one company. Long term if that changes, it stands a very good chance of becoming strongly federated, but right now the federation is weak.