4 ms·
That was very well written. I have to admit that because AT Protocol was Bluesky's I thought it was some corpo version of ActivityPub, but based on this post it
by arjie 1y ago
That was very well written. I have to admit that because AT Protocol was Bluesky's I thought it was some corpo version of ActivityPub, but based on this post it makes a lot of sense. The data is in a 'repository' of my choice. I think I like that very much and it aligns with the kind of general principle I have where it's better to apply filtering etc. on the read side rather than on the write side so that I can publish all sorts of things that I want into my repo and others can then read etc. that stuff.
The arrows do seem to imply that commenting on my posts goes into my repo, but I'm sure that's just an imprecision trying to express an idea. The whole thing seems very cool and decentralized.
When I went to see what it takes to run a separate PDS on AT, though, I see that it's all nice and packaged up and has certain assumptions:
1. It takes care of SSL etc.
2. It will stand up HTTPS/WSS servers to handle a bunch of RPC
So in practice, you don't get https://roshangeorge.dev https://roshangeorge.dev and at://roshangeorge.dev because for the latter you kind of need https://roshangeorge.dev/xrpc https://roshangeorge.dev/xrpc and wss://roshangeorge.dev
Therefore, you probably end up with https://roshangeorge.dev https://roshangeorge.dev and at://at.roshangeorge.dev and then you can run https://at.roshangeorge.dev https://at.roshangeorge.dev and wss://at.roshangeorge.dev
All minor stuff and doesn't take away from the main point, but it was a thing.
- whyrusleeping 1y agoThe default pds packaging takes care of SSL, but thats not a requirement, just something we try to make easy for users. 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.
- extraduder_ire 1y agoYou can authenticate a handle via a file in ./well-known/ at the domain too, which is how bluesky does it for their default handles.
- deleted 1y ago[deleted]
- danabramov 1y ago>The arrows do seem to imply that commenting on my posts goes into my repo, but I'm sure that's just an imprecision trying to express an idea. The whole thing seems very cool and decentralized. 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.
- vermilingua 1y agoThis makes sense but doesn’t this imply that displaying comments under a post is a very expensive operation? 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?
- nasso_dev 1y agoDisplaying comments is cheap because the AppView (the "cache" layer that consumes the aggregated feed of records from the relay) can maintain a relational database of the social web/graph. 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.
- 1y ago
- KolibriFly 1y agoBeing able to dump everything into your own repo and let others filter it however they want - that's a powerful shift