Bluesky, decentralisation, and the distribution of power
Bluesky has seen a large inflow of new users following the results of the US election, and a significant amount of media attention as well. All that attention to Bluesky has also led to a renewed conversation around the question of whether Bluesky is decentralised or not.
The terms decentralisation and federation are used in multiple ways: to describe the technological architecture details of an internet protocol, but just as often as a shorthand to describe whether or not a (digital) network is open and not under the control of a central authority. The second definition is the one I care about: I write about decentralised social networks because I care about an internet that is open, accessible, and not under the control of a few tech oligarchs. My interest in federation and decentralisation is pragmatic; I view it simply as the most likely option of getting there.
Once you view decentralisation and federation as tools to achieve a more equal power structure of the social web, conversations about Bluesky and decentralisation can become clearer, as there are multiple dimensions at play.
Technological decentralisation
The first dimension is technological, and the questions here relate to the architecture that the network uses. The concerns here are around the implementation of ATProto, the protocol that powers the network that Bluesky is a part of. This network is called the ATmosphere, and it includes Bluesky as well as other apps that use ATProto, such as Frontpage.
Technological details matter, as small decisions can have large impact on power and authority, but I’m not looking to hash out all of the details in this post. What I do want to point out is that even on the matter of technology there are multiple aspects to it:
- Are we talking about Bluesky the microblogging app, or the larger ATmosphere network?
- Are we concerned about whether decentralisation has happened, or whether it is possible?
It turns out that once you start peeling back the layers of the technological side of decentralisation, more and more questions start to arise. This is because ATProto splits up the network into separate components, and makes each component open and accessible for others to use and run. This is good for making the network more decentralised, but funnily enough it makes understanding decentralisation all the more difficult.
Taking control of your own data on ATProto is possible by hosting your own PDS. Building and hosting your own app on ATProto is possible. Streaming data from the entire network is possible by running your own Relay. Verifying digital identities and owning one yourself is possible.
All of these options are possible, and people are doing them to a varying extent. But a single, agreed-upon definition of ‘once ATProto conforms to these specifications it counts as decentralised’ is not available.
Social Distribution
Decentralisation is a way to distribute power, and power is gained by people bestowing it on you. Technology changes the ways power can be distributed, but it is a sideshow to the thing that matters: where are the people, and on whom are they distributing power.
The above conversation about the technological side of ATProto matters much less than how people actually use the network. Here it becomes clear that for any meaningful way to describe distributed power, the ATmosphere is not decentralised at all: over 99% of people exclusively use infrastructure that is owned by Bluesky PBC.
The technology allows for decentralisation, and there are other parts of the network. But the user count for the other apps is in the thousands at best, compared to the tens of million for Bluesky. Even the other apps that do exist reuse infrastructure owned by Bluesky. While they could run their own relay instead of using Bluesky’s relay, why would they spend money when they can also not spend money?
Furthermore, what the protocol affords is not equal to what the average person can actually use. ATProto allows people to take full control of their own data by either self-hosting their PDS or using a hosting provider.1 Doing so currently requires technical knowledge: easy from the perspective of an experienced programmer, but out of reach from the majority of the population.
Structure and structureless
Control and authority in decentralised and distributed systems is a hard problem to solve. In the Tyranny of Structureless, Jo Freeman writes:
“This apparent lack of structure too often disguised an informal, unacknowledged and unaccountable leadership that was all the more pernicious because its very existence was denied.”
I took Freeman’s quote from this essay about systems design, which adds2:
“‘Informal, unacknowledged, and unaccountable’ control is just as common in distributed computing systems as it is in human social systems. The truth is, nearly every attempt to design a hierarchy-free, ‘flat’ control system just moves the central control around until you can’t see it anymore. Human structures all have leaders, whether implicit or explicit, and the explicit ones tend to be more diverse.”
Decentralised social networks are capable of distributing power to a certain extent, but control does pop up in other places. The fediverse is very decentralised with over 30k servers, but virtually all software is dependent on the Mastodon API, and every Mastodon competitor quickly realises that implementing the Mastodon API is mandatory in order to be part of the fediverse. The Mastodon API is not part of the ActivityPub protocol, and the code is owned by a self-styled dictator for life. Every human structure has leaders after all, and in the case of the fediverse, it is more implicit.
ATProto has chokepoints too, but what stands out to me about them is that they are so much more explicit:
- There is the development of ATProto itself: the protocol is open-source, but it is clear that it is the Bluesky company who is doing the development work
- Within the protocol there is the PLC.Directory, which is effectively a giant address book of everyone on the network.
These two chokepoints show that Bluesky PBC has some centralised control over the ATmosphere. But the explicit nature of the control points also makes it easier to deal with them by recognising them for what they are. It also indicates that technological decentralisation might not always be the answer, and that we can look for other ways to make sure that control over critical infrastructure is done in an democratic manner. Bluesky PBC is working towards bringing the PLC.Directory under control of a different organisation. Although it is not clear yet that which organisation that will be, Bluesky PBC is looking for an ‘ICANN-style’ consortium.
Incentives
Networks do not become decentralised purely by having a technical architecture that enables decentralisation. The people who together constitute a network need to have incentives to organise themselves in a manner that results in a distribution of power. On this front, Bluesky has an attractive value proposition for start-ups that are looking to launch a social product: Bluesky comes with a multimillion user social graph that new apps can plug into and build on top of.
This makes the ATmosphere much more likely to become decentralised the more the network grows in popularity and Bluesky becomes a household name. Building Instagram on ATProto is just such an obvious idea that every techbro is going to try it once the realisation starts to settle in what ATProto actually enables. 3
Assuming (still an if!) this comes to pass, conversations about decentralisation and the distribution of power in the ATmosphere will start to look quite differently. In a situation where there are multiple apps in the network, power is decentralised and distributed between the owners of these apps. That would create some type of decentralised power structure of the broader network, but not necessarily one where the power of Bluesky the microblogging app is concerned.
So while competitive incentives might lead to a decentralised network, it might not necessarily lead to decentralised microblogging within that network. Not everything needs to be left to market forces however. We can built other, cooperative structures that lead to an even better distribution of power on the ATProto network, and fully intend to pursue that direction further.
- A Personal Data Server, which stores all your data on the ATProto network. ↩︎
- I found out about this article via this post by Bluesky developer Jaz, which seems relevant here. ↩︎
- I use a custom feed on Bluesky to count how many people have posted this idea as a suggestion, and it’s a lot. Wish I had kept screenshots. ↩︎
Bluesky, decentralisation, and the distribution of power
Bluesky is building a decentralised social network. But how does decentralisation lead to a better distribution of power?fediversereport.com
L. Rhodes
in reply to Laurens Hof • • •I'm not really sure what it would mean for a person to "take full control of their own data" in the context of the ATmosphere. Running your own PDS lets you /manage/ your own data, but the network is structured such that doing so is virtually useless unless you're making your data available to a relay, at which point it's back out of your control again.
There may be benefits to running a PDS, but I don't see how they have much to do with concerns around data security or ownership.