Comment by anon7000
14 days ago
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.
> 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.
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.
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.
RSS! But you can't make a personalized timeline with a pull model, and that's where the money seems to be.
I think finding where the money _isn't_ is a fun way to find interesting projects.
> 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.
There kind of is: the computers the "p" run don't allow incoming connections and don't allow long lived processes.
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.
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.