4 ms·

Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helpin

Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra. Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But atproto architecture is a very fair experiment in this space. I can store my data on my own server, use a client app I wrote, subscribe to a specific aggregation/feed service I prefer, use the moderation list I want… all while still being connected to the larger protocol & network. It’s pretty neat.

cluckindan 9mo ago
You use routers as the beefy servers. Unicast, multicast, broadcast. Unfortunately that means the implementation needs to reach all the way into the network layer.
- direwolf20 9mo ago
  Multicast doesn't work on the global internet, and can't, due to problems of scalability and billing. It's sometimes possible to negotiate with specific ISPs to use multicast in specific ways on their network.
walletdrainer 9mo ago
> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? You design it with those requirements in mind? There’s no fundamental technical limitation at play here.
- dboreham 9mo ago
  There kind of is: the computers the "p" run don't allow incoming connections and don't allow long lived processes.
somat 9mo ago
You invert the problem. People want to build store and forward systems because that is their mental model of the problem. store and forward system are fine, and there are many advantages to them, but direct request systems scale much better. basically have each user fetch their messages from the locations they want rather than delivering the messages to them. think how the web works vs how email works.
- direwolf20 9mo ago
  RSS! But you can't make a personalized timeline with a pull model, and that's where the money seems to be.
  - azertify 9mo ago
    I think finding where the money _isn't_ is a fun way to find interesting projects.
fc417fc802 9mo ago
> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Presumably by fusing the P2P and federated models together. There's no particular reason those two models can't coexist within the same protocol. It just hasn't been created yet. Similar to how a good mesh networking implementation will make use a high bandwidth backhaul such as the internet if it's available.
- bccdee 9mo ago
  ATProto may be the closest we'll get to that. PDSes are granular enough to serve individual users, and you can (theoretically) pull from a relay and index only posts from users you're interested in for your appview, if you're hardware-limited. Relays are fungible and pretty lightweight themselves, so you're not depending too much on any central server. But people don't want to run an always-online server to send their stuff to peers, so they host it on the main bsky servers. The problem with p2p is UX; people don't want to DIY their server.

cluckindan 9mo ago

You use routers as the beefy servers. Unicast, multicast, broadcast. Unfortunately that means the implementation needs to reach all the way into the network layer.

direwolf20 9mo ago
Multicast doesn't work on the global internet, and can't, due to problems of scalability and billing. It's sometimes possible to negotiate with specific ISPs to use multicast in specific ways on their network.

walletdrainer 9mo ago

> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? You design it with those requirements in mind? There’s no fundamental technical limitation at play here.

dboreham 9mo ago
There kind of is: the computers the "p" run don't allow incoming connections and don't allow long lived processes.

somat 9mo ago

You invert the problem. People want to build store and forward systems because that is their mental model of the problem. store and forward system are fine, and there are many advantages to them, but direct request systems scale much better. basically have each user fetch their messages from the locations they want rather than delivering the messages to them. think how the web works vs how email works.

direwolf20 9mo ago
RSS! But you can't make a personalized timeline with a pull model, and that's where the money seems to be.
- azertify 9mo ago
  I think finding where the money _isn't_ is a fun way to find interesting projects.

fc417fc802 9mo ago

> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Presumably by fusing the P2P and federated models together. There's no particular reason those two models can't coexist within the same protocol. It just hasn't been created yet. Similar to how a good mesh networking implementation will make use a high bandwidth backhaul such as the internet if it's available.

bccdee 9mo ago
ATProto may be the closest we'll get to that. PDSes are granular enough to serve individual users, and you can (theoretically) pull from a relay and index only posts from users you're interested in for your appview, if you're hardware-limited. Relays are fungible and pretty lightweight themselves, so you're not depending too much on any central server. But people don't want to run an always-online server to send their stuff to peers, so they host it on the main bsky servers. The problem with p2p is UX; people don't want to DIY their server.