RFC, cotd:

> Almost all existing Internet protocols -- including IP, TCP, HTTP, and DNS -- fail to prevent centralized applications from using them. While the imprimatur of the standards track is not without value, merely withholding it cannot prevent centralization.

RFC, cotd:

> Thus, discussions should be very focused and limited, and any proposals for decentralization should be detailed so their full effects can be evaluated.

Mark is not wrong that standards can't prevent centralization on their own! Mark's analysis of how many things end up re-centralizing is, overall, also largely correct!

However, I disagree in the present moment that standards orgs shouldn't be making decentralization concerns a *key priority*.

But Mark, to be fully fair, does examine several strategies, and their strengths and downfalls, of how we may enable decentralization.

However, the path that Mark most heavily leans into is "Enable Switching". Hm. Does that phrase sound familiar?

"Enable switching" from the RFC:

> The ability to switch between different function providers is a core mechanism to control centralization. If users are unable to switch, they cannot exercise choice or fully realize the value of their efforts because, for example, "learning to use a vendor's product takes time, and the skill may not be fully transferable to a competitor's product if there is inadequate standardization".

(cotd ...)

"Enable switching" cotd:

> Therefore, standards should have an explicit goal of facilitating users switching between implementations and deployments of the functions they define or enable.

Does this sound familiar? If so, it's because it's awfully close to "credible exit"!

As said, I think "credible exit" is a worthwhile goal. But it isn't participatory decentralization, on its own. The ability to *move away* is good, but what if your options are to choose between McDonalds and Burger King? Is that *sufficient*?

In particular, Mark is especially fair to highlight that email and XMPP are great examples of decentralized systems that either ended up centralizing in the case of email or failing to stay alive after the exit of a major player in terms of XMPP.

Mark's RFC has a lot of useful analysis. It does!

So I've given a lot of context for Mark's RFC: it's an RFC by a respected standards author who has a long history of participating in standards from major internet-based corporations. It worries a bit about centralization but overall downplays decentralization more than it plays it up IMO.

And this is important of course, because this is the RFC where the definition of "decentralization" being provided comes from!

Or wait, or is it? Oh right, the RFC cites another source for its definition!

It's time to examine Paul Baran's 1964 paper. The story is about to become more intense.

Except, like a 1990s sitcom, we're gonna cut to a break!

We'll be back... after

=== TEA BREAK 2: MY NOSE IS COLD ===

Alright I'm back from my tea break. But I have a confession for you.

I made hot chocolate instead.

But we are going to get into the second part of the unnecessarily thorough "decentralization" terminology deep dive I'm doing here in just a moment

Before we get into that it's also getting pretty late here and I have another confession to make to you, I was pretty hungry, so you know what I did? I stood in the kitchen and I ate hummus in the kitchen with a spoon over the sink

You have found Secret Goblin #2, judging me for my hummus shame 👿

When we last left off I was peeling back layers of the terminology onion and we have gotten to the inner layer (maybe it goes deeper, I guess terminology usually does but this is as far as we go)

It is time to examine "decentralization" in Baran 1964

Because I am being UNNECESSARILY thorough

So here is Paul Baran's "literally the most influential paper to affect networking systems ever" 1964 paper:

"On Distributed Communications: I. Introduction to Distributed Communication Networks" https://www.rand.org/pubs/research_memoranda/RM3420.html

It's good, it's amazing, it's INCREDIBLY visionary

So okay yeah it's very military-oriented but... but! The context for this paper is that Paul Baran is arguing for what eventually *becomes* networking as we know it. Baran says: let's use *cheap* equipment with *way less centralization that we've ever seen* and it'll be *better actually!*

And just imagine the *gall* of it: telling the *military* let alone the world oh you know how you love hierarchy? Well guess what, you know what's WAY better, something that's closer to cooperative anarchy, where there's a lot of cooperation lots of error-prone little guys

AND HE WAS RIGHT

Baran comes in with the math to back up his claims, a vision of how basically wifi and satellite and land lines and cable internet would all work together before we even *had* any internet stuff, shows how a packet would look, and says if you want to REALLY be tough, be... "distributed"

Hm, did you notice I said "distributed" and not "decentralized"?

Actually wait... does this sound familiar, have you heard of this paper before?

Could it be? No... it couldn't be...

And yes of course it is literally the paper that gives us this incredible FIGURE 1, which you have CERTAINLY seen if you have ever heard ANYONE talk about ANY "decentralized" or "distributed" system ever

CENTRALIZED DECENTRALIZED DISTRIBUTED

You know this image. You could never forget this image

