How decentralized is Bluesky really? - Christine Lemmer-Webber

ActivityPub co-author Christine Lemmer-Webber "often get asked whether or not I have opinions about ATProto vs ActivityPub... I do ... but I am usually head-down focused on building... [and] anything I had to say on the subject would not be received productively". But, encouraged by a core Bluesky developer, here is her longread.

It's too long to summarise completely, so I'm going to just grab some key points.

" Under these definitions, Bluesky and ATProto are not meaningfully decentralized, and are not federated either:

• "Decentralization is the result of a system that diffuses power throughout its structure...
• Federation... technical approach ... achieves decentralization by many independent nodes cooperating and communicating to be a unified whole, with no node holding more power"

Bluesky's still useful: while they're not building a decentralized Twitter, they are building an excellent replacement - unsurprising, give that their original goal was to create "a decentralized protocol which Twitter could adopt. This informed a lot of the initial architectural decisions".

The main goal, however: "a Twitter replacement, with the possibility of "credible exit... (Bluesky's own term)". Unlike "the present-day fediverse ... Bluesky uses content-addressed content, so that content can survive if a node goes down...... possible to also do on the fediverse, but is not done presently."

However...

Decentralisation theory vs practice.

She uses Google as a great metaphor for Bluesky. After all:

• "Bluesky's developers have described Bluesky as being a bunch of blogs aggregated by Bluesky as a search engine"
• While a few "people are running Personal Data Stores ... Bluesky may have the appearance of being decentralized"
• But "there's really only one ... Relay and a (Twitter-like) AppView", although in theory that could change
• but, as the Google Reader story shows, "having one big player enter the room and then exit effectively killed" the blogging+feeder ecosystem that was the decentralised social web before social media walled gardens appeared.

Economics

Running both a Fediverse node and an ATProto PDS is cheap, but they're not comparable things. A Fediverse node is a fully functioning instance participating in the network. There are 1000s. However, "In July 2024, running a Relay on ATProto already required 1 terabyte of storage", which then jumped nearly "5x in just four months". As Bluesky grows, so will the cost to each Relay - they'll all be spending big money.

Why? It comes down to the architecture:

• ActivityPub is message passing like email & XMPP, all client-server architectures (although she's working on making it more p2p). So "if only users on five servers need to know about a message... only those five servers will be contacted", despite the network having 10000s of nodes
• "Bluesky ... instead operates in what I call a shared heap architecture... letters which may be interesting are dumped at a post office (called a "relay") ... interested parties ... filter through the mail to see what's interesting to them... there is no directed delivery"
• cf "Secure Scuttlebutt and Nostr, where missing message replies are even more common than on ActivityPub... in SSB you fetch the feeds of your friends and 3 degrees removed ... In Nostr you simply "embrace the chaos" of only grabbing the information from hubs you use"
• "Bluesky solves this problem via centralization... one very large relay ... [with] a god's-eye knowledge base". The AppViews pull from the relay and "sort through mail and relevant replies for users... any other services which participate in the network must operate at the level of gods rather than mortals"
• So while ActivityPub's architecture allows for what in the physical world would be "every user sends mail to every other user's house", in a "fully decentralized ATProto... every user .... stores a copy of every piece of mail delivered to every other user... A world of full self-hosting is not possible with Bluesky... [beyond] the storage requirements... message delivery requirements become quadratic... Rather than writing one letter, a copy of that letter must be made and delivered to every person on earth".
• While Bluesky "does acknowledge this, to some degree... "Small bespoke Relays could also service tightly or well-defined slices of the network, like a specific new application or a small community"... smaller bespoke relays would have a greater problem with missing message replies than a directed message-passing"

Apart from costs, there's also "legal liability ... [of] effectively hosting the equivalent of all of Twitter", quoting Bluesky: "the Relay performs some initial data cleaning (discarding malformed updates, filtering out illegal content and high-volume spam)". So "there will always have to be a large corporation at the heart of Bluesky/ATProto, and the network will have to rely on that corporation to do the work of abuse mitigation".

Nuance

I really liked the nuanced take she took, taking pains to point out that "It is not a bad choice for Bluesky to be focused on providing an alternative to X-Twitter for those ... looking for an offboarding from an abusive environment", and there are levels of decentralisation: " it certainly seems more decentralized than Twitter, the same way that Twitter may seem more decentralized than cable news. Things are sometimes more decentralized in degrees".

But she concludes that Bluesky is not decentralized "within any reasonable metric of the power dynamics we have of decentralized protocols which exist today, and it does not use federation in any way that resembles the way that technical term has been used within decentralized social networking efforts", so she's personally sympathetic to the phrase "federation-washing... people are gaining the impression that it's a decentralized system in ways that it is not... [and so] might believe there's an "easy decentralized way to do things" ... [but] Bluesky could collapse at some point and that people might walk away with the impression of "oh well, we tried decentralization and that didn't work... remember Bluesky?"

Instead, she would prefer them to describe themselves as having "an open architecture ... with the possibility of credible exit" - if the Bluesky company "goes out of business or loses users’ trust, other providers can step in ... using the same dataset and the same protocols".

More key points

• "most of the architectural assumptions assume public messages only... even blocks are public information" - unlike ActivityPub by design, as "sharing such information could result in harassment". This might change, but it will be difficult because "early architectural decisions can have long-standing architectural results"
• DMs are private because... they're centralised: "All direct messages... go through Bluesky, the company... [and] not end-to-end encrypted" (ActivityPub DMs aren't encypted either).
• There are problems with Bluesky's "use of Decentralized Identifiers (DIDs) for account migration... [including] Even if a user wishes to switch away from Bluesky's infrastructure, Bluesky probably has effective permanent control over that user's identity destiny, removing the reassurance that one need not trust Bluesky as a corporation in the long term." She provides some history and then analysis to back this up. I'm keeping:
  • "a DID method mostly provides ... a mechanism by which cryptographic public keys can be registered, retrieved, and rotated"
  • decentralisation is not a requirement - "blessing DIDs which were centralized as "Decentralized Identifiers" ... [is] decentralization-washing"
  • "Bluesky has developed its own DID method, did:plc... Bluesky hosts a web service from which one can register, retrieve, and rotate keys... centrally controlled by Bluesky." They're looking at this, perhaps moving "to an ICANN-like organization... did:plc was meant to be a placeholder
  • "Bluesky PDSes hold these signing keys custodially on behalf of users... other PDS operators are free to use different methods... even if users "move away" they must trust Bluesky to perform this move on their behalf... even if Bluesky delegates authority to that user... Bluesky will always have control over that user's key, and thus their identity future"
  • Overall, she concludes that "if a hostile company were to take over Bluesky", things won't work out well. However, "perhaps actually decentralized identity solutions can be layered on top". Until then, trust Bluesky.

She ends with some suggestions for how the Fediverse should evolve, based on an " ActivityPub + OCaps ... proposal ,... which I co-submitted with Jay Graber when Twitter was still evaluating Bluesky proposals... . I put together a document called OCapPub a few years ago to present an alternative vision for how the fediverse should go".

Overall, both ActivityPub and ATProto need to "converge on a shared direction: the fediverse needs to adopt content addressing and portable identity ..., Bluesky needs to support a messaging architecture such that participating meaningfully ... not needing to host everything... adopting something that ultimately looks a lot like ActivityPub"

"the organization is a future adversary"

This is a phrase the Bluesky team uses about Bluesky PLC, which is them acknowledging the reality of taking venture funds, so the "right next step then is to start planning all work to survive". However, they have other pressures - scaling, returns, sustainability - beyond "Rearchitecting towards meaningful decentralization".

What about ads? "A common way to make premium accounts more valuable is to make them ad-free. But if Bluesky is sufficiently decentralized and its filtering and labeling tools work as described, it will be trivial for users to set up filters which remove ads from the stream", and when investors see that, expect the openness to disappear.

Hence they should focus on credible exit to prevent enshittification: "perhaps a large corporation or two always have to sit at the center of Bluesky, but perhaps also it will be possible for people to leave."

(PS there's also a great description of Nostr ... as "a more uncomfortable version of Secure Scuttlebutt for Bitcoin people to talk about Bitcoin").