4 ms·

I feel like it's the best ATProto architecture explanation on the web. I hope it will make people who argue that "there are no instances in ATProto" is wrong,

I feel like it's the best ATProto architecture explanation on the web. I hope it will make people who argue that "there are no instances in ATProto" is wrong, understand that it is actually true and not just a naming debate.

echelon 2mo ago
Is ATProto federated, P2P, or a protocol flexible enough to build all kinds of things? Is it opinionated about which type of system to build? Skimming this page, it looks like ATProto is a schema for the ontology, and despite saying "P2P", it looks built around federation and concerned about scaling infrastructure (rather than scaling message broadcast). I'm interested in a p2p social network with federated supernodes (p2p first class, federation second class, relays for devices that don't want to join the swarm) for people and agents. Could you easily build that with ATProto, or is it the wrong domain? I'm interested in true, first-class P2P. Not a bolt-on afterthought. That's the problem with all of these federated services like Bluesky and Mastodon. A true social protocol should work like email. Any machine on the network should be able to talk it to any other machine. Of course centralization nodes will appear, but they should be optional. Used as aids for user friendliness, anonymity, and firewalling yourself off.
- marci 2mo ago
  Then maybe what you want is email? Sprinkled with a little bit of https://delta.chat https://delta.chat ? And potentially a dash of iroh https://news.ycombinator.com/item?id=48542480 https://news.ycombinator.com/item?id=48542480 https://www.iroh.computer/solutions/delta-chat https://www.iroh.computer/solutions/delta-chat ?
  - janandonly 2mo ago
    Delta.chat no longer uses email though, right?
    - marci 2mo ago
      delta.chat is email https://delta.chat/en/help#can-i-use-a-classic-email-address-with-delta-chat https://delta.chat/en/help#can-i-use-a-classic-email-address...
- blackqueeriroh 2mo ago
  Any PDS can talk to another PDS, yes.
  - evbogue 2mo ago
    Yes, and is that useful within the structure of the Bluesky ecosystem? What if PDSes replicated the content of PDSes? Then it'd be available.
  - culi 2mo ago
    They do not directly talk/query each other. But Relays and AppViews allow PDS's to be aggregated to create apps like BlueSky. I don't think anyone would describe ATProto as p2p
- riffraff 2mo ago
  > A true social protocol should work like email. Any machine on the network should be able to talk it to any other machine You may find littlefedi interesting https://littleone.littlefedi.social/@stefano/blog/2026/08/07/littlefedi-a-fediverse-server-that-doesn-t-need-a-data/ https://littleone.littlefedi.social/@stefano/blog/2026/08/07...
- danabramov 2mo ago
  Some atproto designers come (somewhat disillusioned) from the p2p world, you can read what they have to say about that here: https://atproto.com/articles/atproto-ethos#peer-to-peer https://atproto.com/articles/atproto-ethos#peer-to-peer and https://atproto.com/articles/atproto-ethos#synthesis https://atproto.com/articles/atproto-ethos#synthesis
- mort96 2mo ago
  Mastodon works like email. Users have their data hosted on instances and most big instances can communicate with most other big instances, and all instances blacklist a bunch of other instances for spam or political reasons. Just like e-mail.
- culi 2mo ago
  ATProto is definitely not P2P and probably not federated. Every user has their own personal storage and gives apps like Bluesky permission to write to them. They solve different problems and, in theory, you can use ATProto and ActivityPub (Mastodon/Threads/Peertube/etc) together
jmusall 2mo ago
The article did not make me understand that at all. > Since we're making a new app, we're going to want two things: an app server (which hosts our API & frontend) and a view server (which collects data from the network for us). Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances? Also: > Why are we listening to the event stream if we're the one making the write? Because we're not the only ones making writes! There are lots of user repos generating events, and lots of apps writing to them! Who is hosting this event stream? Aren't we making some kind of federated network by deciding on our app server which event streams or which users/apps pushing updates to listen to?
- danabramov 2mo ago
  >Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances? There are two main kinds of "nodes" in atproto: - Hosting aka "personal data servers" (PDS). This is dumb JSON hosting that you can query by HTTP or watch by Websocket. Super cheap to run. They don't talk to each other. You can have one per user, or one per many thousands. - Apps. These are your normal webapps. (But they ingest data from everyone's hostings.) They also don't talk to each other. So yes, there are "instances" in the sense of "boxes which run software" but the topology is completely different from Mastodon or such. Data flows from hosting into apps (and then apps write to hosting). There is no hosting-to-hosting or app-to-app connection. Hosting is app-agnostic, and apps are hosting-agnostic. To make all of this practical, there are things in the middle that make the situation easier for app developers — either relays (which combine event stream from many hostings), or caches like Hubble[1] and Constellation[2] (which let you query the entire network in one request). >Aren't we making some kind of federated network by deciding on our app server which event streams or which users/apps pushing updates to listen to? Ideally you would listen to every relevant event from the entire network (and filter out every irrelevant one). It isn't hard today — you can either use an existing relay or run your own for ~$30/month or pool with someone. The discovery mechanism is that (1) a hosting can request any relay to crawl it, and (2) a relay can discover more hostings it hasn't crawled yet by following links — similar to how Google crawls the web. [1]: https://atproto.com/blog/introducing-hubble-a-public-mirror-for-the-whole-atmosphere https://atproto.com/blog/introducing-hubble-a-public-mirror-... [2]: https://constellation.microcosm.blue/ https://constellation.microcosm.blue/

