Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ATProto for Distributed Systems Engineers

atproto.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: ATProto for Distributed Systems Engineers

#11

Post by jmusall »

LelouBil wrote: post #2

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.

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?

Re: ATProto for Distributed Systems Engineers

#12

Post by riffraff »

echelon wrote: post #8
LelouBil wrote: post #2

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.

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 supernode…

> 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...

Re: ATProto for Distributed Systems Engineers

#13

Post by evbogue »

blackqueeriroh wrote: post #10
echelon wrote: post #8

Earlier quoted context omitted.

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 supernode…

Any PDS can talk to another PDS, yes.

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.

Re: ATProto for Distributed Systems Engineers

#14

Post by jauntywundrkind »

evbogue wrote: post #7
skybrian wrote: post #6

Earlier quoted context omitted.

Not quite sure what you're getting at with "authenticated distributed data," but records that came from a PDS are signed by the PDS. The signatures are there to enable untrusted mirrors to be used for distribution. There's a downside: you can't really disavow a post. But that doesn't seem to be the purpose of the signatures? It's more of an unfortunate side-effect. In practice, this can be annoying and there are alte…

Yah it clearly has always done this, but why doesn't it support multi-PDS replication? But you're right that the screenshot proto and the copy and paste proto are quite successful as a distributed system these days.

There's nothing stopping multi-PDS replication right now. It would work fine. No one would know that content is available elsewhere, is kind of the main chicken-and-egg problem.

Hubble is starting to come online, which is a network cache. With excellent storage and runtime characteristics, cheap to run. I'm not sure if this is in the same https://microcosm.blue banner-head, but the same developer, as another incredibly fantastic network service that's open for use, that's open source, that other people can also run themselves. https://atproto.com/blog/introducing-hubble-a-public-mirror-...

I agree that yes the PDS's hopefully start doing more mirroring too. It'd be nice if they would themselves also attest that they have seen it too.

Re: ATProto for Distributed Systems Engineers

#15

Post by janandonly »

marci wrote: post #9
echelon wrote: post #8

Earlier quoted context omitted.

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 supernode…

Then maybe what you want is email? Sprinkled with a little bit of https://delta.chat ? And potentially a dash of iroh https://news.ycombinator.com/item?id=48542480 https://www.iroh.computer/solutions/delta-chat ?

Delta.chat no longer uses email though, right?

Re: ATProto for Distributed Systems Engineers

#16

Post by danabramov »

Shameless plug, but if this got you interested, I have a couple of longreads on the topic:

- https://overreacted.io/a-social-filesystem/

- https://overreacted.io/there-are-no-instances-in-atproto/

From the official site, I'd also recommend https://atproto.com/articles/atproto-ethos

Re: ATProto for Distributed Systems Engineers

#17

Post by danabramov »

jmusall wrote: post #11
LelouBil wrote: post #2

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.

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…

>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-...

[2]: https://constellation.microcosm.blue/

Re: ATProto for Distributed Systems Engineers

#18

Post by danabramov »

echelon wrote: post #8
LelouBil wrote: post #2

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.

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 supernode…

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 and https://atproto.com/articles/atproto-ethos#synthesis

Re: ATProto for Distributed Systems Engineers

#19

Post by giancarlostoro »

jmusall wrote: post #11
LelouBil wrote: post #2

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.

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…

Lol reminds me of "ITS SERVERLESS!" Which always cracks me up, as someone who does find serverless useful for very strategic scenarios, naming things as though they don't require a computer somewhere to function has been one of the weirdest trends in tech.
Post reply on HN