> However, I disagree with some of the analysis, and have a couple specific points to correct.

Amber 🌸

@[email protected] no no hold on. You see, what’s super fucking annoying to me is the BLOCKED thing. You can never tell if the user is blocking you, if it was manually removed or what. It makes thread traversal nearly impossible. Huge pet peeve, I understand kinda why but they need to make it better so you can see the replies before the section being removed.

Amber 🌸

@[email protected] I was looking back at that post about the reply person who told you to do your homework on nostr and the entire thread was missing and I had to find your screenshot. It’s so fucking awful. I thought misskey was the worst, because if the parent is deleted all children are unlike akkoma which can orphan posts. No. Bsky somehow makes misskey looks sane.

Octavia con Amore :pink_moon_and_stars:

@puppygirlhornypost2 @cwebber "Bsky somehow makes misskey looks sane."

I'm sorry, HWAT!? that...that's an accomplishment

Christine Lemmer-Webber

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?

Amber 🌸

@[email protected] @[email protected] yes. At least with misskey the thread is no longer there. You can accept it that way. Bsky? No you get fragments and this horrible mess you can’t navigate. It’s like if akkoma and misskey had a child. Worst of both worlds.

Christine Lemmer-Webber

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.

viq

@cwebber hey, First Secret Goblin popped up! Does it want to be petted, or does it want to bite me in the shin and steal my lunch?

Christine Lemmer-Webber

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.

Christine Lemmer-Webber

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.

Christine Lemmer-Webber

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.

Christine Lemmer-Webber

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

Christine Lemmer-Webber

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?

Christine Lemmer-Webber

"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 ...)

Christine Lemmer-Webber

"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"!

Christine Lemmer-Webber

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*?

Christine Lemmer-Webber

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.

Christine Lemmer-Webber

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.

Christine Lemmer-Webber

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

We'll be back... after

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

Christine Lemmer-Webber

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