One of the reasons you know this image is that everyone worth their salt who works on decentralized networks thinks about this image and puts it in their talks

But also so does this bro who has literally no idea about how tech works but thinks he does

So one way or another you're gonna see it

(tech bro courtesy https://www.threepanelsoul.com/comic/job-interviews)

That comic is from Three Panel Soul btw, and here's the link https://www.threepanelsoul.com/comic/job-interviews

All of Three Panel Soul is good, but the Tech Bro ones are my favorites https://www.threepanelsoul.com/comic/search/Tech%20Bro

I love Three Panel Soul so much

(Gonna weird out @3psboyd by fangirling over here)

*COUGH* where was I

"Christine if you love this paper so much why don't you like the definition of 'decentralized' from it?!"

The definition is great actually if you know the context

Because the context is CRITICIZING THE DESIGN UNDER THE DEFINITION AS A FORM OF CENTRALIZATION

"What Christine you can't mean that, why would 'decentralized' be 'centralized' that can't be true"

Because because BECAUSE my good friend, Baran was describing "decentralization", a term that ALREADY EXISTED in networking, as being a kind of centralized system

NO REALLY I AM SERIOUS

The term "decentralized" was *already* in active use! So Baran was providing "distributed" as the new term! Oh my god THAT'S WHY THE DEFINITION BARAN PROVIDED FOR DECENTRALIZATION WAS SO WEAK

You don't believe me? Let me show you. LET ME SHOW YOU

Here is where Baran defines "decentralization!" We have to read the whole definition!
You're not allowed to stop until we finish EVERY (cotd) let's GOOOO

> The centralized network is obviously vulnerable as destruction of a single central node destroys communication between the end station.

(cotd)

Baran "decentralization" cotd:

> In practice, a mixture of star and mesh components is used to form communication networks.

IN PRACTICE FOR CENTRALIZED SYSTEMS YOU GUYS

(cotd)

Baran "decentralization" cotd:

> For example, type (b) in Fig. 1 shows the hierarchical structure of a set of stars connected in the form of a larger star with an additional link forming a loop.

OH SHIT HE'S STILL TALKING ABOUT CENTRALIZATION FIGURE B IS THE MIDDLE ONE

(cotd)

Baran "decentralization" cotd:

> Such a network is sometimes called a "decentralized" network, because complete reliance upon a single point is not always required.

OKAY WE'RE DONE

But look at it all together! He's talking about how "decentralization" is a term of art but it's still CENTRALIZED

Baran didn't make up the term "decentralized" it already was being used in practice to talk about top-down hierarchical systems! Baran calls this version centralized even if there's a "loop" (a small number of top-level providers)!

YOU GUYS THIS IS NOT HOW WE ARE USING "DECENTRALIZED"

WE are not describing the future of routing small packets in 1964, that is NOT the world we are existing in, where "decentralized" meant a top-down hierarchical structure

When WE talk about "decentralized", we mean roughly a spectrum, with "centralized" on one side and "decentralized" on the other

Now I don't think Bryan Newbold realized that when he pulled his definition from Mark Nottingham who pulled his definition from Paul Baran, that this was the case. I think this is a game of telephone.

(I don't know how Mark Nottingham didn't realize it but that's an aside)

What I DO know is that it means that the entire structure of analyzing decentralization in Mark's paper and Bryan's blogpost thus, in practice, surround a term that is weak because it was FUNDAMENTALLY describing a centralized system, so it could criticize it

The loss of context here is BRUTAL

To conflate the two *automatically* introduces decentralization-washing. I don't think this is intentional, but it explains a lot.

It explains how a "weak" definition of decentralization could come from one of the boldest visions of what that very *idea* could be

Now okay let's point out the irony here because I feel like if I don't I'm being mean. Bryan does say:

> To some degree, I don't really want to spend time in a terminology debate.

And I just did! At length!

But the whole debate this whole time is "is Bluesky decentralized" so we kinda HAVE to

But also what happened was:

- I lay out a strong definition of decentralization; Bluesky doesn't match
- Bryan suggests an alternate definition, pulls
from
- An RFC which despite the title is extremely lukewarm AT BEST about decentralization which pulls from
- A definition describing centralization

And I don't think this was malicious on Bryan's part in the least because I know Bryan well enough to know he's not like that!

I am pretty annoyed at Mark though for quoting this out of context in such a way that it can completely confuse a narrative like this. I'll assume that was a mistake but

The reality is that Bluesky didn't match my definition of decentralization, and I hope it's pretty clear now that the alternate definition supplied was literally one about centralization

And so that cannot possibly be a lower bar that we say "okay maybe Bluesky can pass this one" I am sorry