Back

This is from the "Message passing vs shared heap architectures" subsection of https://dustycloud.org/blog/how-decentralized-is-bluesky/

> A world of full self-hosting is not possible with Bluesky. In fact, it is worse than the storage requirements, because the message delivery requirements become quadratic at the scale of full decentralization: to send a message to one user is to send a message to all. Rather than writing one letter, a copy of that letter must be made and delivered to every person on earth.

You might say "well, gossip helps with this!" or something, but it doesn't.

Bluesky *strongly emphasizes* in their documentation that they are aiming for "no missed message replies". Without directed message delivery, everyone needs to *receive* every message.

Regardless of how the messages are distributed, It's O(n^2) in best case if everyone fully self hosts and there is no directed delivery.

@cwebber I'm interested to do more big-O comparisons as well.

for a large reply thread, say a thousand actively replying users on hundreds of separate instances, the number of AP messages that need to be rapidly distributed to assemble complete reply-thread view on each instance is pretty huge, no? N^2? and then also fan-out to followers?

each also needs to fetch/render media and social cards (O(instances)). and that doesn't cover *viewers* distinct from participants/followers.

@bnewbold @cwebber "assemble complete reply-thread view"

Why is that even a goal though? On a large thread there's no way to display, let alone read, all branches of the tree. I'm usually perfectly fine reading the portion of the thread that my instance just happens to know about for random reasons (usually, on account of someone on my instance following the author of that post)

@nemobis @cwebber I plan to get in to this more in a longer response to Christine's blog post, but a design goal for atproto is to have "no compromises" compared to a centralized platform. we don't want to try and convince/educate users that they don't "need" consistent and complete views of public conversations (or accurate "counts", or low-latency notifications, etc)

@bnewbold I get it, but giant threads are broken on Twitter as well, just as they are on email. People keep adding and removing ccs. There are a million different ways of displaying the tree so everyone gets surprised by whichever display sequence Twitter happens to pick. You need to click every child of every post to surface other branches of the tree which weren't displayed for whatever reason. Notifications are haphazard. Etc.

@cwebber

@nemobis @bnewbold @cwebber

But adding/removing CCs shouldn’t be the determining factor in which replies I can see.

In a big conversation, all those CCs start to take up a huge part of the message. That’s even worse considering Mastodon’s character limits.

I think most regular people don’t want to worry about the subtleties of federated networks, and just want to see the conversation without strange, unexplained gaps in the context.

I know that’s what I’d rather have.