Thread

What, an "optimization"? Are you suggesting that Bluesky would work today without the optimization, just slightly slower? Or what do you mean by that? If your information isn't out of the date you probably know that nothing of Bluesky works without the "relay". And sure, you can argue, as you have elsewhere, that Bluesky can change to actually connect directly to PDSes, but then you will need to trash all the labelers, feed generators and app views and the client app codebases, as they all assume the existence of the "relay", and then you'll have to create a query language for the PDSes and proceed to recreate all of these things on the clients directly -- and then obviously you would have just created Nostr again (and then you have to start working on the same problems Nostr has been working on for the past years). If that ever happens then great, we don't need Nostr anymore -- but if you are indeed following Bluesky you have probably read directly from the Bluesky creators that they do not intend to do any of this decentralized data-fetching stuff ever because they think it is a bad idea to not have a canonical centralized source of data, it's an irreconciliable divide and no "progress towards decentralization" can be expected from them, at least not decentralization in the way we understand it.

Replies (2)

The comment about relay being an optimization was somewhat nitpicky, you’re just using the wrong term (technically the relay is a proxy between all the PDs’ and the app view, the app view stores all the posts too and you could drop the relay and replace it with the app view(s) connecting to all the PDSs directly). The “App View” is a server that returns the posts to display in the feed to clients (eg the mobile app). In practice the App View is what *has* to have a full copy of all the tweets, much like a nostr relay works in practice today. Clients simply making the same request to multiple App Views wouldn’t result in having to rewrite or throw anything away, I have no idea why you’re suggesting that - in general you’ll get the same response from each, just have to merge them on the client side.
I don't know about your claims that the App View is the server that has to store everything. It's not clear what they do exactly, looks like they are just another soft-centralizing layer like a web2 backend that talks to the BGS (I'll start calling "relay" BGS because that's a much better name) and caches data for user consumption and also talks to users's PDSes on behalf of clients? In any case given that to run a BGS today you need many terabytes of disk that must mean it is storing all the data. So we have both BGS and AppViews requiring storing all the data?