social.coop is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Fediverse instance for people interested in cooperative and collective projects. If you are interested in joining our community, please apply at https://join.social.coop/registration-form.html.

Administered by:

Server stats:

502
active users

Now here is Bryan's definition (more accurately Mark Nottingham's definition (more accurately, Paul Baran's definition)) of decentralization:

> [Decentralization is when] "complete reliance upon a single point is not always required" (citing Baran, 1964)

Uh, hm... this seems... pretty weak?!

This definition of decentralization is so weak it may as well say "Users occasionally not rely on a central gatekeeper, as a treat"

It's pretty weak, and yeah Bluesky qualifies, but that's... I'm gonna be honest that's an *incredibly* weak definition by comparison

Let's look at the delta between my definition of decentralization and the one chosen by Bryan:
- The discussion of power dynamics, and diffusion thereof, is removed
- The "phrase complete" reliance is introduced, so incomplete reliance is now ok
- And not only that, now it's "not always required!"

In my previous blogpost I had expressed worry about moving the goalposts of "decentralization". That is *exactly* what's happening here, and what's being said is "if we weaken the definition dramatically, then Bluesky qualifies"

This is, IMO, not a very compelling look I've gotta say

Now you might notice this citation [Baran, 1964] and hey if you work on network things you might be thinking "Hey Christine, wait isn't this one of the seminal papers on networking which led to the internet?"

GOOD QUESTION LET'S COME BACK TO THAT

The context is CRITICAL.

Back to that in a moment.

Okay so "decentralization", maybe Bluesky qualifies if we use an unimaginably weaksauce definition that's so loose you don't even have to comply with it hardly at all?

So okay now let's compare definitions of "federation".

My definition:

> [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.

Bryan's definition (more accurately Mark Nottingham's definition):

> [...] federation, i.e., designing a function in a way that uses independent instances that maintain connectivity and interoperability to provide a single cohesive service.

Hm okay, well these don't look quite as far apart, right?

So what's the delta?

- The discussion of power dynamics, once again, is not present.
- "Cooperation" is not present.
- And very specifically, "decentralization" and "no node holding more power than the responsibility or communication of its parts" is not present.

Turns out this has a big effect.

Re-read and compare. Under that last definition, even corporate but proprietary internal microservice architectures or devops platforms would qualify as federated!

Maybe? But it's not federation in a *decentralization* context.

(That last observation is thanks to @vv btw, good observation from a good gf)

Bryan then acknowledges it's a comparatively low bar:

> What about federation? I do think that atproto involves independent services collectively communicating to provide a cohesive and unified whole, which both definitions touch on, and meets Mark's low-bar definition.

However, Bryan does concede the following:

> Overall, I think federation isn't the best term for Bluesky to emphasize going forward, though I also don't think it was misleading or factually incorrect to use it to date.

Well okay, actually that's quite the thing to concede, so massive props on that

Bryan also in that same paragraph goes on to mention some very interesting history about Bluesky's earlier prototypes and how the design changed. Worth reading btw. But that's an aside, kinda.

It seems that there might be more of a concession here that Bluesky isn't federated, so the bigger question really is whether or not it's decentralized.

I mentioned that the definition is interesting in context and BOY is it interesting in context, oh gosh oh boy

Hey remember earlier when I said this thing:

> now here is Bryan's definition (more accurately Mark Nottingham's definition (more accurately, Paul Baran's definition)) of decentralization

Did you notice all the parentheses? That's not JUST because I love lisp

I mean I do love lisp

But not only

We need to understand Mark Nottingham's RFC and we need to understand Paul Baran's seminal 1964 paper both, within the contexts they were written, before we can pull this quote-of-a-quote out.

So let's start with the RFC.

If you hear "Respected standards technologist Mark Nottingham's independent IETF RFC 9518: Centralization, Decentralization, and Internet Standards", what do you think you'll find inside?

I'll tell you what I'd expect

Rah rah decentralization!! The internet was meant to be free!!!

Well...

The surrounding context of the RFC is a debate within the IETF and elsewhere: gosh! this internet! it sure seems to have centralized a *lot*, is this really what we wanted to happen to it? This wasn't the original vision!

Shouldn't standards orgs do something to fix it?!

Well should they?

Mark Nottingham's own words answer better than I do, and you should read the RFC. It's not quite one way or the other. It's kind of a "well decentralization is great and yeah centralization is bad but how realistic is decentralizing things anyway and when?"

But Mark's own words handle it better

From the RFC:

> This document argues that, while decentralized technical standards may be necessary to avoid centralization of Internet functions, they are not sufficient to achieve that goal because centralization is often caused by non-technical factors outside the control of standards bodies. As a result, standards bodies should not fixate on preventing all forms of centralization; instead, they should take steps to ensure that the specifications they produce enable decentralized operation.

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!

Christine Lemmer-Webber

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 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 threepanelsoul.com/comic/job-i)

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

All of Three Panel Soul is good, but the Tech Bro ones are my favorites threepanelsoul.com/comic/searc

I love Three Panel Soul so much

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

*COUGH* where was I

www.threepanelsoul.comThree Panel Soul - Job Interviews

"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

@cwebber
I keep refreshing this thread like a mystery novel and the cliffhanger is making me ghasp

@cwebber

I love, how you're telling your story.

Especially, the little strides to the sides make it very entertaining to read, despite the length and the non-trivial content.

(I might have left enough stars in the process of reading to create you some annoyance - sorry).

It is truly fascinating (and worrying) how much power over real things arises from controlling the semantics of terms.

Needless to say, I align pretty much with your idea of "(de)centralisation".

@cwebber [ANNOUNCER VOICE]
Do you suffer from Nose Is Cold? Millions of people endure this condition every day.

Fortunately, Tea Break Industries has just released its breakthrough remedy: Cup Of Tea.

Cup Of Tea is hot, fresh, & available in caffeinated or non-caffeinated; with optional milk & sugar. It’s guaranteed to hydrate, invigorate, & warm your nose.
Look for Cup Of Tea in finer kitchens & break rooms everywhere.

[We now return you to our regularly scheduled Christine.]

@cwebber

You ate hummus without bread ????
You heathen !

@cwebber It is the middle of the night and I am worried that reading this post in my head is going to wake my dog

@cwebber What’s the next logical progression?
Zero trust?
Ephemeral mesh?

@cwebber @3psboyd
Something I think is really important for people to understand about those programming problems before they post comics like this is that, even though they don't accurately mimic the day-to-day of professional programming work, they do teach a lot of skills in terms of solving the unique problems that people encounter, and tell potential employers that the person who solves them knows enough to solve a programming problem.

Keep in mind that the vast majority of applicants for programming jobs, including a large chunk of people with degrees in computer science, do not know how to do any programming in any language. Solving weird programming problems at least shows a degree of general competency.

@Raccoon @cwebber In the past I've generally been able to tell if someone doesn't know how to program by speaking to them for a few minutes.

@3psboyd @cwebber
"Yes I had chat GPT write that block for me. It knows better than I do how to solve the Fizz Bin problem."

@cwebber
So, the Fediverse is B? I've always thought it more as C.

And we all know the corporate controled networks is A

@bob @cwebber If I'm understanding right, I think the fediverse (activity pub) is more like C with many nodes fully participating (27,000?) but each node has a starburst like A and B of users connecting to that node. But maybe I'm misinterpreting.

@semitones @cwebber
I've been on computers since the 80's and the different network types... so, I've always thought of ActivityPub and XMPP like C but the term people use for the Fediverse is B... Just for confusion 😜

@cwebber this is literally in [[decentralized]] in the Agora (the social knowledge graph I'm developing) but I didn't know where it was from, thanks for finding the source!

It should of course also be linked at [[distributed]] for completeness :)

@cwebber
I love the figure.

The figure is love, the figure is life.

All hail FIG. 1.

@cwebber Isn't this part of the reason why the Internet became SO successful?

There is a lot of technology that is less centralization

@cwebber Also on how it could have ended up in implementation:
en.wikipedia.org/wiki/X.25

VC may be established using X.121 addresses. The X.121 address consists of a three-digit data country code (DCC) plus a network digit, together forming the four-digit data network identification code (DNIC), followed by the national terminal number (NTN) of at most ten digits.

en.wikipedia.orgX.25 - Wikipedia

@cwebber but seriously that’s such a good paper and it’s always a good day to reread it

@cwebber Mmmmm! The wife got me into making hummus from scratch, and I can't resist a good homemade hummus. 😋

@cwebber Second Secret Goblin doesn't judge, only nudges you to share hummus

@cwebber the Hummus Goblin knows what you did :dragneyes:

Found Secret Goblin #2!

@cwebber given the choice I'd choose hot chocolate too. ☕

@cwebber This thread is so long it's like LOST or The 100 I want to so much know how it continues but its past midnight here in Europe and I gotta sleep I'll binge the rest tomorrow. Thanks Christine for writing this!