If you’re interested in free/libre software, you have probably heard of things like Matrix, Mastodon, and slightly more probably, BlueSky. If you haven’t, the short version is that they are, to varying degrees, decentralized platforms for communications.
Despite looking nothing alike on both technical and visual levels, these platforms share an abstract goal: allowing people to communicate freely, without having their data stored and used by tech giants for advertisement.
While traditional socials pay for their costs with advertisements, decentralized platforms work by offloading the cost of infrastructure to their users. There is, theoretically, no “central” Mastodon server, which the platform creators have to pay for, but a variety of servers (“instances”), run by community members, which communicate together as they use the same protocol. The server code is, theoretically, built to be so lightweight that anyone with a cheap VPS or server can run it (more on that later), so many instances are open to the public and happily survive thanks to the donations of users (or the instance admins’ parents).
Sounds cool, right? The companies that run the mainstream web platforms like Twitter or Instagram are known to do all sorts of nasty things with user data, and moving to lesser-known, but still centralized, platforms doesn’t guarantee that they won’t eventually end up in the same spot. Decentralized platforms, on the other hand, are more resistant to the threat of greed, as server admins can just refuse to run code with anti-features if they’re implemented upstream.
So why aren’t we all chatting on Matrix? Liking each other’s Mastodon posts? Out of the protocols I’m talking about today, only BlueSky seems to have gained any kind of popular recognition, but it still only has 36 million total users at the time of writing, which is not even 1/7th of Twitter’s daily active users.
Although I can’t claim to be an expert, I’ve used all platforms, and I’ve run, at least for a while, my own server for each one. So, let’s try to see what’s up with them.
ActivityPub: Honestly, it’s just not that good
ActivityPub is the OG decentralized communications protocol for Twitter-style social networking. It was released in 2018 by the W3C, but it has been around since 2016, together with Mastodon, the most well-known software that uses it.
Mastodon is somewhat known in tech circles: many FOSS projects use it to share updates and communications, but it seems not to have gathered much interest from the rest of the world. Every stats page for ActivityPub will tell you the same story: it received a small boost in popularity during the Twitter takeover by Elon Musk, but it has been in a steady decline ever since.
The federation is janky
If you have ever used ActivityPub-compliant software, you may have noticed that the comments section for the same post looks very different when viewed from two different instances: you may see some comments in one, and different ones in another. That is expected behavior and can’t be fixed without significantly altering the protocol. If your jaw hasn’t already dropped to the floor, you may need to read the paragraph again.
ActivityPub servers don’t know each others by default. When a new instance pops up, it has to figure out what other compatible servers exist on the network, but since there’s no central index, it will do so by “federating” (communicating) with other servers as their users interact with them.
To make things worse, content in ActivityPub is rarely served on-demand. The “inbox/outbox” system of ActivityPub makes it so that servers will push updates (like new posts, comments and reactions) to the ones they’re federated with, but it’s very difficult for servers to pull historical data, like old posts.
The comments you don’t see in Mastodon are from accounts whose host doesn’t federate with yours, or whose connection with your sever has started recently. The profiles you can’t find when using the Search feature have the same problem.
I don’t need to explain how detrimental this is to communications, and to the entire protocol as a result.
The ecosystem is fragmented
Someone found the courage to write this paragraph in Wikipedia’s page for ActivityPub:
ActivityPub implementations have been criticized for missing replies and parts of reply threads from remote posts, […] However, this isn’t a problem with the ActivityPub protocol itself, but with implementations not refreshing their content for updated data when needed. [citation needed]
That’s funny. Not only because it’s false, but because, even if it were true, it’d be still a terrible look for ActivityPub. I probably didn’t need to point this out, but the “citation needed” flag is extremely poetic.
Mastodon is basically the flagship implementation of ActivityPub, and it has this issue. As a matter of fact, I’m not aware of any ActivityPub-compatible software that doesn’t have it, but please let me know in the comments if you do.
But this is a great way to show one of my pet peeves with ActivityPub: people will always tell you to switch to another implementation. Mastodon is too heavy and slow to run? Try Pleroma. Pleroma lacks features and the client is an eyesore? Try Akkoma, the newborn fork that emerged after some internet drama with the Pleroma dev. Is it any better? Barely. And they dropped DMs because they didn’t like them. Try Sharkey (a fork of Misskey) next. It won’t work better, but at least you’ll get to complain about something else. Have you tried SoapBox? It’s a beautiful client (it looks like Twitter), but the developer is gradually moving most of his efforts to Nostr, the cryptobros platform that I am so repulsed by, I’ve decided not to even talk about here besides this very mention. And neither of these implementations can fix the underlying problems with the protocol, which we’ve talked about.
I really wish I was making this up, but the ActivityPub community is full of this people. Again, try explaining to your mother, or even an artist who wants to leave Twitter behind, that they should install the Tusky client for Android, because the official Mastodon client isn’t that good.
Let me be clear: I’m not against alternative implementations existing, or people playing around with them. All I’m saying is that you should only have to use them if you want to, you shouldn’t be forced into using them because the flagship implementation is barely usable.
For the normal user, which these platforms also claim to be targeting, the slightest bit of friction can be a show stopper. You may care about privacy so much that you ignore that the social you’re joining has a fraction of the user-base or lacks any kind of algorithm to recommend you interesting posts, but it’s hard to find someone that will tolerate the kinds of jankiness that seem to be bundled with ActivityPub.
Matrix: Can we give up please
Matrix is the messaging equivalent of ActivityPub. Introduced in 2014 and developed and improved ever since, it’s the thing that FOSS projects use when they don’t want to use Discord or IRC.
It’s a lot more corporate than ActivityPub: not only does it have the Matrix Foundation behind it, it’s also powered by a for-profit company, the cartoonishly evil named New Vector Limited, developing the reference implementation client and servers, which allows them to get funding by, for example, running enterprise instances for companies and organizations, like Raytheon (??) Boeing (???), NATO (????), or Germany (!?!?!?).
You may think that if it’s good enough for US defense contractors, it’s probably good enough for you. But don’t be fooled. You won’t find any Boeing employee leaking military contracts in Matrix rooms that seamlessly federate with your servers. Those solutions are not for federation, they are for internal communications on a platform that is usable, white-labeled, but most importantly to them, end to end encrypted.
Not all the improvements that are made for them will trickle down to your server. Matter of fact, they probably won’t, thanks to tricks like Synapse Pro, the solution that gatekeeps the Rust patches that drastically improve the performances of Synapse (the reference implementation Matrix server), which is written in Python.
I’m not usually for programming language wars, but I do strongly believe that if you’re trying to build a fast, efficient and scaling messaging solution that low-budget nerds are supposed to run on their hardware, you should stay as far away from Python as possible. The folks at Matrix also seem to acknowledge this, since in 2019 they started developing Dendrite, the “second-generation” Matrix server, written in Go and much more efficient.
But in 2023, the Matrix foundation transferred the duty to develop the reference implementation servers, including Dendrite, to New Vector. The company started sort of “quiet quitting” on the Go server, which is now barely updated at all, and has not seen a release in six months at the time of writing.
Someone could speculate that abandoning Dendrite perfectly aligns with New Vector’s incentives to sell Synapse Pro, and I wouldn’t blame them for it.
Matrix is painful to use
Whether you’re an instance admin or a regular user, Matrix is extremely painful to use.
Running Synapse? Get ready to have your RAM and storage taken hostage. Even if you run a single-user instance that a XMPP server running on an Atari 2600 could have handled, Synapse is so inefficient that you will start regretting your life choices. Don’t forget to manually clean the Synapse database once in a while!
Running Dendrite? Your server won’t look like it’s mining Bitcoin, but you’ll miss out on most of the improvements that are being done to Synapse. You may think they don’t matter, but Matrix has been having some real improvements lately, and running Dendrite largely excludes you form them. For example, Synapse now has “faster remote room joins”, which allow users to join room without having their server completely validate the room state from scratch, an operation which used to take tens of minutes for bigger rooms. Dendrite hasn’t implemented them at all, which, needless too say, makes user experience much more pitiful.
Are you just an user? Element, the reference implementation (and only feature-complete, AFAIK) client, is built with Electron and poorly optimized. Again, I’m not for framework wars, but you will start to feel it very soon: Element takes up much more storage than many other chat apps, and is noticeably less responsive.
And if you’re a developer, who wants to build on top of the Matrix protocol, you’re also in for some fun! The protocol will get in your way, especially if you’re trying to build a secure app. Check out the notes left by the FUTO team, who was building an encrypted social network on top on Matrix, shortly before dropping the project.
Matrix has an image problem
Matrix has been around since 2014, and it has failed to manifest into a single product that people like to use ever since. It has improved, but it has done so too little and too late.
The Foundation and New Vector have been working to clear up the tarnished reputation of the protocol, in what has been amusingly named Matrix v2. It does bring some very real improvements, like Element X, an experimental client built with Rust that is eventually going to replace Element, and which I really think is the best way to interact with a Matrix server so far, even though it’s not feature complete yet.
But again, it’s too little and too late. Issues with key syncing in encrypted rooms are so frequent that the “Unable to Decrypt” errors have basically become a meme. Many people I know have tried Matrix, seen how annoying it is to use, and given up on it.
Matrix is also losing the sympathy of the FOSS community, ever since the development of Synapse and Dendrite was transferred to New Vector. Independent server implementations do exist, but since Matrix is designed to have lean clients and fat servers, they are slow to catch up on all the features, and despite all the efforts, they’re just not there yet.
Can we please stop with the names salad
Element is the reference implementation client for Matrix, and it went through a couple of names: Vector, when it was first released in beta, then Riot, and finally, Element.
I hate these names (including the current one!) with a passion. They are all extremely non-googleable terms, which have little to nothing to do with communications, or Matrix itself. I also think that naming “Riot” the product you want to eventually sell to Boeing is completely insane, but I digress.
The Matrix name is extremely stupid into itself. I don’t need to point out all the reasons why, but I can tell you about the funniest one. In late 2024, news broke out that a chat service called MATRIX (in all caps), which was used for illegal activities, had been compromised and taken down by the Dutch police. Obviously everyone went completely nuts, several online media outlets mistook the different Matrix platforms (since Matrix Foundation’s is the one that pops up when looking for “Matrix messaging”). It turns out the MATRIX thing that had been shut down had nothing to do with the decentralized Matrix we’re talking about, the Foundation probably had to send some emails which had “[URGENT]” in the title and write a blog post in a hurry to distance themselves from the cyber-criminals.
You may think I’m yelling at clouds here, but try to put yourself in the shoes of the average Joe, who has just casually heard of Matrix and wants to maybe communicate securely with his family. You’re not going to open Google and search “Matrix protocol”, then learn about the various clients, figure out that Element is the reference implementation, install it and be happy. You’re going to open the PlayStore and search “Matrix”. You won’t find it, of course, because there’s no Matrix client called Matrix, and Google assumes that people who are looking for “Matrix” want to be shown apps for matricial calculations rather than a messaging app called Element. That’s one less user.
BlueSky: the closest we’ve got to a success story so far
As I’ve mentioned in the beginning of the article, BlueSky and its protocol, ATProto, are closest thing we’ve got to a decentralized communications success story.
BlueSky, like Mastodon, is a new take on the idea of “what if Twitter wasn’t owned by an egomaniac”, and it gets a surprising amount of things right.
BlueSky is more of a product than a protocol: BlueSky Social PBC (Public Benefit Company), the entity that operates the social network, is the same one that develops the underlying protocol, ATProto, and it does so with the clear intent of advancing BlueSky first, and the rest of implementations eventually.
I know of people who dislike this approach, but honestly, I’d rather see this than Matrix. With this structure, the folks at BlueSky can move fast and implement changes as the need for them comes, without having to deal with the administrative slop of having to open Spec Change Proposals or anything like them.
BlueSky solves some of Mastodon’s issues with centralization: BlueSky PBC operates relays that aggregate the updates generated from individual instances, and display them in a neat way to users.
This little trick allows BlueSky to have network-wide search and federation, while maintaining server code for self-hosters reasonably lightweight and easy to run.
The obvious downside with this system is that BlueSky users are still entrusting a critical part of their communications, which is, by design, very expensive to run, to a third party. Honestly, I’m okay with it. Users have been able to replicate those parts, even create alternative implementations from scratch, and the BlueSky PBC is providing what some have called a “credible exit strategy”, a plan to make ATProto more independent from the PBC, once the protocol is more stable, in order to keep it safe from corporate interest.
If you have a bit of free time, I recommend you read this **blog post** by Christine Lemmer-Webber. She is way more qualified than me to talk about these topics, having worked on ActivityPub, and she provides a very interesting prospective on the issues with BlueSky and decentralization.
I do think that some of the issues raised in the article are not that relevant. Yes, running relays is very expensive, but it’s not outside the realm of possibility of your rich nerd with an overspec’d homeserver in their basement. There’s already at least one ATProto relay which is not run by the BlueSky PBC. Yes, the identity system of BlueSky requires that you either trust ICANN for did:web handles, or BlueSky itself to manage the did:plc directory, but the same issue applies for probably every single other federated social network: ActivityPub usernames end with domain names as well.
What I think no one can argue about is that BlueSky is doing a terrific job at being user-friendly and frictionless. You can even search for “BlueSky” in the PlayStore, and you’ll find the official client!
BlueSky is easy to use, it has a beautiful default user interface, and its decentralization is basically transparent. I’m willing to bet that most users don’t even know how BlueSky works besides “it’s an open network”, and that’s honestly how it should be: most people don’t care about decentralization, they’re on BlueSky because they want to look at cat pics and not get their data harvested in the meantime. And that’s perfectly fine.
Meanwhile, folks like me can have fun with all sorts of unofficial projects like deer.social, the AppViewLite, Atmo.Lol and whatnot. The important thing to note is that these projects don’t exist out of spite, because the flagship implementation is bad, but because someone thought it’d be cool to get them running.
What will happen to these platforms?
Time to pull out my magic ball and speculate a bit on the future of things.
ActivityPub
I see a future of existence, but irrelevancy, in ActivityPub. I don’t foresee a sudden drop in popularity: ActivityPub is not actively becoming user-hostile like Twitter, it has always, in its own little way, been. I think it will remain vaguely popular in techie circles, there’s still going to be a good amount of instances, but the active user count will hardly ever surpass what it was during Elon’s takeover of Twitter.
I’ve heard of ActivityPub users who are happy with their platform not becoming mainstream. I personally don’t agree, as I like my timeline to have art, entertainment, and a variety of content, not just tech stuff, but I see how someone could still enjoy Mastodon as a “small” social network.
Matrix
I foresee poorly ironed suits and cigarette smell in the future of Matrix. New Vector will continue to focus on the commercial partnerships, the only reliable sources of income for the corporation. Maybe it will be more successful than ever in that field, and become an industry standard, but I have no such hopes for the Matrix open protocol in general.
I think (or, rather, hope) we’ll see something new in the space of federated messaging. With Matrix practically stagnating in popularity, and big platforms like Telegram and Discord getting more and more annoying to use every day, thanks to Pro plans and AI features being shoved down users’ throats, I think the demand for a decentralized alternative does exist. We’ll just have to see how long it takes to manifest itself.
BlueSky
Only time will tell what will happen to BlueSky. While I unironically think that my predictions for Matrix and ActivityPub will be accurate, it could go either way for BlueSky.
Right now, the BlueSky Social PBC is burning money. Servers, developers and moderators don’t pay themselves. Although the company has been trying to monetize through the sale of custom handles (basically reselling domains, since BlueSky handles are mostly TXT records), and comically overpriced t-shirts, they are obviously not in the green yet. The company has already talked about potentially implementing some optional premium features, which I’m honestly okay with as long as they don’t start restricting the openness of the network.
I hope BlueSky will be able to figure out a way to become sustainable soon. BlueSky is the only of the services in this article which I have any hope for, and it’s the only service for which my instance is still online. I’m very aware that things could go south with it very quickly as long as the BlueSky PBC remains both so vulnerable to external influence and so tied to ATProto, so I remain ready to jump ship at any time, and I have chosen not to build anything on top of the protocol yet.
What about [NAME]?
You may be wondering: “What about [NAME]? “. Worry not. I have all the answers.
Keep in mind that I’ve tried these platforms less extensively, so I might be wrong about some stuff. Please correct me in the comments!
- XMPP: Extremely fragmented ecosystem. The core protocol is lackluster and there are a bazillion extensions, which are optional, there’s no reference implementation server or client, so for each feature that is available on your end, you’re wondering whether it will show up correctly at the receiver’s side.
- Session/SimpleX/Literally anything without free human-readable usernames/Literally anything with Tor: They may be cool for buying drugs online, they are not usable enough for normal people.
- Literally anything based on a blockchain: If you plan on storing posts and data on the blockchain, we should talk about the terrible idea that is undeleteable public records in the context of social media. Think of revenge porn. If you are just planning to use blockchain nodes as infrastructure, we should talk about how cryptobros are pushing for a dystopian future where everything is commodified and sold at a price.
- DeltaChat: It’s an interesting idea, since it’s based on email, the decentralized communications standard which is by far the most popular. Unfortunately, it’s also a very annoying one. Running your own server is famously a pain, and some of the mainstream providers don’t work too well with DeltaChat. GMail is one of them, as it requires some prep work, which is going to be already too much friction for a bunch of users. It also supposedly doesn’t work that well with large groups. I still see it as a good option for users in countries with strict censorship, where email can “fly under the radar”.