Replying to @⁨rysiek@mstdn.social⁩

@rysiek @anominominominous I guess that you are mixing up relays with the AppView. Relays aren't very cost intensive. There are some independant out there, have for example a look here: firehose.stream/ and status.vayumandala.com/

AppView is cost intensive.

firehose.streamFirehose Stream | ATProto Jetstream NetworkGlobal ATProto Jetstream Network with public instances worldwide
en

Replying to @⁨heluecht@pirati.ca⁩

@heluecht @anominominominous I am basing this on analysis by Christine Lemmer Webber, who is as much an expert on this as anyone can be:
dustycloud.org/blog/how-decent

> In July 2024, running a Relay on ATProto already required 1 terabyte of storage. But more alarmingly, just a four months later in November 2024, running a relay now requires approximately 5 terabytes of storage.

dustycloud.orgHow decentralized is Bluesky really? -- Dustycloud Brainstorms

Replying to @⁨rysiek@mstdn.social⁩

@rysiek @heluecht @anominominominous I don't have a more up-to-date analysis to give you, mostly just following all the devs over there and see what people are up to. Would be good to see some new people come in fresh and try to partake in the network with a fresh pair of eyes. @ricci has been doing good work trying to understand and publicize the actual state of things lately.

Replying to @⁨liaizon@wake.st⁩

@liaizon

[For context, this is about #atproto / #bluesky]

Couple things:

1) Yes, it is generally the case that AppViews are, by far, the more expensive thing to run now; there is some stale information about relays being expensive because they used to hold full network history. However, this has changed and not even the Bluesky-run relays do this anymore. The cost of running the relay is just the bandwidth, which is currently around 20Mbps - negligible storage, fairly low compute needs, not a ton of RAM.

2) The AppView is now the main part of the network that has to store a bunch of stuff, have the necessary compute to be doing constant stores and lookups, and lots of RAM to hold caches and indexes, etc.

3) As pointed out above, this is for *Bluesky* records, you can put, to a first approximation, whatever data you want on the network, and if you are building an app that doesn't need to see every Bluesky post, like a long-form publishing app, your AppView can be much smaller.

HOWEVER

4) Costs are in large part proportional to the *number of subscribers pulling data from them*. Yes, if you run a relay and no one uses it, it's cheap; 20Mbps in is not expensive these days (in fact, I am bringing *five* complete copies of the network into my living room from different relays for Reasons). BUT if you are going to run a relay that has very many subscribers, this changes. I highly doubt that any of the indie relays running now (of which there are several) could take over the load of the Bluesky-run relays.

5) All of the above is true of the *current* network. If you believe the people that claim that atproto is not just about micoblogging, and is the foundation of the future Internet, then 20Mbps is laughably small, and almost certainly means that a relay - with the current architecture - would be out of basically everyone's reach in the future.

6) The data model in atproto means that if you want to see things that reference your records (replies, likes, mentions, etc.) then *someone* has to see and index them. At the current network size, this is not too bad, and people run services to do this, that get real usage, on Raspberry Pis. But, this only stays true if the network stays fairly small, see point above.

7) Bluesky is making a network node called Jetstream, which is a different sort of relay, more capable and it will probably become even more central than it already is; the new version of Jetstream DOES have history data, and it's operations are more complex (does more cryptography and data validation, can serve subsets of the network to subscribers). So, it may very well shift back to being the case that the *kinds of relays that matter* are expensive to run. In large part this is because:

8) The basic data and network models stream *everything*, not just the kinds of records your app uses. You are running a longform blog app and need to see when your 1,000 users publish new entries? Congratulations, you have to listen to everything that happens on any app on the network from all users everywhere. Doable in the current network, but obviously absurd if you believe the "protocol of the future network" story. This is the problem that Jetstream solves: it lets you subscribe to just the bits of the network you want. Great. But, it means that relays are fundamentally more expensive to run since instead of basic pipes that just do fan-out, they have to do subsetting and feed different stuff to each subscriber. So, if the network, and the number of apps it grow, there is a shift back from cheap relays to potentially very expensive jetstreams.

@rysiek @heluecht @anominominominous