Recent searches
Search options
I think the "quadratic at scale" concern is the one thing I failed to share from my summary thread of the differences between "shared heap" in ATProto and "message passing" in ActivityPub.
In short: if everyone fully self hosts in message passing, you send messages between just send messages to relevant recipients
In a shared heap approach, to *not* miss relevant messages, all users must receive copies of all messages (including irrelevant ones), which is quadratic if everyone fully self-hosts
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.
@nemobis @cwebber I think this conversation really gets at a difference in approach. we (Bluesky) are trying to migrate mass numbers of users off incumbent centralized platforms into alternatives with "credible exit" and interoperation. we want to make that as seamless and low-friction as possible, and asking folks to change expectations and behavior *at the same time* cuts against that.
can see this w/ quote posts, interaction counts, recommendation feeds, etc
@bnewbold Definitely possible, and while writing the previous post I wondered whether people have vastly different experiences of what a big thread on Twitter looked like. For me it might have looked like a thread with hundreds of replies from dozens of authors branching in all directions. For others it might be, as you mentioned, mostly about celebrity posts. Maybe those have thousands of branches all attached to the same root and not so many layers? I'd love to see some analysis.
A quick search surfaces surprisingly little prior art. (I'm probably not looking at the right keywords.)
https://arxiv.org/abs/2105.11596
https://arxiv.org/abs/2407.06998