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

[cwebber@social.coop]

Now, I said I won't read replies until I am done summarizing things, and that's true, so maybe someone has gone out of their way and proven that I am wrong, that the claims in my article are factually incorrect and so on and so forth. I wouldn't know yet.

But... I don't think I'm wrong.

[cwebber@social.coop]

As said I'm very self-conscious about these things because I *don't* have formal CS training. But I do a lot of research and so I've tried to become knowledgeable about these things and this *seemed* like the correct analysis to me

Because of that, I turned to people who actually knew more than me

[cwebber@social.coop]

For one thing I derailed the entire Spritely morning standup by walking everyone through the scenario. I gave the story example, which I'll detail later.

But @dthompson didn't find the story helpful, too much narrative detail. "I need to work through this example independently." So he did.

[cwebber@social.coop]

@dthompson came back and laid it out in more formal terms and said I was right.

But I was still nervous, so I called up one of my old MIT AI Lab type friends and rambled about it to them on a call. What did they think?

[cwebber@social.coop]

"I think it's pretty clear immediately that it's quadratic. This is basic engineering considerations, the first thing you do when you start designing a system," they said.

Well that's a relief, why isn't it clear to everyone else, I asked?

So they suggested I lay it out to you as I did to them.

[cwebber@social.coop]

Let's start with the following:

- ATProto has positioned itself as "no compromises on centralized use cases". Well, in that case, let's say it can't do *worse* than eg ActivityPub. This includes with replies. You can't do *worse* than ActivityPub on replies and mentioning someone, etc.

[cwebber@social.coop]

- We will interpret the most centralized system as one where there's only one provider for storage and distribution of all messages: the least amount of user participation
- The flip side of the spectrum of maximum decentralization is the *most* amount of participation: every user self-hosts.

[cwebber@social.coop]

- Just as blogging is decentralized but Google (and Google Reader) are not, it is not enough to have just PDS'es in Bluesky be self-hosted. When we say self-hosted, we really mean self-hosted: users are participating in the distribution of their content.

[cwebber@social.coop]

- We will consider this a gradient. We can analyze the system from the greatest extreme of centralization which can "scale towards" the greatest degree of decentralization.

[cwebber@social.coop]

- Finally, we will analyze both in terms of the load of a single participant on the network but also in terms of the amount of network traffic as a whole.

Okay. That is the structure we will use for our analysis. Let's compare "message passing" vs ATProto-style "global public shared heap".

[cwebber@social.coop]

So okay. Let's get the CS notation out of the way:

"Message passing" at full decentralization:
- O(1) from a single node's perspective
- O(n) from a whole-network zoom-out perspective (inherent: add a user, it's one more user)

Okay, that's reasonable and what you'd expect

[cwebber@social.coop]

"Public global no-missed-messages (or not worse than AP) shared-heap" ATProto style at full decentralization:
- O(n) from a single user's perspective (!)
- O(n^2) from a whole-network perspective (!!!!!!)

Oof I'd better back this up because that ain't good!

[cwebber@social.coop]

In other words, as our systems get more decentralized, message passing handles things fine. Individual nodes can participate in the network no matter how big it gets. The zoom-out for the network as a whole doesn't get more complicated as we add more users OR move more users towards self hosting.

[cwebber@social.coop]

Things are NOT good, if I'm correct above, as we make things more decentralized in the atproto-public-shared-heap model. The more self-hosting and indeed the more "full nodes" join, the more it gets expensive for each of the nodes and the network EXPLODES!

Truly self-hosted atproto is NOT POSSIBLE!

[cwebber@social.coop]

And there is no solution to this without adding directed message passing. Another way to say this is: to fix a system like ATProto to allow for self-hosting, you have to ultimately fundamentally change it to be a lot more like a system like ActivityPub!

[cwebber@social.coop]

Now I left more of the precise analytical explanation in my blogpost. But social media isn't great for that, so go check out my blogpost if you want to go through all that (eg if you're more like @dthompson and less like me, I'm a narrative person) https://dustycloud.org/blog/re-re-bluesky-decentralization/

[cwebber@social.coop]

Here's our story:
- We have 26 users: [Alice, Bob, Carol, ... Zack].
- Each user sends one message per day, which is intended to have one recipient. (This may sound unrealistic, but it's fine for modeling.)
- Each user sends a message in a ring: Alice => Bob, Bob => Carol, ... Zack => Alice

[cwebber@social.coop]

Now just before you say "wait but ATProto isn't for DMs", yes, but one way this could happen is that eg Bob follows Alice, Carol follows Bob, etc.

What I'm saying is, messages can have an "intended audience". That's what we're using here.

[cwebber@social.coop]

Before we get into this, remember, the main difference between "message passing" and the "shared heap" is the former has directed and delivered messages, the latter does not. See prev blogpost for explainer.

So, what happens in a day for both systems? Because that's what we really want to find out.

[cwebber@social.coop]

Under message passing, Alice sends her message to Bob. Only Bob need *receive* the message. So on and so forth.

- For an individual self-hosted node, messages passed per day: 1.
- Per the decentralized network, total messages passed zooming out: 26.

That's about what we'd expect.