Samuel
@samuel.fm
atproto records are addressed with an AT URI, which has three parts: the host, the collection, and, the record key (shortened to rkey) at://mozzius.dev/app.bsky.feed.post/3l7z4whnkr224 host: where it is collection: what it is rkey: which one it is
9 11 139
Robin Berjon
One thing I've been tinker with is small webapp containers that can't touch the network, so that they're pretty safe and can therefore be given data. I'm guessing they could be used for this, registered to handle collections, since the client knows exactly what to give them.
1 3
David Buchanan
hm, I think you do realistically want them to have network access though, to "hydrate" a view. A bluesky post record on its own isn't very interesting without the replies and likes and quotes etc.
1
Robin Berjon
Sure, my point is you could restrict access to just what's needed (preventing exfiltration) while allowing for arbitrary rendering.
1
JP ✨
How is host determined? I get how you can have a self hosted PDS but how does an ATProto app know which server contains what data?
1 3
Archived fry69
Thank you. This was not mentioned in other discussions before (or I missed it). Also, this makes Bluesky currently a bit centralized, correct? All clients would need to get seeded with a different PLC directory if the current one goes away (or goes rogue), correct? A bit like the DNS root serves?
2 1
bryan newbold
it is currently centralized for *lookup* by default, though other folks can run PLC instances (as long as they keep up with all DIDs). the operator of the PLC directory can't do much with that centralization (they can't edit DIDs or DID docs)
4
Robert Lin
Just FYI: did:plc isn't the only game in town. Users can also configure did:web identifiers. Those will then not be in the PLC directory. (This is one way that ATProto is decentralized 🙂) If you want to find those did:web PDS serviceEndpoints, you'll need to follow this: bsky.app/profile/robe...
Robert Lin@robertl.in· 3 Nov 2024
TY, Tom! 🙏 For anyone in the future finding this, the web:did convention is to place your did details at `https://<YOUR-DOMAIN>/.well-known/did.json`. So, eg. joncaruana.com/.well-known/...
How to get the did details (including their PDS serviceEndpoint for someone with a did:web identifier.
2
Archived fry69
Not really a distributed store, more like caches in aggregators. Think of RSS. This thread explains it much better than I ever could -> bsky.app/profile/dana...
dan@danabra.mov· 3 Nov 2024
here’s a listing of your (public) data on atproto: atproto-browser.vercel.app/at/hbuchel.b... it’s currently hosted on a bluesky server (scroll down for serviceEndpoint — that says who does your hosting). but you can move this data to another server or self-host it. the server itself is open source
1
devin ivy 🐋
that "host" part is also sometimes called the uri's "authority." i think of atproto as moving authority from services (as on the web) to people, or identities. so i read that part more as "who" rather than "where." the at:// is kinda like... @.
1 2
Ian Preston
That address doesn't look self authenticating. Isn't that a core property of the protocol? Unless the rkey is a full hash and you've just truncated it in the example?
1
Ian Preston
My point is you can't share a link to a record safely, because, as it is not self authenticating, the server can return whatever it wants.
1 1
More replies on Bluesky