How Decentralized Is Bluesky Really? https://dustycloud.org/blog/how-decentralized-is-bluesky/
A technical deep-dive, since people have been asking me for my thoughts. I'll expand a bit on some of the key points here in a thread. 🧵
A technical deep-dive, since people have been asking me for my thoughts. I'll expand a bit on some of the key points here in a thread. 🧵
Comments
I hope you enjoyed the tea
If you write something in the future, about this or something else, send me a link! 💜
This can be mitigated however with something like ERIS https://eris.codeberg.page/
Big topic, a bit too big for this thread
I'm through 1/3... and the costs of decentralization are one thing... I'm interested, and I hope you get to the opportunities.. ie. bluntly $. I see it more as a value question than a cost question. Is this the front end of an ecosystem?
"The physical world equivalent would be that every user had their own house at which they stored a copy of every piece of mail delivered to every other user at their house."
it's a very valuable did method for services
I'm not sure the issues with DID<->domain binding that Christine raises are that serious
That shared heap explainer is only the case if *everyone thoroughly self-hosts* in the shared heap model tho
I do think that maybe a different venue might be better for getting into that tho!
i'd like to host one, where can I do that?
i don't think i can afford a FTE salary just to host it, tho.
But it doesn't matter I get what you're going for, haha
Nothing may ever be truly perfect, but I’m glad to know people who care are fighting for it to reach those heights.
oof.
I would be grateful if you added ID attributes to the header tags in this document, so I could link to/bookmark its sections directly (e.g., the excellent explanation of what "The organization is a future adversary" *actually* means beyond some nebulous sci-fi dystopic concept).
AsciiDoc might be good but those rich semantics make it so damn complicated that there's only one implementation.
· foolproof to compose
· self-evident to read
· actually suitable for technical documents
It is my hypothesis the combination of any two of these goals becomes mutually exclusive to the third.
there are multiple implementations
https://asciidoctor.org/
https://asciidoc-py.github.io/
as long as you stick with the basics its also not much harder than markdown
https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-markdown/#comparison-by-example
'Asciidoctor Mathematical' is my main reason to use asciidoc, i find it a lot simpler than latex
But like JavaScript, it reflects the result of letting a novice define a standard by themselves.
"if only users on five servers need to know about a message, out of tens of thousands of servers, only those five servers will be contacted", talking about AP.
would you say then that AP is just not suited for the same applications as atproto?
"but the ideal version of decentralization is that everyone self-hosts, and from a resource perspective, this is perfectly possible to do", talking again about AP.
I don't think this is true or even should be the goal of decentralization. not everyone can/would self-host
Absolutely fascinating thread btw. Taking so many notes. 🙏
I barely even referenced what I wrote in the blogpost because the structure had been burned in
I'm curious about how Jetstream fits here with respect to relays. Having to consume or host the full firehose is a huge liability, but being able to filter on subscribe might change that?
My first thought was "I don't even want to host a feed if I need to consume this much raw traffic", even with the hydration done by the PDS.
But I *think* Jetstream lets you filter by DID before even getting the data?
With those two filters alone, my own app or feed built on this network would really only have to scale up to the amount of accounts that actually use it, so it doesn't need to be Internet Scale.
As an app dev if I am using Jetstream that becomes a commodity?
That'll change. I do think we need lots of alternative providers so that it becomes a commodity. That's how I think you get to "distributish" enough to make it a net win for the Internet at large.
https://bsky.app/profile/why.bsky.team/post/3lbjdux6ubc2f
Medium term it seems like only the AppViews will be particularly centralized, which I think is a good thing tbh.
Now that I'm thinking about it, This would make it possible to create "gated communities" of PDSs that only accept requests from certain relays.
with a cache in between i think this might become viable for a small parallel indie appview.
- so far i’m finding this doable at pretty low cost
- one link aggregator could be shared by multiple appviews to split costs
https://bsky.app/profile/bnewbold.net/post/3lbiyukqs2c2x
bsky puts all bsky content into a big (centralized) db in the appview. i’m not sure that’s essential if you’re not serving millions of clients.
However, the "credible exit" goal is worth perusing, and does use decentralization techniques! But it is not decentralization/federation without moving the goalposts on those terms.
The fact that Bluesky's team has managed to scale to receive such users is incredible, nearly feeling miraculous.
thank you / congrats @dustyweb.bsky.social!
planning to reply in longer form soon
Thanks so much for authoring all this.
https://therecord.media/bluesky-access-blocked-pakistan
I'll say a bit more below
However the group came in with 3 different competing directions (linked data (Solid), REST'ish (ActivityPub), indieweb (micropub etc)). For a while it looked like we might hit full convergence; it was stressful, but we tried
This was really upsetting, one of my colleagues even left the group over it
However, ActivityPub *DID* manage to achieve massive interoperability work with the groups that started with a message-passing mindset. That took a lot of work developing consensus from other groups
does the thread stretch across the atlantic and back
OCapPub goes into this at a high level https://gitlab.com/spritely/ocappub/blob/master/README.org
But the real work to address this is happening at @spritelyinst.bsky.social