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

[cwebber@social.coop]

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.

[cwebber@social.coop]

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

[cwebber@social.coop]

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.

[shtrom@piaille.fr]

@cwebber Side adventure: is email federated by that definition?

[cwebber@social.coop]

@shtrom email is absolutely federated per my previous blogpost

[cwebber@social.coop]

But actually in this case, Mark Nottingham's definition happened directly within a context talking about "decentralization mechanisms", enough so that maybe it was stronger in the RFC. I dunno.

More comments on the RFC in a bit though.

[cwebber@social.coop]

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

[david_megginson@mstdn.ca]

@cwebber Yes, very true. A network is decentralised only if you can remove any node and the network keeps functioning.

If we removed a giant node like mastodon.social, we'd temporarily lose a lot of accounts but the fediverse would keep functioning just fine (probably better in the long run if it permanently eliminated a dominant player).

#fediverse

[octaviaconamore@cutie.city]

@cwebber out of curiosity, has social dot coop ever thought about not having a 500 character limit? I adored your last thread, and I'll eventually get around to reading this one as well, but it feels like having at least a few thousand per post would make it a bit less unwieldy

[cwebber@social.coop]

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.

[cwebber@social.coop]

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

[cwebber@social.coop]

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

[flippac@types.pl]

@cwebber @shtrom which is to say: the power issues arise because so many people use one of three or so providers, making them dominant within the federation

similar dynamics in B5 and at least some Trek if you want to look for them

[cwebber@social.coop]

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.

[cwebber@social.coop]

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

[cwebber@social.coop]

You should read the RFC yourself, here it is: https://datatracker.ietf.org/doc/rfc9518/

Mark Nottingham is a respected, accomplished standards author. And with good reason. Most of his work history is representing standards for big corporate players.

That's how most of it is these days, actually

[cwebber@social.coop]

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?

[cwebber@social.coop]

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

[cwebber@social.coop]

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.

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