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.
Thread
Login to reply
Replies (1)
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?
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 ...