Table of Contents
I've often been asked whether people could follow me on Bluesky, and the answer is no. I don't have that platform, and though I might join it in the future, I'd like to explain what makes me skeptical about it.
Bluesky as a company was born between 2022 and 2023, with a goal that shifted from building a protocol that Twitter could eventually use, to becoming its alternative and competitor to X.
Back then, ActivityPub - the protocol that powers the Fediverse, such as Mastodon - was already developed (obviously!) and had somewhat widespread usage amongst fans of decentralized systems.
However, Bluesky rejected the idea of using it (or bridging to it) and instead decided to build their own protocol, called AT proto. Why? Well, according to their documentation (we'll get back to this):
Account portability is a major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
Now, I've never been particularly sold on this argument. When talking about social networks, having an interconnected web of users is a priority to be successful, and building your protocol is a great risk. Is it worth refusing to connect with an already-existing community because switching one account to another server is not a great experience? Still, we'll come back to this point.
Another major reason is scalability. ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual nodes to be flooded with traffic and generally struggles to provide global views of activity.
This sounds more reasonable, though I don't have the skills to know whether this is a satisfying explanation or not. Let's assume it is.
Thus, Bluesky started accepting users through an invite-only system in early 2023 and soon offered an Android application as well. It's worth noting that, back then, the social network was fully centralized and run by the Bluesky company, which promised federation and decentralization to come soon.
It did: in February 2024, they published a blogpost announcing that they were allowing users to federate. However, the federation system that the AT protocol proposes is quite different from ActivityPub's, and it's worth getting a bit technical about it to understand the differences.
On the Fediverse, everyone can run their own ActivityPub instance. This could be Mastodon, which looks like a Twitter competitor, but it could also be Pixelfed (more picture-oriented), or Peertube (video-oriented). If you sign up at one instance, you can still follow and interact with people on other instances; thus, the Fediveres is an interconnected web of decentralized ActivityPub instances, which you can sign up for.
Bluesky works differently. Each user has its data, which is hosted in a Personal Data Server, or PDS. That data is gathered by Relays, which then "output it in one big stream for other services to use". The data goes through labelers, which handle the moderation (more on that later), and is given to the AppView (which might be any third party application), which can use various Feed Generation algorithms to decide the order to show them it.
This is a very different architecture compared to the Fediverse. There's no such thing as single instances talking to each other (a "message passing" system), but instead, there's a "shared heap" where all content gets thrown together into Relays.
By default, all of these services are offered by the Bluesky company themselves. However, you can go ahead and host yourself pretty much any of these components that I've mentioned, which renders the system decentralized.
Or does it? Let's start with PDSs. Yes, this makes it much easier to self-host your data: you'd be able to do it even on a very cheap or potato server. However, this only allows you to self-host your data, whereas all social network aspects are handled elsewhere. If we want a federated network, we're more interested in the other components.
Which brings us to Relays. Quoting Christine Lemmer-Webber, a co-author of ActivityPub,
The physical world equivalent for a fully decentralized fediverse then is that every user sends mail to every other user's house, as needed, similar to how sending letters works in the physical world. This is decidedly not the case with a fully decentralized ATProto. The physical world equivalent would be that every user had their own house at which they stored a copy of every piece of mail delivered to every other user at their house.
Effectively, this means that each Relay is required to bring at least 5 terabytes of storage and a significant amount of system and network resources; and it would still only have part of the data that's in the public heap. This means that you might end up missing messages in a thread unless you also fetch data from a bigger Relay.
On top of that, Relays are going to host any kind of content that's posted in Bluesky, and it's their responsibility to filter off illegal material. This also gives them a high legal burden to uphold.
Thus, one year after announcing that Bluesky is federated, how many third-party Relays are there? According to SoftwareMill, the answer is none:
Currently, there's only one relay operated by Bluesky (the company); however, in theory, there might be multiple ones.
The required storage is also growing very quickly, and it will keep growing as more users join the network. This means that, in the long term, it will get harder and harder to create an independent Relay, to the point where only companies might be able to. And, until then, Bluesky will still be run de facto in a centralized way.
Even worse, I have not found any figure about the number of Personal Data Servers running independently, but the general idea is that almost all of them (probably more than 99%) are run by the Bluesky company. This gives them even more (again, de facto) power over its user base.
Now, I've mentioned that labeling (which includes moderation for content that should not be displayed) is also decentralized, as in, everyone can run their labeler. Of course, Bluesky also runs its central labeler.
I can see the appeal of this system; as an example, there's an "AI images detection" labeler that will, well, label AI images. You can opt-in to use that, which is cool.
What's less cool is that the Bluesky application hardcodes its labeling system; this means that, if you want to opt out of the Bluesky company moderation system, you have to build your independent application to do so.
This effectively means that, if you get banned by the Bluesky company, you're out. Sure, you could still host your own Personal Data Server, wait for a non-existent independent Relay to fetch your data and interact with users of third-party Bluesky applications. But you won't: you're effectively at the mercy of the Bluesky company.
You might argue that it's Bluesky's right to ban someone entirely from their servers if they want to, but that becomes a problem if (a) 99% of the infrastructure is run by them, and (b) it's hard to provide an independent alternative. Then, you're effectively a centralized system.
There are a few other problems as well. Firstly, all private messages between users are centralized; they go through the Bluesky servers, and there's no way to self-host that service. They don't even claim the DMs to be federated, they only hope that they'll be able to change that in the future.
Secondly, the ID mechanism, which assigns each user with a unique key to keep track of them, is also centralized. This is already too technical for me, but Bluesky currently offers two "Distributed ID" mechanisms, called did:web and did:plc, both of which are centralized and controlled by Bluesky.
I think this is particularly incriminating since the reason they wanted to provide an alternative to ActivityPub was to make it easier to transfer your data to "a different instance". I guess that's true since it's easy to self-host a PDS, but the ID that's associated to your data, and by which you're indexed by, is still centralized and controlled by them. In my opinion, that's worse than "it's hard to move data between instances".
Thirdly, Bluesky is unable to handle private information; everything is public on the giant heap. This does not include private messages, because - again - those go through a different centralized system, but it does include other information you'd prefer not to have public, such as who you blocked.
Overall, the Bluesky "federation" promise relies on two main points.
Point one: it's going to be decentralized later. When creating Bluesky, the most important thing was to provide a viable alternative to Twitter as soon as possible, and that meant moving quickly; yes, some parts of the network are still centralized, but they won't be in the future.
Fine; I therefore think it's fair for me to wait until then before starting to use Bluesky. I don't need a Twitter alternative now. Nonetheless, I'm still not sold on the fact that it was necessary to build a whole new protocol at all, instead of assuming ActivityPub could not scale enough to be a viable alternative.
Point two, and more importantly: this approach provides an "exit strategy" in the event that Bluesky "goes evil". Right now, that's false: parts of the social network are still centralized and it's impossible to avoid that. But even if we limit ourselves to PDSs and Relay, the current situation is that federation is only achievable in theory and no one has done it in practice yet.
On top of the (IMO!) flaws of the AT proto approach, I think it's important to highlight some benefits of ActivityPub that are not translated well over Bluesky.
Let's start with a personal story. A few months ago, I was running an activity to explain to some boys and girls how to use social networks safely. As part of that, I decided I wanted to run a "private" social network, that would only allow sign-ups from people I selected; I looked into self-hosting some sort of social network, and turns out it's a mess.
However, since Mastodon is quite known software, it's easy to find a service that will set up the server for you, at a very low price; you can also lock down a Mastodon instance to make sure it cannot interact with other instances, if necessary.
But if I wanted to go on, I could've made more instances for other groups of my organization, and all of these instances could've interacted between them. Even better, the younger generations aren't really that into Twitter-like socials anymore, but I could've just set up some Pixelfed instances to give them an Instagram-like experience.
And there still would've been room to grow; some activities require videos, so there could've been a Peertube instance as well to host those, and it still would've been completely interconnected with the others. All of this would still be run entirely by me, which is a requirement since I (legally) need to keep an eye on what these teens are doing and be able to step in immediately.
This is something that I could've done today, not potentially in the future. And honestly, it would not even have taken that much effort: I'm just a bit lazy.
And, if we talk about "potentially in the future", there's even more cool stuff that might happen over time. I'm a big fan of existing social networks federating with ActivityPub; I'm really happy that Threads made this choice, but there's WordPress as well, and even Ghost - the blog system that I use - is working towards that.
I'm also really happy that all of my videos are automatically uploaded to Peertube, and that people on Mastodon can follow my channel there and automatically get the videos on their feeds.
Ultimately, the Fediverse feels to me like a better alternative all-around. I think user onboarding should be improved somewhat; but, if you were to ask me which social network I'd recommend, I'm not going to pick Bluesky. Quite the opposite: I view it as a centralized social network that jeopardizes the future of the (IMO) better alternative, the Fediverse.
