"Is the AT Protocol decentralized?
---
This question has been a matter of open debate since, from what I can tell, the unveiling of the protocol's architecture. Although this question had been tepidly discussed ad nauesum both in ATmosphere and Fediverse circles, the general lack of structured arguments left legitimate discussions of these questions largely unaddressed in any serious capacity.
This all changed after [Christine Lemmer-Webber's fantastic critique of the AT Protocol](https://dustycloud.org/blog/how-decentralized-is-bluesky/), in my opinion the best and most thoughtful critique the protocol has received so far. This blog post sent ripples across the Fediverse and ATmosphere, providing several far-reaching critiques, many of which are beyond the scope of this blog post. Christine does, however, provide an overarching thesis for her philosophical disagreement with ATProto's infrastructure, which she summarizes as such:
> [...] I stand by my assertions that Bluesky is not meaningfully decentralized and that it is certainly not federated according to any technical definition of federation we have had in a decentralized social network context previously. To claim that Bluesky is decentralized or federated in its current form moves the goalposts of both of those terms, which I find unacceptable.
>
> However, "credible exit" is a reasonable term to describe what Bluesky is aiming for. It is Bluesky's term, and I think Bluesky should embrace that term fully in all contexts and work that they can.
The impact of this article has forced the discussion of several architectural components of the protocol into the limelight, which is fantastic and a sign of a healthy, lively developer community receptive to criticism. Yet, even among these discussions, I couldn't help but notice something. Despite the laundry list of critiques that Christine provided regarding the AT Protocol, a significant amount of time has been spent attempting to answer the question at the lede of this blog post: Is the AT Protocol decentralized? Is it federated?
In this blog post, I would like to examine these discussions, and why I believe that Paul's proposal for Internection might, in fact, be the best solution for this neverending discussion.
## Disclaimer
Before beginning this dissection, I want to make one thing clear: I am not a developer. I do not specialize in computing professionally, and I am certainly no expert in networking or social media. I am, however, a biologist by trade; instead of studying computer systems, I study biological systems. And, much like in computer systems, semantics are of utmost importance to enable productive communication regarding the concepts and systems we study. This is not my first rodeo when it comes to semantic debates.
I volunteer my opinion not because I believe I am an expert in any topic, but because I believe it is not necessary to be one in order to yield productive conversations regarding this topic. I couldn't opine on, for example, whether 32 characters is an appropriate amount of chars for `did:plc` to have; that is a question for the cryptographers. I couldn't opine on whether the inner corporate dynamics of Bluesky Social, PBC will yield it stability for the next 5-10 years; that is a question for its workers and the board.
I *can* opine on whether ATProto is decentralized or not. Why is that? Because decentralization is no longer a *technical* term -- it has outgrown this definition long ago. Decentralization and federation both carry significant social weight. As its use has matured, it has become associated with a particular philosophy, one that many hold in particularly high regard. This is why Christine has been so adamant in calling for ATmosphere devs to cease calling the protocol decentralized. Not only does she believe it's incorrect in the technical sense, but it's clear that she believes that it provides a social cue that ATProto's abstract architecture simply does not meet.
It is these kinds of social cues that I would like to opine on. Language is a tricky thing. It is one of the few social constructs that are solely limited to our human domain. As much as we'd like it to be otherwise sometimes, words are slippery; definitions can change and morph over time to suit certain needs. New and useful words emerge: Tired and dated words fall out of favor. It's useful sometimes to take a step back and examine how we use these words, what we attempt to convey with these words, and how we can do better to communicate what we truly intend to. That is my goal here today.
# The Easy and Hard Question of Decentralization
I'd like to start by setting a clear boundary between what I will call the "soft question" of decentralization and federation and the "hard question" thereof. **The easy question of decentralization** is eponymously the easiest to answer:
* **Is the AT Protocol, as it exists today, decentralized?**
This is an easy question to answer: no, it is not decentralized. Bluesky Social operates nearly all of the infrastructure within the protocol as of writing. Nearly all user accounts reside within Bluesky Social's PDSes. Nearly all archival relays are run by Bluesky Social, and the ones that aren't are largely experiments. Bluesky operates the largest AppView by several orders of magnitude, with the smaller AppViews only really used by ATProto's most involved community members. I'm convinced that if Bluesky Social were to go bankrupt tomorrow, the network simply wouldn't survive, regardless of the FOSS implementations that would rise in its wake. As such, as it stands, **the AT Protocol, as it exists today, is not decentralized.**
Much to its credit, Bluesky Social and its employees are taking steps to alleviate this centralization of services within the protocol. Even during ATProto's lightning fast development cycle, they have done their part in nurturing and growing the developer ecosystem, and I'm certain they have more plans to nurture this further down the line. However, these efforts will take time and a robust developer ecosystem to see fruition. Having seen both Bluesky and ATmosphere devs working for more than a year now, I'm confident in their ability to move services away from Bsky PBC -- but we will have to wait and see whether this comes to be.
This question was the one often posed, sometimes genuinely, sometimes in bad faith, by people less familiar with ATProto's architecture. It's a fair question, and one with a rather easy answer. However, anyone who's spent any time around the people running the show at Bluesky Social know that their ambitions to build a better social web is genuine, and everyone in the ATmosphere is excited and willing to help see it through.
However, this isn't the question that Christine was addressing in her blog post -- the question she posed struck at something much deeper, and, I would argue, much more philosophical than either she or the responses to her blog post so far had intended. This is **the hard question of decentralization:**
* **Is the AT Protocol's architecture, in the abstract, decentralized?**
This is the question I will attempt to examine next.
## What is Federation and Decentralization.... Really?
In order to answer the hard question of decentralization, we first have to *define* meaningful decentralization and federation. Unfortunately, this is an impossible task. I will attempt to explain why in this section.
### Christine's definition
It's clear, both in Christine's blog post and in the responses therein, that this question holds significant weight, and Christine provides her own technical definition of decentralization and federation from which to work her analysis. This is her working definition for both:
> Decentralization is the result of a system that diffuses power throughout its structure, so that no node holds particular power at the center. "Federation", as has been used as a technical term since the emergence of the "Fediverse" (which presently is mostly associated with ActivityPub, though I would argue XMPP and email are also federated), 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.
On first read, this is a fair working definition for decentralization and federation. In Christine's definition, federation is a technical means to a social end -- that being decentralization. We see some flexibility regarding the usage of the term here -- as she atypically describes XMPP and email as federated -- but overall, this is a fair definition to work from.
We see later, however, that this working definition holds far more than a technical or "working" definition, holding a social connotation that Christine holds in upmost importance. We can see this manifest at its strongest in the following:
> Bluesky does use several decentralization tricks which may lend themselves more towards its self-stated goal of "credible exit". But these do not make Bluesky decentralized, which it is not 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. (I have heard the term "**federation-washing**" used to describe the goalpost-moving involved here, and I'm sympathetic to that phrase personally.)
The term "federation-washing" stuck out to me like a sore thumb as I read the blog post. Christine used the term "decentralization-washing" later on to describe `did:plc`. Despite her establishment of federation in solely *technical* terms, the *social* implications described by this language are unmistakeable. Not only is the AT Protocol not federated, but describing it as such is an actively *deceitful* act. Why? Because it belies the protocol's fundamental ability to achieve what she defines as truly decentralized social networking.
How do you refute this argument on its own terms? The answer is simple: you can't. Under Christine's working definition, it's not feasible for the AT Protocol to be federated or decentralized. As she eloquently argued, the economic and computational dynamics underlying the microservice architecture of the protocol makes this a difficult endeavour.
I'd like to take a look now at Bryan's response to Christine's article"