Administered by:
Decentralization and erasure: Blacksky, Bluesky, and the ATmosphere
https://privacy.thenexus.today/decentralization-and-erasure-blacksky-bluesky-and-the-atmosphere-2/
There's been a lot of discussion about whether or not Bluesky and the ATmosphere (the ecosystem using the AT protocol) are decentralized. Blacksky runs three feed generators, a moderation service, and a work-in-progress personal data store (PDS) as well as providing a starter pack. And the vision for Blacksky "extends beyond any single platform".
That sounds pretty decentralized to me!
But as far as I can tell, nobody else in the discussion is talking about Blacksky as an actually-existing example of decentralization. What's with that?
The Appendix of Decentralization and erasure: Blacksky, Bluesky, and the ATmosphere is a roundup of various articles and posts on the question of whether or not Bluesky and the ATmosphere are decentralized and/or federated. There are lots of interesting perspectives here, including from @laurenshof on @fediversereport, @cyrus, @cwebber @bnewbold, @rysiek, @jonny, @possibledog, @oblomov, @rwg, and @Kye. Every single one of those posts was worth reading, and I really appreciate the time everybody's put into it.
That said, it's still very strange to me that as far as I can tell none of you mentioned what seems to me an actually-existing example of decentralization on Bluesky today.
> Blacksky could easily get their own up and running – by themselves, or working with some of the communities Fraser is already hosting.
The "easily" is doing a *lot* of work here. Roughly 16TiB of NVMe storage, based on available information – and growing fast.
This is not decentralized, the same way Google Search is not decentralized. Yes, one can spin up their own web search engine, but the cost is prohibitive.
Using multiple siloes is not decentralization.
actually relays can (soon? haven't 100% followed this development) be ran as non-archival, only storing (by default) the last 48h of events
as such the required bandwidth and storage can be decreased by a A LOT - Even at the default 48h timeframe you'd only need around 2-4TB, most of that not being used and being there more as a scaling safety measure
of course optimally I'd want relays to have the ability to connect with each other to federate information, and I've done threads about that before asking in the Bluesky dev community what they think how this issue could/should be solved and many seemed to have agreed that bringing down the storage costs and decentralizing the relays are good ways to do that - and seemingly the first measure has already happened
I figured this might be relevant context to the price & storage problem and wanted to drop it here
@cyrus interesting, thank you! This does improve the storage situation, but the bandwidth requirements will remain huge and only increase with use.
But that kind of uproots one of the expectations most users have about a social network – that posts are not ephemeral.
I'd like to see relays talking to each other, but I don't believe this will ever happen in any meaningful way on Bluesky, for reasons Christine Lemmer-Webber dove into in her write-up.
Minor clarification: oposts reside on PDSes, so they're still not ephemeral with non-archival relays.
I'm not sure about relays talking to each other, it might happen more at the appview level -- appviews talking to other appviews, appviews listening to multiple relays. There are various projects looking at independent and semi-independent subnetworks, I'm not sure what architectures they're experimeting with ... It's hard to predict at this point what will and won't work.
@rysiek@mstdn.social> Minor clarification: oposts reside on PDSes, so they're still not ephemeral with non-archival relays.
Yes, but AppViews talk to relays, not PDSes. So from the perspective of users, if relays their AppView talks to are all ephemeral, the experience is ephemeral.
@thenexusofprivacy and as far as predicting stuff is concerned, again, I would love to be wrong.
But as far as my prediction about DID:PLC from 1.5y ago is concerned, it seems right on the money:
> If I were a betting man I would bet that in five years it will keep on using the centralized DID Placeholder, and that that will be a root cause of a lot of shenanigans.
DID:PLC is no longer "Placeholder", it is now enshrined in Bluesky for good it seems.
depends on the appview actually, whtwnd.com gets posts directly from PDSs