Or, what do we talk about when we talk about decentralization?
People were up in arms recently in Bluesky about the reported censorship of an account, on request of The Turkish government.
Some of this is justified: you want transparency, and it doesn’t seem like Bluesky did an excellent job of communicating what was going on or how they made the decision. Can users expect Bluesky to act like a dissident platform, prioritizing free speech at all costs, or will they comply with requests from local petty tyrants to avoid getting a blanket block by a regime?
Other complains, however, seem to come from a place of misunderstanding the architecture. People have gotten used to equating decentralized with *unstoppable (which no software project fully is, regardless of whether they do provide a censor a varying degrees of blocking difficulty). This came up again recently, with what availability issues caused by what I understand to have been a DDOS on the Bluesky-hosted personal data servers.
So let’s talk about architecture decisions and their impact.
Any architecture decision revolve around three things: what do you want to optimize for, what price are you willing to pay for that outcome, and what your threat model is.
A useful lens with which to view these decisions is that of the threat model: what potential problems are you worried about, and how should the system behave when they appear?
You’ll notice these are questions of system design. They tell you nothing about how that system may be used by the people in charge or those acting as end users, so we need to differentiate between ATProto and Bluesky PBC, which happens to be only one of the companies building on it (even if they do lead development right now).
Bluesky PBC is a centralized company and, while they may be benevolent at the current point in time, they are still subject to local laws. They have to make choices about if to censor a post based on a takedown that has legal standing in the country in which it was issued, or potentially lose access to a population altogether.
ATProto, the underlying protocol, encodes no such concerns or decisions. There is a measure of unstoppability to ATProto, but it isn’t geared towards ensuring you have reach into every possible geography, or from stopping Bluesky PBC before they implement any sort of censorship on their own site or mobile application. What ATProto provides is a design where people can always build around attempts to stop you from keeping your social graph or curtail your ability to communicate with users on the network at large.
Notice that word: network. It doesn’t merely mean “the microblogging network run by Bluesky PBC“, but the network of users and applications using the protocol. ATProto is designed with the threat model that Bluesky PBC might be the main adversary that the network faces in the future, to help route around it, and even in its current state it is already showing signs of such resilience.
Let me give you two examples.
The way that Bluesky complied with the Turkish order to make some content inaccessible in the country was to tag that it, so that it isn’t shown on the official Bluesky app for other users coming in from Turkey. Users from elsewhere in the world can still find it, as can Turkish users using alternate interfaces to access the network.
Furthermore, in theory they could have nuked a user’s account altogether, if it were hosted on their own servers, but as long as a user has the account on their own PDS (personal data server) only the key owner would have that right. Turkey could issue specifically-worded dictums about deleting a user’s entire content history, and those users running their own data hosting would still outside of Bluesky’s reach.
Second, during the recent outage, only PDSes hosted by Bluesky PBC were affected - others kept operating just fine. Sadly said third-party servers host a minority of accounts, but that’s not Bluesky’s fault - anyone can decide to migrate out at any point (although I grant it currently requires some technical knowledge).
It is up to us to ensure the network grows even more resilient, and I personally need to dogfood this by moving my own data off their PDSes. Remember: if you want an unstoppable network, this feature doesn’t simply “drop out” of the architecture - you need to help build it.