echelon 2mo ago

Is ATProto federated, P2P, or a protocol flexible enough to build all kinds of things? Is it opinionated about which type of system to build? Skimming this page, it looks like ATProto is a schema for the ontology, and despite saying "P2P", it looks built around federation and concerned about scaling infrastructure (rather than scaling message broadcast). I'm interested in a p2p social network with federated supernodes (p2p first class, federation second class, relays for devices that don't want to join the swarm) for people and agents. Could you easily build that with ATProto, or is it the wrong domain? I'm interested in true, first-class P2P. Not a bolt-on afterthought. That's the problem with all of these federated services like Bluesky and Mastodon. A true social protocol should work like email. Any machine on the network should be able to talk it to any other machine. Of course centralization nodes will appear, but they should be optional. Used as aids for user friendliness, anonymity, and firewalling yourself off.

marci 2mo ago
Then maybe what you want is email? Sprinkled with a little bit of https://delta.chat https://delta.chat ? And potentially a dash of iroh https://news.ycombinator.com/item?id=48542480 https://news.ycombinator.com/item?id=48542480 https://www.iroh.computer/solutions/delta-chat https://www.iroh.computer/solutions/delta-chat ?
- janandonly 2mo ago
  Delta.chat no longer uses email though, right?
  - marci 2mo ago
    delta.chat is email https://delta.chat/en/help#can-i-use-a-classic-email-address-with-delta-chat https://delta.chat/en/help#can-i-use-a-classic-email-address...
blackqueeriroh 2mo ago
Any PDS can talk to another PDS, yes.
- evbogue 2mo ago
  Yes, and is that useful within the structure of the Bluesky ecosystem? What if PDSes replicated the content of PDSes? Then it'd be available.
- culi 2mo ago
  They do not directly talk/query each other. But Relays and AppViews allow PDS's to be aggregated to create apps like BlueSky. I don't think anyone would describe ATProto as p2p
riffraff 2mo ago
> A true social protocol should work like email. Any machine on the network should be able to talk it to any other machine You may find littlefedi interesting https://littleone.littlefedi.social/@stefano/blog/2026/08/07/littlefedi-a-fediverse-server-that-doesn-t-need-a-data/ https://littleone.littlefedi.social/@stefano/blog/2026/08/07...
danabramov 2mo ago
Some atproto designers come (somewhat disillusioned) from the p2p world, you can read what they have to say about that here: https://atproto.com/articles/atproto-ethos#peer-to-peer https://atproto.com/articles/atproto-ethos#peer-to-peer and https://atproto.com/articles/atproto-ethos#synthesis https://atproto.com/articles/atproto-ethos#synthesis
mort96 2mo ago
Mastodon works like email. Users have their data hosted on instances and most big instances can communicate with most other big instances, and all instances blacklist a bunch of other instances for spam or political reasons. Just like e-mail.
culi 2mo ago
ATProto is definitely not P2P and probably not federated. Every user has their own personal storage and gives apps like Bluesky permission to write to them. They solve different problems and, in theory, you can use ATProto and ActivityPub (Mastodon/Threads/Peertube/etc) together

jmusall 2mo ago

The article did not make me understand that at all. > Since we're making a new app, we're going to want two things: an app server (which hosts our API & frontend) and a view server (which collects data from the network for us). Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances? Also: > Why are we listening to the event stream if we're the one making the write? Because we're not the only ones making writes! There are lots of user repos generating events, and lots of apps writing to them! Who is hosting this event stream? Aren't we making some kind of federated network by deciding on our app server which event streams or which users/apps pushing updates to listen to?

danabramov 2mo ago
>Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances? There are two main kinds of "nodes" in atproto: - Hosting aka "personal data servers" (PDS). This is dumb JSON hosting that you can query by HTTP or watch by Websocket. Super cheap to run. They don't talk to each other. You can have one per user, or one per many thousands. - Apps. These are your normal webapps. (But they ingest data from everyone's hostings.) They also don't talk to each other. So yes, there are "instances" in the sense of "boxes which run software" but the topology is completely different from Mastodon or such. Data flows from hosting into apps (and then apps write to hosting). There is no hosting-to-hosting or app-to-app connection. Hosting is app-agnostic, and apps are hosting-agnostic. To make all of this practical, there are things in the middle that make the situation easier for app developers — either relays (which combine event stream from many hostings), or caches like Hubble[1] and Constellation[2] (which let you query the entire network in one request). >Aren't we making some kind of federated network by deciding on our app server which event streams or which users/apps pushing updates to listen to? Ideally you would listen to every relevant event from the entire network (and filter out every irrelevant one). It isn't hard today — you can either use an existing relay or run your own for ~$30/month or pool with someone. The discovery mechanism is that (1) a hosting can request any relay to crawl it, and (2) a relay can discover more hostings it hasn't crawled yet by following links — similar to how Google crawls the web. [1]: https://atproto.com/blog/introducing-hubble-a-public-mirror-for-the-whole-atmosphere https://atproto.com/blog/introducing-hubble-a-public-mirror-... [2]: https://constellation.microcosm.blue/ https://constellation.microcosm.blue/