Let me emphasize a sentence there for you:
> standards bodies should not fixate on preventing all forms of centralization
That is the crux of this RFC
It's an interesting read, it's very thoughtful, it analyzes from many angles. It's worth reading! But that is the broad sweep of RFC 9518.
Mark examines centralization's effects from multiple angles. He has a *great* section called "Centralization Can Be Harmful". Covers the general ground.
But it's immediately followed by "Centralization Can Be Helpful"!
This is not a radical pro-decentralization RFC, is what I'm saying.
Mark does address the radicals:
> Many engineers who participate in Internet standards efforts have an inclination to prevent and counteract centralization because they see the Internet's history and architecture as incompatible with it.
So true bestie, that's me you're describing
While Mark analyzes both, his position is ultimately that of someone who does care about standards, but takes a kind of pragmatism that hey, look, decentralization, it's a great goal, but it's pretty hard, and maybe actually centralization is pretty helpful too, let's not go too wild here
The history of the internet and the web *is* of big dream believers making big strides. The internet has been moving away from that, and it's getting harder to participate in standards without being a big corporate player. (Trust me, I know *all too well.*)
So, *should* standards orgs do something?
As a side note on the thread on the other place, Bluesky dropped one of my replies and literally refuses to pull it up for me even though it acknowledges it's there
I have the worst time navigating replies on Bluesky, sometimes I send people threads and they say "I don't see the reply you're talking about there"
Dear god for all the claims of ATProto and Bluesky having a big deal of no missing replies it's really frustrating dealing with replies on Bluesky's UX
Anyway...
Anyway Mark, tell us, what should standards orgs do?
> Centralization and decentralization are increasingly being raised in technical standards discussions. Any claim needs to be critically evaluated. As discussed in Section 2, not all centralization is automatically harmful. Per Section 3, decentralization techniques do not automatically address all centralization harms and may bring their own risks.
Note this framing: centralization is not necessarily harmful, decentralization may not address problems and may cause new ones.
Rather than a rallying cry for decentralization, it's a call to preserve the increasing status quo: yes, it's worrying large corporations are centralizing the internet, but should *standards* really be worried about that?
More from the RFC:
> [...] approaches like requiring a "Centralization Considerations" section in documents, gatekeeping publication on a centralization review, or committing significant resources to searching for centralization in protocols are unlikely to improve the Internet.
RFC, cotd:
> Similarly, refusing to standardize a protocol because it does not actively prevent all forms of centralization ignores the very limited power that standards efforts have to do so. 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:
> 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
Let's PLEASE not move the goalposts on "decentralization". Let's certainly not move them back to something that was literally "here's what centralization looks like in practice".
That's what I'm asking for here. That's why I went so goddamned HARD on terminology here.
Let's check the time.
It's 7:30pm where I am. I woke up at 4:30am and resumed work on my blogpost at 5am.
I have been, for the most part, between the blogpost, my job, and this thread, sitting at my computer fighting for decentralization for about 14 hours. It's been like that a lot lately.
I have a reputation at work of being good at pushing others to take off time and they HAVE to take off time OR ELSE and I try to be that way in general. But I am really truly bad at doing so for myself and I know I have crossed my limits for today.
So let's wrap up for *tonight* in a sec
We're about halfway through this blogpost. There's a lot going on in my life. I am trying so hard to keep the organization I work for alive and moving forward. I am tired. I need rest. And I still need to drive two hours across the state tonight.
We're going to resume tomorrow. But first...
There's a reason I'm going really hard on this. I really care a lot about the shape of the internet. And tomorrow we're going to get into some more analysis and a talk about *values*, and one thing I like is that Bryan talked at length about Bluesky's values. And I think that part was really good.
For tonight, I need to unwind, I need to put a label on a mailbox, I need to eat dinner, I need to drive across the state, I need to sleep.
Maybe I appear ridiculous. I get it. I go pretty hardcore on this stuff. If you know me you know I tend to go all in.
I am signing off for the night. Tomorrow we will analyze whether or not my assertion that "ATProto has explosive behavior as it approaches decentralization" problems.
I'm not going to read notifications until I finish this. Maybe someone will prove me wrong before I get it done.
I'll be oblivious.
We will also analyze values, which maybe I care about more than anything. And there will be more secret goblins, hidden among the posts.
For tonight, it's rest time. It's time for a
=== NO MORE LOOKING AT MY COMPUTER BREAK ===
Hello! I am back at my computer. Today we are going to talk about how ATProto does in terms of scaling. Yes, we know it scales up, and has done an impressive job of doing so!
But what about scaling towards decentralization? Does it scale down? And does it scale wide? Let's look.
Before we get deep into that, when we left last night I was extremely tired and had been working at my computer for over 14 hours. I then said I was going to drive two hours across the state that evening.
Thankfully thanks to the support of people who love me, I did not do that foolish thing!
So anyway, I am better rested, and also I woke up to the surprise that our fundraiser is doing a lot better, like by a lot, than it was yesterday, which is nice because I was extremely stressed out https://spritely.institute/donate/
So I am feeling much better and alive and today I remembered to eat lunch
But you probably aren't here to hear about my lunch choices or how much sleep I got or whether or not I forgot to bring my ADHD medication with me (I did so now I am drinking a bunch of caffeine instead), you are probably here to hear the rest of the analysis about decentralization and Bluesky etc
So let us get to it, let's talk about whether or not Bluesky can scale *down* in a meaningful way.
In my last essay I made assertions that this was important for decentralization and said ATProto wasn't great for this, and this was one thing people challenged me on
So let's take a look!
@cwebber we're right here with you!
@cwebber I for one appreciate your threads and look forward to the rest tomorrow
I don't have any goblins but I can humbly offer you this flaming party parrot
keep it up!
@cwebber loved this, thanks to u for being u and thanks for your thoughts here <3
@cwebber I couldn't help but finish this thread start to bottom. I'm behind schedule on my own work, but this procrastination drift was worth the ride.
To build a common understanding of terminology is pretty hard, specially when people involved have (personal) stakes on the sources and consequences of the discussion. I think it makes sense that this somewhat boils down to a statement of values, as that's were the crossroads of discourse lies.
@cwebber
1. Thanks for the
2. This is reminding me about this historical research into what “airborne” transmission of disease meant (Telephone)
3. Values > words
@cwebber there’s always time for more analysis, but knowing you’re doing okay is really good
@cwebber I am ALSO here to hear about your lunch choices.
@cwebber wait, caffeine is an alternative to ADHD medication?
@cwebber looking forwards to the next part tomorrow, and the third Easter egg
@cwebber I am really grateful for the attention to this word that we all care so much about. I value your constructive discourse tremendously, and your energy and passion about the topic is refreshing. This stuff is important for the future of humanity.
@cwebber
First off thank you, these threads have been very enlightening. For those of us without the formal CS background is there a portion of something we missed in our learning. I'm just wondering how and where you learned all of this. Is it covered in a traditional CS degree (something I don't have) or more something you've learned over the years of doing standards work yourself?
@McNeely A lot of work on standards, other research... though most of my fundamental CS background came from studying SICP
Thank you @cwebber for caring so much about the shape of the internet, that you not only engage in this discussion but also pick your own writing apart to help us follow it and comprehend the substance.
This has been a gripping few hours of reading, rest well and I look forward to the continuation.
Don't forget to move
@cwebber Agreed as long as people stop conflating federated and decentralised
@cwebber thank you for contextualizing the Baran 1964 citations btw.
@cwebber It's like when people make proprietary source code releases, call that "open source" and then argue that nobody has a monopoly on the meaning of the term while clearly benefiting from its preexisting connotations.
@cwebber I appreciate this view, and can mostly, let's say, agree with it. But I also think it has flaws.
Mostly, I think the loss of context goes the other way around, but I also admit that it's a matter of perspective: if you use a term, it's best to use it as it was defined, not redefine it. So the use of "decentralized" kind of *should* be as described in Baran.
But independently, using the term as a counter to centralization is intuitive, so I know that's a fight against windmills.
1/n
So back to Mark's RFC: he's a smart cookie, and there's a reason they're talking about centralization and consolidation as different things in it, where - very broadly - you can think of the first as an architectural centralization, and the second as centralization of control or power.
The reason I bring up DINRG is actually because of this and/or the the loss of context you lament: it exists across the board.
I don't think it's fair to criticize Mark for it, or for me to turn it around as...
... I just did above, because the real issue is that a bunch of people have overloaded the same term with different meanings, and for largely well intentioned reasons. The word means what you think it means, to loosely quote Alice in Wonderland.
That's a problem to be solved.
In DINRG, we've been talking about better terminology also because each type of centralization has different reasons and risks, and so may need different solutions.
Besides the architectural and power types of...
... centralization, we also spoke of "algorithmic" centralization.
https://datatracker.ietf.org/doc/slides-121-dinrg-discussion-of-next-steps/ is the summary slides again, by the way.
Anyway, algorithmic centralization could be uses to describe blockchain. Even though at a network level it's decentralized, decision making happens in one logical place, the consensus algorithm.
Worse, algorithmic centralization *may* coincide with centralization of control, especially when the algorithm in question is effectively controlled by a small group.
This is a long winded way of saying, please join that conversation! The mailing list is free: https://www.irtf.org/dinrg.html
I do think a lot of problems in the misunderstandings that exist here have to do with flawed terminology, and it's been biting us hard. On the plus side, I've seen the conversation shift within IETF from "you're using it wrong" to "let's figure out the misunderstandings", which on some level is slow and annoying, but also very necessary and a great step forward.
It's worth...
... noting as well that Mallory contributed to the draft specifically to point out that first difference between architecture and power, and it seems unlikely that there is no relation to her Human Rights hat she wears for HRPC. Where, by the way, centralization of power *is* described as a risk to Human Rights.
Now for the more political context here: I very much think Mark's RFC has contributed to shifting the conversation as I described previously. And from what I know of him (we have yet...
... to speak in person), that would have been his intent: move away from entrenched points of view towards disambiguation, so that the conversation can proceed more productively.
In that sense, I would very explicitly treat it as a document that *kicked off* things, not as one describing a desired set of definitions.
And to be fair, the reasons I keep mentioning those slides with my name on is only a little pride in having made a useful contribution here: it's also and predominantly surprise!
Because when I got involved more with IETF and IRTF, it also felt to me as if there are some really bad perceptions there on that topic that don't really help move things to a better place. So I added my thoughts only to realize that a) I'm not alone there, and b) things *are* shifting, apparently.
I want to circle back to terminology again, briefly.
I don't like the "decentralization" term, precisely because it still is ambiguous. I do find talking about the different kinds of...
@jens as an activist, our advice on the term is.... retreat from it if you feel a retreat is needed, but keep in mind that the ambiguity is not an accident, it's the result of an adversarial situation.
for example, representatives of capital find it to their interests to muddy the waters on this topic... and those pyramid-scheme people had a hand in this one, too.
@jens we've seen movements get locked into endless retreat from words because they don't realize what's happening
@jens whether it's this word or another one, sooner or later you have to pick a word at which to make your stand, and defend the meaning you care about
"Newspeak" not as a mind-altering populating control thing, but as the annoying habit of certain people to make up their own meanings and use them consistently.
"Cryptocurrencies have always been more like company shares, not like currencies. How could you ever assume anything different?"
@wakame @ireneista Oh, absolutely!
It's a question of strategy. I find fighting for a "proper" definition of "decentralization" just gobbles up spoons, while it's easy enough to discuss different kinds of centralization. That's where we can lock things down better at this stage, which is why I'm so much behind that (if you hadn't noticed I am).
... centralization useful, though.
If I want to avoid the term *and* look at Baran again, then I can't help but notice that his "decentralized" usage actually describes the Web very well, and by extension current iterations of the fediverse.
The nodes we're using - our PCs or phones or whatnot - connect to a locally central point, a web/AP server, and losing that point cuts us of from the network. Those locally centralized points are connected in a mesh to, in our case, federate our...
... interactions and so create the end-to-end channels we're using here.
I share your dislike of this "top down" or "kinda centralized" operations, which combined with the terminology confusion leads me to adopt the "distributed" term. With @interpeer , I want to achieve distribution of our human-to-human interaction (I keep not using h2h networking for this, because I fest the irony will be lost on people).
Anyway, and that's the last point, I also think you've skipped over the most...
... essential part of Baran's memorandum, maybe because it *is* about low level packet switching, and that is its central concern: resilience.
Baran's line of argumentation may seem outdated or starting to be relevant again, but he's very explicitly concerned with the destruction of pivotal communications nodes, so he wants a mesh as a way to make no node pivotal.
This has an application in the packet switching underlay, but as I hopefully pointed out well, it also applies to e.g. the fedi...
... layer and its instances.
And with fedi instances, you can also talk about different kinds of (local) centralization! There's the architectural one, and the political one of having to align well enough with your admins/mods.
Personally - people don't need to agree - that's the complex of reasons that Baran's terminology is actually very, very relevant.
TL;DR: let's tease out the different kinds of centralization and its reasons, and perhaps avoid decentralization as a term entirely.
And lastly, this brings me to another DINRG topic, namely that there are two drafts relating to this that need a maintainer. I half volunteered, but haven't found time yet to do anything useful with them:
https://datatracker.ietf.org/meeting/121/materials/slides-121-dinrg-two-consolidation-drafts-a-reconsideration-00 is the presentation about them. And look, they're effectively the next logical bits in this terminology discussion (at IRTF/IETF).
I would *love* to help bring your inputs into those, but of course, again, the mailing list and discussions are free! You can do so...
... without me.
Because all nitpicking in my subthread aside (and it's nits, not disagreement!), I can think of few people better suited to that conversation than yourself!
@cwebber so is all-the-way decentralized (not just a little bit) … distributed?
@cwebber Is there a mathematical algorithm, probably from graph theory, that measures how de/centralised a network is?