Thread

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.

Replies (3)

But really I do not at all understand your comment here - literally the Bluesky devs encourage other relays to exist, and other people *do* run relays, just not very many because of the overhead. Suggesting that they view multiple relays as a bad thing is…. strange to me 🤷‍♂️
↩ replying to Matt Corallo
They have said over and over (maybe not in these words) that they think it's essential for apps to have a "guarantee" that they have seen all -- i.e. that users have read all that was written to them, or by someone, or with some tag etc -- that implies that the entire ecosystem of apps should rely on a single "relay". Their architecture diagrams also depict all the pieces talking to a single relay, their codebases all point to a single relay. There is no provision anywhere for an app that uses two or more relays. Of course they will say it is possible for others to run alternative relays, and they want that only insofar as it will validate their idea of decentralization, but the truth is that if someone is running an alternative relay they will not be able to use any of existing online infrastructure -- they will have to run alternative versions of everything configured to point to the new relay URL. If someone is running a relay today it's probably for hobby purposes, maybe not indexing the full network, someone trying to make their closed little sandbox of atproto, I don't know, a serious relay is already hard to run today, should get increasingly harder and virtually impossibly hard if Bluesky achieves its world domination plans.
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
Notes on Running a Full-Network atproto Relay (July 2024) | bryan newbold (✈️ vacation/travel through mid-Jan)
Note: See updated post from May 2025 describing a newer, cheaper, easier to run relay implementation! These are some informal notes on setting up ...
 that must mean it is storing all the data. So we have both BGS and AppViews requiring storing all the data?