4 ms·

>Before this new surge in activity, the firehose would produce around 24 GB/day of traffic. After the surge, this volume jumped to over 232 GB/day! >Jetstream

by S0y 2y ago

>Before this new surge in activity, the firehose would produce around 24 GB/day of traffic. After the surge, this volume jumped to over 232 GB/day! >Jetstream is a streaming service that consumes an AT Proto com.atproto.sync.subscribeRepos stream and converts it into lightweight, friendly JSON. So let me get this straight. if you did want to run Jetstream yourself you'd still need to be able to handle the 232 GB/day of bandwidth? This always has been my issue with Bluesky/AT Protocol, For all the talk about their protocol being federated, It really doesn't seem realistic for anyone to run any of the infrastructure themselves. You're always going to be reliant on a big player that has the capital to keep everything running smoothly. At this point I don't really see how it's any different then being on any of the old centralized social media.

rudyfraser 2y ago
> It really doesn't seem realistic for anyone to run any of the infrastructure themselves. You're always going to be reliant on a big player that has the capital to keep everything running smoothly I run a custom rust-based firehose consumer on the main firehose using a cheap digitalocean droplet and don't cross 15% CPU usage even during the peak 33 Mb/s bandwidth described in this article. The core team seem to put a lot of intention into being able to host different parts of the network. The most resource intensive of which is the relay which produces the event stream that Jetstream and others consume from. One of their devs did a breakdown of that and showed you could run it at $150 per month which is pricey but not unattainable with grants or crowdfunding https://whtwnd.com/bnewbold.net/entries/Notes%20on%20Running%20a%20Full-Network%20atproto%20Relay%20(July%202024) https://whtwnd.com/bnewbold.net/entries/Notes%20on%20Running...
- purlane 2y ago
  I can attest secondhand that it's possible to run a relay for ~€75/month, which is well within the range of many hobbyists.
AlienRobot 2y ago
Sometimes I think all of this could have been avoided if people knew how to use RSS.
PhilippGille 2y ago
Based on the article OP runs his Jetstream instance with 12 consumers (subsets of the full stream if I understand correctly) on a $5 VPS on OVH
pfraze 2y ago
Old social media never gave full access to the firehose so there’s a pretty big difference. If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. If you want a smaller scale view of the network, do a crawl of a subset of the users. That’s a perfectly valid usage of atproto, and is how ActivityPub works by nature.
- S0y 2y ago
  >Old social media never gave full access to the firehose so there’s a pretty big difference. That is good, but it's still a centralized source of truth. >If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. Thats just simply not true. ActivityPub does perfectly without the need of any bulky machine or node acting as a relay for the rest of the network. Every single ActivityPub service only ever interacts with other discovered services. Messages aren't broadcast through a central firehose, they're sent directly to who needs to receive them. This is a fundamental difference with how both protocols work. With ATProto you NEED to connect to some centralized relay that will broker your messages for you. With ActivityPub, there is no middle man, Instances just talk directly to each other. This is why ActivityPub has a discovery problem by the way, but it's just a symptom of real federation. >and is how ActivityPub works by nature. It's not. See Above.
  - str4d 2y ago
    > > If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. > Thats just simply not true. > [snip] > This is why ActivityPub has a discovery problem by the way, but it's just a symptom of real federation. You're actually agreeing with them! The "discovery problem" is because "federated open queries aren't feasible". > With ATProto you NEED to connect to some centralized relay that will broker your messages for you. You can connect to PDSs directly to fetch data if you want; this is exactly what the relays do! If you want to build a client that behaves more like ActivityPub instances, and does not depend on a relay, you could do so: - Run your own PDS locally, hosting your repo. - Your client reads your repo via your PDS to see the accounts you follow. - Your client looks up the PDSs of those accounts (which are listed in their DID documents). - Your client connects to those PDSs, fetches data from them, builds a feed locally, and displays it to you. This is approximately a pull-based version of ActivityPub. It would have the same scaling properties as ActivityPub (in fact better, as you only fetch what you need, rather than being pushed whatever the origins think you need). It would also suffer from the same discovery problem as ActivityPub (you only see what the accounts you follow post). At that point, you would not be consuming any of the _output_ of a relay. You would still want relays to connect to your PDS to pull data into their _input_ in order for other users to see your posts, but that's because those users have chosen to get their data via a relay (to get around the discovery problem). Other users could instead use the same code you're using, and themselves fetch data directly from your PDS without a relay, if they wanted to suffer from the discovery problem in exchange for not depending on a relay.
