The way I used arrows might’ve been a bit confusing because I use two types of them.

The solid ones pointing from @alice.com downwards indicate ownership. They’re the same thing as grouping by color. All blue stuff is Alice’s.

The dashed ones pointing between records are links. Those are equivalent of <a href>. Any record can link to any other record, no matter which repositories either is in.

When you comment on someone’s post, your comment goes into your repo, but it has a link to the parent post (which may be in any repo). That’s usually how you want to represent it in the data model so that anyone indexing both records can reconstruct the relationship.

In the example, Bob comments on Alice’s post. So Bob’s comment is in Bob’s repo and Alice’s post is in Alice’s repo.

To clarify your specific point, a person commenting on your post will create record in their repo. In fact one can never create records in somebody else’s repo. That’s the central premise.

Hope that makes sense.

Also not totally clear to me (apologies if I missed it in the post) is where repositories live, I have a bsky account with my own domain, but I am not running anything to host a repo. Am I correct in assuming that bsky is hosting my repo, but I would have the option to self host or move it elsewhere and continue using bsky?

It would be expensive if you don’t do your own aggregation. The recommendation for social atproto apps is to aggregate the records you care about into a local database and essentially build your app-specific index/cache of the network.

Ctrl+F to this part: “Coincidentally, that’s the exact mechanism you would use for aggregation. You listen to events from all of your app users’ repositories, write them to a local database, and query that database as much as you like with zero extra latency.”.

(One interesting consequence is that indexing the network can also be done by someone on your behalf, see https://slices.network/ for an upcoming experiment in that area.)

> Also not totally clear to me (apologies if I missed it in the post) is where repositories live, I have a bsky account with my own domain, but I am not running anything to host a repo.

Yeah, Ctrl+F here: ”Note that https://alice.com and at://alice.com do not need to resolve to the same server. This is intentional so that having a nice handle like @alice.com doesn’t force Alice to host her own data, to mess with her website, or even to have a site at all. If she owns alice.com, she can point at://alice.com at any server.”

You can inspect where at:// points for your handle in an online browser like http://pdsls.dev. If you put your handle there you’ll see the physical server it resolves to at the top.

Presumably you signed up from Bluesky so yes, Bluesky is hosting your repo by default. You can move it somewhere else with no disruption. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u for how to do this from CLI and https://pdsmoover.com/info.html for something less technical.

When it receives a post, it creates a row in the Post table. When it receives a comment, it creates a row in the Comment table, which has a column pointing to the Post it's replying to. Then, getting all comments under a post is easy SQL.

About your second question: yes, you're correct. What handle you use and where your data is hosted are completely separate matters.

Also at:// URIs are of the form at://DID/..., and your human readable handle is bound to your DID through DNS TXT records _atproto.roshangeorge.dev, but applications all know to render that as just roshangeorge.dev. That DID points to a document that specifies where your server lives, so the HTTPS/WSS routes can live wherever you want them to.

Also likes/replies/etc on your posts go in their authors repos not yours, your intuition is correct there.