You know I’m a committed user of the fediverse, perhaps this post will surprise you. Still, at some point the truth has to be told, before lying leads to a catastrophe.
I think I’ve been present in the fediverse (sometimes hosting a pod of some software and sometimes not) since its inception. And what I’ve seen is that nobody learns from mistakes, and mistakes are repeated bigger and bigger, and bigger and bigger.
It’s time to tell the truth about the fact 70% of federated platform projects are incomplete, bogged down or simply abandoned.
lostinlight
Sooner or later someone has to shout the truth out loud. And the truth is
The activityPub protocol sucks.
ActivityPub looks like it was written by an idiot who just won second prize in idiots’ contest. It has every possible flaw without having any good.
ActivityPub is the perfect representation of the pompous incompetence of those programmers who put their lousy hands on a computer just because it’s legal.
Before going into detail, let’s look at some history of the ‘federation’.
The first protocol I can remember being to “federate” was UUCP. (I am not taking into account things like Token Ring, of course). In the UUCP protocol people had to describe which resource (or program) they wanted to operate, and the remote machine on which people wanted to move files.
https://en.wikipedia.org/wiki/UUCP
Let’s be clear about one thing: although it is very old-fashioned, the UUCP protocol could meet all the requirements of the “fediverse”: that means it has all what is needed.
In more recent times, I can mention other protocols that “federate”:
- SMTP
- SIP
- XMPP
all these protocols describe the user as “user@FQDN”, i.e. they rely on a DNS to find the machine where the user is located, and then ask a local system to deliver the message to the user.
All three protocols are widely used: mail, VOiP, Instant Messaging.
It may seem contradictory that all these ‘decentralised’ protocols are based on a very centralised structure such as the DNS, when one could use a DHT, like torrent is doing.
The answer is that the modern programmer, completely ignores DHT, and barely knows about the existence of DNS ( without a clou about how DNS works: when the modern programmer has a name resolution problem he changes /etc/hosts and then wonders ‘cause the software doesn’t work outside its computer)!
In any case, the pattern is always the same. And paradoxically, so is the “fediverse” : a user describes himself as “user@FQDN”, and FQDN is resolved by the DNS.
Could SMTP, XMPP, SIP have been used to build the fediverse?
The answer is: yes, and they would have worked MUCH better.
How do I know? Because they are widely used, and they DO work much better. As easy as that.
This is not a technical assessment, meaning: if all three protocols (plus ActivityPub) can succeed in getting a message to a user (using MIME for SMTP, SDP for SIP, and XML for XMPP), they are all equivalent. If all of three can do it while also describing the type of message , they are equivalent.
Still we must admit that some aforementioned protocols have created huge ecosystems and hundreds of applications, while ActivityPub seems to be relegated to a very few applications aimed at mimicking GAFAM, and nothing more.
Even worst, the scenario is boring: there are very few functional and ‘complete’ applications. The usual Mastodon, Pleroma, Misskey, Mobilizon, etc…. everything else is aborted in development.
Now your question might be: but if they are all equivalent, what are you complaining about?
Learning curve: the first point is that learning SMTP is simple. Encryption aside, anyone can open a terminal, and using telnet send an email message.
So writing a library that uses SMTP is easy. It’s easy to use, and it’s easy to troubleshoot. In fact, if we write an application that uses SMTP, we have a 99.99% chance that it will work. Same for SIP or XMPP.
Can ActivityPub say the same?
No. ActivityPub has the worst learning curve since ancient Etruscan.
The documentation is terrible. Initially the W3C “standard” was hosted on a page that answered 404 and explained nothing. It was the offspring of another standard, ActivityStreams,where “delusional” was an understatement: https://github.com/go-fed/activity to describe it.
The whole implementation sizes MILLIONS of lines of code. How a human being was supposed to learn it in full?
Yet this is the first problem with ActivityPub: the learning curve is so catastrophic that a single programmer CANNOT use it but for professional reasons (your free time will NEVER be enough to learn such a moloch). This way, ActivityPub lost all the programmers who do not have a team and also all the hobbyists who cannot dedicate their whole life to it.
For this reason alone, a decent ecosystem will NEVER be born, and the few developers are consortia of people and/or people paid full time for this. The number of aborted applications created by individual programmers or small groups, which have stopped at the “federation” stage, makes the problem clear: ActivityPub sucks.
The documentation sucks.
If you are looking for documentation on ActivityPub, you will find two kinds of websites: those who explain (in an endless lecture) what the protocol does, and those websites that show you an example (always the same) of a basic thing. It goes without saying that “basic thing” is not enough, and it does not give you a clue. At all.
(I leave out the third kind of websites, the ones who makes examples too complicated to be examples, because wasting time with idiots makes no sense.)
The lack of documentation makes even harder to use the protocol, let alone its utterly over-complex design.
The protocol description sucks.
Whoever described this protocol was probably spoiled by XML. He then defined a protocol as a protocol description, leaving so much freedom to the implementer that even mainstream platforms struggle to federate with each other, and don’t even agree on what to federate. Not all reactions are federated by everyone, there is no agreement on the groups, and this is because the protocol has been poorly described.
I can write a SMTP protocol library and I know it will work with 99.99% of implementations. Same for SIP. Same for XMPP.
ActivityPub cannot say the same. It MAY work.
Why has such a disaster become so popular? The problem arises with the ignorant script-kid who is calling himself “full stack (exchange) developer”. Among all the “fluency” on languages and tools they claim in their resumee, there is none they really know in deep.
So what do they do? How the pay their bills?
They go to StackExchange looking for the solution for a problem they have , say, in PHP.
They don’t find how to do it in PHP, but they find how to do it in Ruby. Instead of studying PHP better, they add a piece of ruby to the program. And the dependency list grows.
Same, if they don’t find how to use Postgres a certain way, but find how to use Redis the same way, they are happy. Good. Your application now needs TWO databases! Postgres AND Redis!
This is how, before GnuSocial there were things like Diaspora, with their endless list of dependencies. Then comes Identi.ca and then Gnusocial, up to a product with few dependencies.
Except, as usual, GNUSocial has no documentation and the code is so chaotic that no one dares to touch it. So GnuSocial dies, sunk by its own bad practices.
After federation was a landscape of small communities (mostly south american communists , european anarchists , vegans and other freaks you won’t be friend with in real life) , someone tried to make order and created Mastodon.
At that time Ostatus was enough, but it was too “adult” as a protocol to resist. Learning curve was little. After years , the protocol was pretty much known.
Because the second generation of “federators” didn’t just wanted to create a platform federating with the others.
Each of them wants to make the platform that replaces the others and become a monopolist. This is the case with Mastodon.
When Mastodon joined the game and started to have competition, it needed a way to stop competition. And a hard learning curve was perfect
And welcome to ActivityPub , as “the Fediverse best protocol”.
Plus… let’s talk about the fact ActivityPub is replaced with Mastodon API when it comes to C2S. (Client to Server). Sure, it may seem the Mastodon APIs are better, buuuut… may you find a swagger of it? May you find a OpenAPI definition?
No.
Because, again, if this happens, the monopoly of Mastodon (or at least, let’s call it “incumbent”) would end, if almost everybody was in the condition to create something similar. So the Mastodon API are documented in a way which requires a shit load of man-days to understand and implement. The harder as possibile.
Conclusion: the ActivityPub is a betrayal.
The betrayal of the principles (no vendor-lock-in, freedom, welcoming to new developers, etc) people claims it is sponsoring. Every implementation is “open source” in theory. If you try to learn it as such, you’ll meet the kind of troubles you find are very similar to the ones you may find with a Microsoft Proprietary Product: hard learning curve, lack of documentation, implementation too complex and unreadable for a single human developer.
So far, I like the approach of “Delta Chat”: reusing good and known protocol in order to create a new product.
To me, the best possible protocol for federation is SMTP, and if you like to follow, say RSS.
Simple protocols, documented protocols, short learning curve protocols.