deleted 2y ago
[deleted]
CyberDildonics 2y ago
That's only about 2.7 MB/s on average. If someone wants to run a server, they probably would pay for a VPS with a gigabit connection, which would be able to do 120 MB/s. You might need to pay for extra bandwidth, but it is probably less than a night out every month.

by S0y 2y ago

rudyfraser 2y ago

> It really doesn't seem realistic for anyone to run any of the infrastructure themselves. You're always going to be reliant on a big player that has the capital to keep everything running smoothly I run a custom rust-based firehose consumer on the main firehose using a cheap digitalocean droplet and don't cross 15% CPU usage even during the peak 33 Mb/s bandwidth described in this article. The core team seem to put a lot of intention into being able to host different parts of the network. The most resource intensive of which is the relay which produces the event stream that Jetstream and others consume from. One of their devs did a breakdown of that and showed you could run it at $150 per month which is pricey but not unattainable with grants or crowdfunding https://whtwnd.com/bnewbold.net/entries/Notes%20on%20Running%20a%20Full-Network%20atproto%20Relay%20(July%202024) https://whtwnd.com/bnewbold.net/entries/Notes%20on%20Running...

purlane 2y ago
I can attest secondhand that it's possible to run a relay for ~€75/month, which is well within the range of many hobbyists.

AlienRobot 2y ago

Sometimes I think all of this could have been avoided if people knew how to use RSS.

PhilippGille 2y ago

Based on the article OP runs his Jetstream instance with 12 consumers (subsets of the full stream if I understand correctly) on a $5 VPS on OVH

pfraze 2y ago

Old social media never gave full access to the firehose so there’s a pretty big difference. If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. If you want a smaller scale view of the network, do a crawl of a subset of the users. That’s a perfectly valid usage of atproto, and is how ActivityPub works by nature.

S0y 2y ago
>Old social media never gave full access to the firehose so there’s a pretty big difference. That is good, but it's still a centralized source of truth. >If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. Thats just simply not true. ActivityPub does perfectly without the need of any bulky machine or node acting as a relay for the rest of the network. Every single ActivityPub service only ever interacts with other discovered services. Messages aren't broadcast through a central firehose, they're sent directly to who needs to receive them. This is a fundamental difference with how both protocols work. With ATProto you NEED to connect to some centralized relay that will broker your messages for you. With ActivityPub, there is no middle man, Instances just talk directly to each other. This is why ActivityPub has a discovery problem by the way, but it's just a symptom of real federation. >and is how ActivityPub works by nature. It's not. See Above.
- str4d 2y ago
  > > If you want large scale social networks, you need to work with a large scale of data. Since federated open queries aren’t feasible, you need big machines. > Thats just simply not true. > [snip] > This is why ActivityPub has a discovery problem by the way, but it's just a symptom of real federation. You're actually agreeing with them! The "discovery problem" is because "federated open queries aren't feasible". > With ATProto you NEED to connect to some centralized relay that will broker your messages for you. You can connect to PDSs directly to fetch data if you want; this is exactly what the relays do! If you want to build a client that behaves more like ActivityPub instances, and does not depend on a relay, you could do so: - Run your own PDS locally, hosting your repo. - Your client reads your repo via your PDS to see the accounts you follow. - Your client looks up the PDSs of those accounts (which are listed in their DID documents). - Your client connects to those PDSs, fetches data from them, builds a feed locally, and displays it to you. This is approximately a pull-based version of ActivityPub. It would have the same scaling properties as ActivityPub (in fact better, as you only fetch what you need, rather than being pushed whatever the origins think you need). It would also suffer from the same discovery problem as ActivityPub (you only see what the accounts you follow post). At that point, you would not be consuming any of the _output_ of a relay. You would still want relays to connect to your PDS to pull data into their _input_ in order for other users to see your posts, but that's because those users have chosen to get their data via a relay (to get around the discovery problem). Other users could instead use the same code you're using, and themselves fetch data directly from your PDS without a relay, if they wanted to suffer from the discovery problem in exchange for not depending on a relay.

deleted 2y ago

[deleted]

CyberDildonics 2y ago

That's only about 2.7 MB/s on average. If someone wants to run a server, they probably would pay for a VPS with a gigabit connection, which would be able to do 120 MB/s. You might need to pay for extra bandwidth, but it is probably less than a night out every month.