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

[cwebber@social.coop]

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.

[cwebber@social.coop]

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.

[cwebber@social.coop]

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

[cwebber@social.coop]

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

[cwebber@social.coop]

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?

[cwebber@social.coop]

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

[cwebber@social.coop]

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.

[puppygirlhornypost2@transfem.social]

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

[puppygirlhornypost2@transfem.social]

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

[octaviaconamore@cutie.city]

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

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

[cwebber@social.coop]

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?

[puppygirlhornypost2@transfem.social]

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

[cwebber@social.coop]

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@social.hackerspace.pl]

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

[cwebber@social.coop]

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.

[cwebber@social.coop]

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.

[cwebber@social.coop]

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.

[cwebber@social.coop]

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

[cwebber@social.coop]

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?

[cwebber@social.coop]

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