Beyond Decentralization
Power asymmetries have consistently driven the pursuits of egalitarian ideals. Some of them had lasting consequences: Athenian democratic reforms, the Gracchi brother's land reforms in Ancient Rome, the Venetian republic, the Peasants revolt in the Middle Ages, and the French Revolution are just a few examples.1
Power asymmetries tend to find new shapes and forms, which are difficult to detect in the early stages and nearly impossible to change later on.
The recent wave of digital decentralization movements is also driven by power asymmetries. In the social media realm, the abuse of personal data, algorithmic atrocities and political propaganda of Facebook, X-twitter, and other platforms activated the development of decentralized protocols like ActivityPub and alternative architectures like Solid.
Some power asymmetries may stay latent for long and do no harm. Twitter is a centralized platform that was exceptionally lucky to have benevolent dictators for so long. It attracted many users, including those sensitive to platform abuse. To a large extent, it replaced the traditional media. Then, it was exceptionally unlucky with its new owner, who quickly showed the ugliest effects of power asymmetries in social media and beyond.
Yet, that boosted decentralization efforts, supplying them with extra motivation, users, contributors, and even funds. Some say that those who curse Elon Musk should actually be thankful.
The most successful decentralized initiatives in the area of social media are Bluesky and Mastodon, using, respectively, the AT protocol (atproto) and the ActivityPub protocol. There are a few other less popular decentralized protocols. A prominent example among those, thanks to Jack Dorsey, is Nostr.
Technologies are never value-free, but the values of their investors and engineers are usually revealed in retrospect. Decentralization movements, on the other hand, design their protocols in direct correspondence to and as a manifestation of their values. That openness has the benefits of transparency, shorter feedback loops, and adaptability. On the other hand, decentralization may become a surrogate of these values and a goal in itself.
This coupling between values and design decisions affects both developers and users. They tend to be passionate about decentralization. Passions tend to escalate.
The Decentralization Debate
At the beginning of 2024, a heated debate erupted between Mastodon and Bluesky users, triggered by an initiative to create a bridge between the two networks. For those who know history, it was just a matter of time before the unifying factor was occluded by the amplification of differences. Social media decentralization was not immune to schizogenesis.
By the end of 2024 another debate took place. It was again between the camps of Bluesky and ActivityPub. But there were significant differences.
The first debate happened as GitHub comments, ranging from sensible to very rude. The new debate was just the opposite: respectful, rigorous and deep. And it wasn't in the form of issue comments but as long, well-thought-through articles. Another difference is also worth mentioning. When the first debate happened, Mastodon had 8.7 million users and Bluesky 4.8 million. In the second debate, this was reversed. While Mastodon was estimated to have a little over 10 million users, by December 2024, Bluesky surpassed 25 million, with 10 million users added only within a month.
The recent debate was initiated by Christine Lemmer-Webber, a co-author and co-editor of the ActivityPub specification, with the question: How Decentralized Is Bluesky Really? This was in response to an invitation by Bryan Newbold, protocol engineer at Bluesky.
Decentralization can be a principle, aim or claim.2 Bluesky claims to be decentralized, but is it really?
According to Christine, Bluesky is neither decentralized nor federated.
But wait. A truly decentralized system can only exist if every user self-hosts everything. That's not even the case for systems using ActivityPub. So why does it matter how decentralized Bluesky is?
Christine explains:
There are multiple ways this could end up being a problem for the decentralized world; one irritating way is that people might believe there's an "easy decentralized way to do things" that Bluesky has discovered which isn't actually that at all, and another is that 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?"
Christine credits Bluesky with credible exit, content-addressing, scaling capability, and the team's professional and personal qualities. However, she finds the claims of being decentralized and federated unwarranted.
Decentralization, for Christine, is "the result of a system that diffuses power throughout its structure, so that no node holds particular power at the center" and federation "is a technical approach to communication architecture which achieves decentralization by many independent nodes cooperating and communicating to be a unified whole, with no node holding more power than the responsibility or communication of its parts." Based on these definitions and after careful technical analysis, Christine concludes that Bluesky is neither decentralized nor federated.
Before going further, a quick sketch of the Bluesky architecture might be useful.
User data is in personal data servers (PDS). They get user posts, likes and other records from the client apps, and send them to aggregators, called relays, that stream the records via firehose. The streams are then consumed by AppViews, labelers and feed generators. The PDSes read from the AppViews to get replies and whatever is created in other PDSes and concerns the consuming one.3
In Christine's article, she goes into detail to explain why the decentralization claim of Bluesky is unwarranted. (It's admirable that while the arguments are technically rigorous, there is a lot of care that non-technical readers can follow them.) A central argument is the comparison between "message passing" and "shared heap." Fediverse, like email, uses message passing (currently between servers, not peer-to-peer yet). Message passing implies direct delivery to the recipient. In the shared heap architecture, on the other hand, the messages don't go directly to the recipients but to the relays, from where the recipients (or rather some agent operating on their behalf) should filter through to find whatever is for them. Not to miss any messages, unlike Fediverse, Bluesky has one very large relay, a god's eye view, and that is what makes Bluesky centralized. Everyone can host a relay, but Christine goes on to show that this is prohibitively expensive.4
The other issue with Bluesky, Christine points out, is that while Bluesky uses decentralized identifiers (DID, a W3C standard), the only methods supported did:web and did:plc and they are both centralized.
Bluesky should brand itself not as decentralized, Christine suggests, but as having an open architecture with the possibility of credible exit.
This was a quick sketch of the article, not a decent summary by any measure. It's over ten thousand words and without any deviations or rambling.
Bryan Newbold, an engineer from the Bluesky team, wrote an article in response. He clarified that what Christine calls a "shared heap" goes beyond relays and AppVews and is, in fact, a global data graph of records referring to other records. Since Bluesky aims to create a big-world broadcasting system with an uncompromised user experience, full-network indices are inevitable. Yet, Bluesky's architecture is open to other service providers. Then Bryan goes on to clarify the values behind the atproto design and challenges Christine to state those of ActivityPub or Stritely. That part is essential. I'll discuss it later.
The article moves to terminology clarification, referring to an RFC by Mark Nottingham. In it, decentralization is defined by referring to the classical paper of Baran from 19645 as a state of affairs where "complete reliance upon a single point is not always required." While Bluesky may not satisfy Christine's definition, Bryan asserts, it meets Mark's definition. Then, he goes on to acknowledge some points from Christine's articles about the fully centralized direct messages, the public blocks, not having independently controlled rotation keys for the identifiers, and the increasing costs of running relays.
Finally, Bryan makes a point about trust, which, while highly appreciated as something expressed by Christine for the Bluesky team, is not what Bluesky relies on. On the contrary, the aim is to design atproto so that it is legitimate, "even if Bluesky and the team adopt the worst of intentions."
To which Christine responded with another long article, even longer than the first one. There, after acknowledging the rare civility of the debate (I concur), she comments on the points that Bryan agreed with and then moves to more contentious ones.
The definitions of decentralization and federation, chosen by Bryan, don't include power dynamics, move the goal post, Christine asserts, and tolerate partial centralization or switching. This switching, which comes from the article of Mark Nottingham, Christine finds close to the Bluesky’s "credible exit" which she acknowledges and appreciates but doesn't take as decentralization. It only avoids "some of the challenges of centralization going bad." Then Christine goes on to support her claim from the initial articles that atporo has quadratic scaling costs. She also responds to Bryan’s request and shares ActivityPub And Spritely's values and design goals. I'll skip this part now. It deserves a closer look.
In conclusion, Christine comments again on the civility of the debate and the importance of terminology and recognizes the achievements of Bluesky. Yet, the decentralized techniques used by Bluesky allow only "credible exit," not decentralization, because
a system which does not permit user participation in its infrastructure and which is dependent on a few centralized gatekeepers is not itself decentralized
This concrete debate, while uniquely deep, is part of a larger debate on decentralization. It started already with the classic paper of Baran from 1964 (cited lengthily in the exchange between Christine and Bryan). There, seeing that "decentralized" is used to describe a hierarchically centralized network, Baran came up with a separate term for a fully decentralized system: "distributed." Christine wants to keep it "decentralized," but it shouldn't be misused.
From an ontological perspective, this is a classical situation where the battles are fought in two arenas. On the first one, the debate is about which are the necessary and sufficient conditions for a thing to be a member of a particular set (in this case, the set of decentralized social media). On the second, the debate is about what characteristics are selected and how they are analyzed so that they become the criteria for deciding whether that thing is a member of the set or not.
Another way to look at it, from the perspective of the calculus of indications,6 is as a re-entry of the centralization/decentralization distinction into decentralization. However, the centralization/decentralization distinction cannot supply all the arguments to decide, so other distinctions enter the debate. One such distinction is idealism/pragmatism. That is what Mark Nottingham uses in his RFC 9518 (referred to in the Christine/Bryan exchange) and Balázs Bodó et al (reference in note 2) bring in. According to Mark Nottingham, decentralization on the Internet cannot prevent centralization effects, and further centralization is not always bad in itself and is "often present due to technical necessity." What standards can do, which seems to be the main concern from which the RFC is written, is bring rigor in centralization discussions, develop interoperability standards for functions that are currently proprietary, and enable switching.7 That's what realistically can be expected.
Many authors point out the common phenomenon of re-centralization. Decentralization, Balázs Bodó asserts, "might very well be served by and produce centralising effects."
Indeed, decentralization, just like democracy, is not a rachet. The web was decentralized, yet it provided the ground for cloud computing, SaaS business models, and walled gardens. Some walled gardens grew into powerful machines for exploiting the attention and personal data of their users. Facebook zucked over three billion "dumb fucks", as Zuckerberg called the gullible users of his platform. Today, Facebook is an extremely effective amplifier of misinformation (recently officially announced as such), hate, and propaganda.
The parallel with democracy is uncanny. Just like the decentralized web, democracy made it possible to elect anti-democratic leaders.8
Some find the reason for re-centralization in the tendency of natural networks to have power law distribution due to preferential attachment.9 This also makes the network efficient and stable. Others find it in the distinction between decentralized and distributed. The web allowed centralization because the internet itself is decentralized in Baran's definition; in other words, it is hierarchically centralized and not truly decentralized, which in Baran's terms would be called distributed. Some attempts to create peer-to-peer networks, like IPFS, are based on that. They use content addressing to decouple content from the host. However, distributed networks are not immune to power asymmetries. Some node may use their technical advantages, many protocols may favor producers over consumers, and in all cases, a decision needs to be made. There needs to be some form of governance since without it, Balázs Bodó asserts, "nodes may collude, people may lie to each other, markets can be rigged, and there can be significant cost to people entering and exiting markets". Governance can take various forms, but power asymmetries are difficult to avoid.
[C]hanges to the protocol require some framework of coordination and decision making which can range from charismatic leadership, via meritocratic autocracy, to direct democracy. Even in the last case, beyond a certain scale, power tends to accumulate in the hands of those who have enough reputation, social capital, time, and other resources to participate in the governance process.
In summary, in the decentralization debate, there are idealists who, like Christine, can only accept uncompromised, truly decentralized networks, and others, like Balázs Bodó, Mark Nottingham and Bryan Newbold, who call for understanding the limitation of the technical approaches for decentralization, and allow switching or hybrid approaches.
Where do I stand in this debate? Nowhere. It’s simply the wrong debate to have. That might sound like heresy for the decentralization zealots, but I invite you to loosen your grip on the decentralization ideal and try another perspective.
Both Autonomy and Cohesion
Decentralized is an adjective that can be applied to describe a network, but the power asymmetries that decentralization efforts are concerned with will not happen in the network but in the social systems that emerge. To succumb to the temptation of making a causal link between a graph property like centrality and a social pattern as power asymmetry is natural but risky. Describing a social system as decentralized or centralized is like describing a human being as a mobile meat structure, cellulose-independent life form, or self-aware oxygen combustor. From a certain perspective, these are all technically correct descriptions, but they won't help in healing human beings or understanding the human condition.
When we compare two social media, it is now natural to search for their place in the decentralization/centralization axis. But, to paraphrase Heisenberg, what we observe is not the social media themselves, but the social media exposed to our method of questioning. The method of questioning comes from our knowledge and our values. Contrary to the fact that decentralization is usually achieved by decoupling, the values and the method are tightly coupled. As said earlier, decentralization movements design protocols in direct correspondence with their values, which motivates passionate debates. But if we take a step back and start from values, we may use them to guide our choices instead of taking a particular approach as their proxy.
The decentralization debate itself often reaches the point where it can't continue before making a step back to its values. Putting the what and how aside to review the why is common to expect in every intelligent debate, and the one about how decentralization claim of Bluesky is no exception. As Bryan pointed out, nobody's real goal is "to have something "federated" for the sake of being federated." And then he referred to the actual design goals of atproto:
Credible Exit
Own Your Identity and Data
Algorithmic Choice
Composable Multi-Party Moderation
Foundation for New Apps
All these goals can be replaced by one single word: autonomy. And, as Stafford Beer wrote several decades ago, "the familiar debates about centralization and decentralization (based as they usually are on ideology) are powerless to resolve vital questions of autonomy."
Although the five design goals shared by Bryan are all about autonomy, I would argue that there is also an implicit goal, cohesion.10 Otherwise, what's the point of having social media, decentralized or not?
Decentralization is limited both as a description and as a lens. It can't deal with more complex, emergent properties, nor can it account for social factors and forces at play. The balance between autonomy and cohesion, on the other hand, is universal and can be applied not only to every technical system but also to every biological, social, and socio-technical system.11
As atproto goals show, this balance is already implicit. Making it explicit, using it as a lens to look at designed and systemic properties is a more productive way to evaluate networks aiming at avoidance of power asymmetries. Then, for protocol builders, the main question is: since increasing autonomy decreases cohesion, and vice versa, how to increase autonomy and increase cohesion at the same time and at all scales?
The balance between autonomy and cohesion may seem to reflect values different from those fighting for decentralization, but that's not the case. Incidentally, while mainly concerned with viability, it is a more direct reflection of these values. Stafford Beer lamented that the decentralization/centralization debate was not supported by scientific arguments but by ideologies. Yet, it is better to understand the ideologies than dismiss them. After all, they are expressions of shared values. The problem is fixing a set of values with a particular class of engineering solutions defined on the basis of a single characteristic.
The design goals of Bluesky, which, as we saw, are all facets of autonomy, come from an article titled "Progress on atproto Values and Value Proposition." It was a move to zoom out, to go to the why. But this correspondence can be seen in good definitions of decentralization as well. Sarah Jamie Lewis defined decentralization as "the degree to which an entity within the system can resist coercion and still function as part of the system." Here, decentralization itself is defined through the balance: the degree to which an entity within the system can resist coercion (autonomy) and still function as part of the system (cohesion).
Christine’s definition of decentralization does not show correspondence with the balance, but her values do. Since there are no explicit values for ActivityPub, Christine first shared the use cases that the Social Web Working Group should enable. They can easily be seen through the autonomy-cohesion lens:
"User control of personal data," obviously autonomy.
"Cross-Organization Ad-hoc Federation" is about interoperability (cohesion) with minimum loss of autonomy. That's, in fact, what good standards and protocols bring. Autonomy is reduced only to the agreement to use the same protocol; its use otherwise increases both autonomy and cohesion.
"Embedded experiences" are about access to a particular resource (cohesion) without attaching additional dependence on the provider (autonomy) with the associated security risks.
The "Enterprise Social Business" is clearly about interoperability of enterprise systems (cohesion).
Then she shared the values of Spritly, which, as founder, she stands by. You can see the balance directly there, so I'll just quote it, adding in brackets autonomy or cohesion, when obvious, and after that, comment on those that are not.
People deserve the right to communicate and have communication systems (cohesion) which respect their agency and autonomy (autonomy). Communities deserve the right to organize (cohesion), govern (cohesion), and protect and enrich their members.
Protect and enrich are indirectly related to autonomy and cohesion as well. Here it's time to bring another reason to go for autonomy/cohesion balance rather than for decentralization. It can be evaluated in every situation via the law of requisite variety. The law itself is about another balance, that between stimuli and responses. It states that to achieve a certain goal, the variety of the responses must be equal to or greater than the variety of the stimuli, divided by the variety of the goal. Here, variety is defined as the total number of distinguishable states of a system, but there is a much more intuitive way to think about it, which, together with an accessible description of the law of requisite variety, you can find here.
The goal of protection is related to a threat. It follows that the accessible variety without a threat needs to be increased with the variety equal to or bigger than that of the threat to achieve the goal of protection. Depending on the context, that may require autonomy, cohesion, or both. If you are attacked but your hands are tied, you won't be able to protect yourself due to a lack of variety and, respectively, autonomy. To protect a city, you come together (cohesion, increase of variety of the whole), fortify your city, and organize (cohesion) defense.
(I'm reading a book about the Venetian Republic in the Middle Ages, which obviously influences my choice of examples.)
So, your city is fortified. Now, let's take some examples from those who try to conquer it. They come by sea with galleys and use sieging devices. Galleys move by rowing.12 This method is effective only when the oarsmen row in sync (cohesion). So they don't use their autonomy to row whenever they want, but in a coordinated rhythm. This loss of freedom for the sake of cohesion is insignificant (even more so when keeping in mind that most oarsmen were slaves or convicts), but it is important to understand the balance.
The galleys of the attacking army reach the port of the city, and once they overcome the chains and other protecting means, they disembark the soldiers and the sieging equipment, of which the battering ram is a good way to illustrate the balance between autonomy and cohesion. The log is too big and heavy to be lifted by one person. Several people were needed. Not only that, but they had to swing it in the same direction and at the same time. Cohesion is a matter of a combination of forces pointing in the same direction and pushing at the same time. The cohesion costs the loss of several degrees of freedom. But these are freedoms of low value and easy to forfeit in order to conquer the city, which can bring enrichment, hence increasing autonomy and variety later on. This actually happened in the fourth crusade, when the knights, with the help of Venetians, sacked Constantinople.
I hope these examples helped to understand how protection and enrichment are related to autonomy and cohesion and, more generally, how the balance works.
The loss of autonomy for the sake of cohesion in operating the battering ram is minimal in terms of value, but that's not always the case. Let's take a more recent technology, HTML.
The internet appeared in 1969 already but did not spread for a couple of decades. It required expert knowledge. The user had to know the right commands to connect via a terminal to a remote computer, retrieve the directories, find the needed file, and download it to the local computer. Only then she was able to read that file. On the web, in comparison, the only thing needed to read another file on the network is to click on a hyperlink. But the hypertext technology wasn't the game changer. Having open standards was. One hypertext technology, HTML, together with an appropriate protocol, HTTP, brought the right set of de-couplings: autonomy to publish and read from different sources, and permissionless innovation for new applications, services and business models. The only price for this autonomy is to agree to use these standards and not anything else. Regarding hypertext, if we compare HTML with the battering ram, the cost is higher. Earlier hypertext systems, such as HES and FRESS from the 1960s, ZOG and EDS from the 1970s, and HyperTies and Intermedia from the 1980s, were superior in some ways to the early version of HTML. FRESS offered more advanced text manipulation, HyperTies allowed the interlinking of different document parts, and Intermedia supported transclusion.
It's important that these sacrifices were not so big. Mastodon is a decentralized network but requires way too many sacrifices. For example, unlike any other social media, you can't just link and follow; you need to copy the handle on your server and search from there. Well, this is a serious friction. And if we add to this the fact that your ID is dependent on the server, so when you want to migrate, that's too much trouble and sometimes impossible. If it wasn't for the authoritarian turn of Twitter under Musk, the millions that joined the X-odus wouldn't put up with the current inconveniences of the promised lands. (Yet, let’s not forget that the pull of convenience got us in trouble in the first place). Speaking of Musk, if, for the moment, you can detach the person from his company, Tesla, the latter is a good example of what some decentralization idealists fail to grasp. The first electric vehicles used the environmental narrative to justify the various inferior features in comparison to successful combustion cars. Tesla did something different. Here is a car that is better than the rest on the market. And, by the way, it's electric. Bluesky is doing something similar. It does not offer a full Twitter-like experience, but it works impressively well in a situation of rapid scaling that Twitter has never experienced, so we don't know how it would've handled it.
This is just one example, looking at Bluesky though autonomy-cohesion lens will come in a moment.
Now back to Musk, who turned the cheerful bird into something that, even by the look of its logo, looks like a new Nazi symbol. My idea is not to talk about Musk concretely or how a nice social platform, given an appropriate ruler, can make a dystopian turn. Enough has been written about that. It's more about what this was an example of: the huge risk when there are power asymmetries by design that are not evident in cases where, for a long time, the power wasn't abused. So, let's talk a bit about power since avoiding power asymmetries is indeed something worth fighting for and intrinsic to the ethos of the decentralization movement. And a bit, because power is a much bigger topic. I intend to explore it in focused articles.
One way13 to look at social power is as the capacity of a power-holder to influence the choices of a power subject. The influence is twofold: zone and number. If you rate your options and nominate the top three, a power holder may make them unavailable to you, so you'd need to choose between 3rd and 6th. Some numbers, different zones. The other manifestation of power is pure reduction of choices. The proverbial example would be the extreme reduction down to two: your money or your life (which is, in fact, not a simple or but and or/and: you money or your life and your money).
The point here is that it is again a matter of matching variety, and the autonomy-cohesion lens is a useful tool. Your participation for the sake of increased variety (learning, expressing, influencing, entertainment) requires the price of cohesion, which gives the power nodes of the platform the means to reduce your autonomy as long as you are using the platform as a medium to socialize.
The last point is that decentralization is flat, while the autonomy-cohesion balance is a fractal. At every level of recursion, the autonomy of the whole depends just as much on the relations with other agents at the same level as on its own cohesion.14
Bluesky through A-C lens
If Bluesky is strictly speaking not decentralized, how does it look through the lens of autonomy-cohesion balance? A direct answer to this question will fall into the same trap as with decentralization. The autonomy-cohesion balance is something observed in a socio-technical system, and although the protocols and the behavior of the dominant provider make certain patterns more likely than others, there are other factors and forces that would influence the emergent dynamics in unpredictable ways. Since diagnosing the whole system is beyond the ambition of this article, I'll focus on the current affordances of the technology. Yet, in the end, I'll make a few notes on aspects that will remain in the blind spot of the decentralization debate as long as it uses the same set of lenses.
Bluesky and the AT protocol promote autonomy for users, providers, and developers by separating identity, storage, views, feed generators and labelers. Users can use their domain as a handle, which also resolves the problem with verification. Users are free to choose feed generators and labelers. Providers can potentially host personal data servers and indexers. There can be independent curators of feeds and providers of moderation services (labelers). Developers can use the AT protocols for alternative social modes and can create new lexicons and applications.
In terms of identity management, Bluesky offers both more autonomy and more cohesion than Mastodon. The user's handles are not dependent on a particular server that is part of the social media network, and at the same time, the users are more likely to remain connected in many disturbance scenarios.
Another feature of the AT protocol, promoting both autonomy and cohesion, is content addressing. The content is decoupled from a particular host (autonomy). Any server or node with a copy of that content can provide it (cohesion via interoperability) as long as the content ID is the same. The added benefit is resilience.15
The Personal Data Storage (PDS) brings several de-couplings. Users update their own PDS only and not those of others. The second one is that the storage and authentication are not served from the same domain. And the third, potentially, personal data server can be self-hosted. Overall a lot of increase of autonomy, but the price of retaining cohesion is global indexing. That was what Christine found problematic, as it’s a kind of centralization. For the autonomy-cohesion balance, that is not a problem as long as the use of the indexing service does not require something that reduces the autonomy of the users (currently or potentially). There is something else related to PDS that bothers me more since it changes the balance towards the dark ways of cohesion: tight coupling and lock-in. More on that in a bit.
Opening up the possibility of creating algorithmic feeds gives more agency to the users, both creators and consumers. Here, apart from autonomy-cohesion, another essential balance should be applied: that between exploration and exploitation. The possibility of discovering new content and new interesting users to follow and the potential of serendipitous episodes is much higher when there is a wide choice of curated feeds. In turn, the autonomy-cohesion balance is improved since the decoupling of algorithmic feed providers from the social media service provider gives more autonomy and is a likely source of new connections. However, this decoupling is limited as long as the protocol, the app, and the infrastructure are coming from the same provider. Just like X-twitter's "For you," Bluesky provides a curated feed named "Discover."16 Without any doubt, the Discover feed is and will be used by many more users than the user-created feeds. That's one power asymmetry. Another is that the creation of custom feeds favors technical users.
Similar to feed generation, Bluesky’s moderation allows more degrees of freedom, more diversity, autonomy and agency. Indeed, currently, there are many labelers users can subscribe to that serve as independent moderation services providers and also as community builders (another way to enhance both autonomy and cohesion).
Here, it's time to bring in the 4U test, a simple way to access a product or a service. Previously, I have shared the corporate version, 4U2P, but here, we can start 4U only and then see if something is missing. 4U has three basic questions: Is it useful? Does it work? Is it used? You need all three for something to be successful (we have two Us from useful and used, the double-U from work, hence 4U).
Bluesky and the AT protocol are widening user choices not only in terms of what options are available but, importantly, who is providing them. That is new and useful. We hope it will work and scale. But will these options be actually used? How many will use them? That includes several other questions: (taking moderators as an example) how many labelers there will be, what will be the quality of their service, and how many users will actually subscribe to them. These are all open questions.
By the same token, the possibility to self-host a PDS doesn't mean we'll see many users doing it, both because of the cost associated with it, as Christine pointed out, and due to the technical barrier.
But here I see a bigger issue, where the autonomy-cohesion gets out of balance. The current provider of PDS is Bluesky, and this is likely to remain the case. But, if hypothetically, other providers appear, PDS is designed to work with AT protocol. That's tight coupling. To provide actual autonomy and increase the chance to be used, personal storage should be used for all kinds of personal data and not be specific for (even more so, a certain kind of) social media posts. If you use a Solid Pod, for example, for your personal data, currently, you can't use it as PDS. For autonomy-cohesion balance, it's more important to be able to store any kind of personal data, even if you don't self-host, as long as the storage provider and application provider are not the same and the migration cost is low.
Zoom out
If seeing social media through an autonomy-cohesion lens helps us notice different patterns, this becomes even more true when we move beyond the technical level. Paradoxically, not using a decentralization lens can help decentralization efforts. As Mark Nottingham admitted, "centralization is often caused by non-technical factors."
A social medium will get its cohesion by using standards and protocols, indexing, shared infrastructure and so on. It will result in features that will attract some users and put off others, depending on their values and their ability to get value from the network. But a system’s cohesion does not come only from tools and technologies. It is caused, and often more so, by other forces and factors. There are universal cohesion forces at personal lebel, such as the need for safety, the need to belong to a social group, to reduce uncertainty, and the need to increase self-esteem. Factors like proximity, transitivity, and preferential attachment interact with forces such as shared interest and shared aversion, working on top of the basic needs for self-expression and validation, as well as the fear of missing out.
These factors make other questions matter: Who goes there? How do you feel being there? Where do you feel you belong? I had the most satisfying17 experience in the cozy web,18 small communities with shared interests, using centralized platforms like Discord, Slack, and forums based on Discourse. These factors are formative for the cozy web, but they matter everywhere. I'm posting from Buffer to both Bluesky and Mastodon. While I have way more followers on Bluesky (yet, still by far less than on X-twitter or LinkedIn), so far I get more frequent and more meaningful exchanges on Mastodon. And that's not because Mastodon is more decentralized than Bluesky. The most decentralized protocol is probably Notr, but it somehow feels hostile, especially to those who are not worshiping crypto. On the other hand, we have an outright centralized platform like Substack. In the last couple of years, through their microblogging called Notes, Substack turned into an intelligent version of X-Twitter, but in addition, it has somehow the warmth of the cozy web and the feeling of reading your morning newspaper.
Well, that's now and in my bubble. It's maybe different elsewhere on Substack. And it may19 quickly turn ugly everywhere, depending on the intentions of the owners of the platform. That's why power asymmetries matter. Preventing them is a cause worth fighting for. But decentralization is not a good hill to die on. You may not be able to imagine how power asymmetries can be avoided without decentralization, but lack of imagination, as David Graeber said, is not an argument. So, come up with better arguments and engineer them. In other words, create better protocols.20 They will enhance both autonomy and cohesion and will reduce power asymmetries.
Yet so far, that hasn’t changed having elites, just replacing them, sometimes with better ones.
Bodó, B., Brekke, J. K., & Hoepman, J.-H. (2021). Decentralisation: A multidisciplinary perspective. Internet Policy Review, 10(2). https://policyreview.info/concepts/decentralisation
For details, see Kleppmann, M., Frazee, P., Gold, J., Graber, J., Holmgren, D., Ivy, D., Johnson, J., Newbold, B., & Volpert, J. (2024). Bluesky and the AT Protocol: Usable Decentralized Social Media. Proceedings of the ACM Conext-2024 Workshop on the Decentralization of the Internet, 1–7. https://doi.org/10.1145/3694809.3700740
There are some who think otherwise and even demonstrate it.
Baran, P. (1964). On Distributed Communications: I. Introduction to Distributed Communications Networks. RAND Corporation. https://www.rand.org/pubs/research_memoranda/RM3420.html
Spencer-Brown, G. (1979). Laws of form. Dutton. (Original work published 1969)
There are five more: bolster the legitimacy of standardization bodies; consider delegation of power; enforce boundaries with techniques like encryption; consider extensibility carefully so that it is not used by vendors in a way that would reduce interoperability; reuse what works (see all 8 at https://www.rfc-editor.org/rfc/rfc9518.html#section-4)
Some blame malfunction on democracy being the wrong kind: it produces representatives who pursue their own agenda and rely on institutions that are centralized. Then, not surprisingly, various proposals for direct democracy are similar to the decentralization efforts for disintermediation. Others believe the elections as a selection method are to blame, which resembles some of the efforts in techno-decentralization related to distributing decision power. Overall, techno-decentralization approaches and societal governance approaches (e.g., sortition/lottery, liquid democracy, quadratic voting) look for ways to fix democracy and apply common principles: distributed decision-making, resistance to manipulation, transparency, accountability, and participation.
See, for example,
’s Centralization is Inevitable. Notably, he points out that preferential attachments and the related power law distributions are only one of the reasons for (re) centralization.Cohesion in social systems should be understood broader than in physics. It is the ability to form a whole (bonding) and/or to work as a whole (coordination).
See Essential Balances, particularly for organizations, and this series, for sociotechnical systems in general.
Some galleys were equipped with sails that could be used when the wind was favorable.
Another way is to see it (also) as a communication medium (cf Luhmann)
The whole trade machine of the Venetian Republic of the Middle Ages can be seen as a fractal of coordinations, from the seasonal voyaging rhythms (see Chapter 15 of City of Fortune), through the coordination of ships in one voyage to the rowing rhythm of a single galley.
This can be additionally analyzed via the lens of the Stability-Diveristy balance.
Notably, the order on Bluesy is better (the first tab on Bluesky is “Following,” while on X-Twitter, it is “For you” and “Following” is second) and the content as well, but that’s because of the current Bluesky team and their values.
Yet, you tend to over-exploit and under-explore there; low serendipity index.
“A protocol is an engineered argument” is a recent definition of protocol (See the Introduction of Protocol Reader)