In short, at:// protocol lets you build apps that can deeply interop and query/embed each other's information, allow the user to have a shared user identity between apps, and allow the user to self-host their content (or move their hosting) without impacting the apps. It does this by giving bits of JSON permanent URIs that aren't tied to a specific user handle or hosting server, but instead are rooted in identity. The article describes how that works (and what an "identity" is) in technical detail.
Here's a concrete example: a blogging app (https://leaflet.pub) automatically "sees" mentions of a Leaflet post on a different microblogging app (https://bsky.app) and can display them: https://bsky.app/profile/o.simardcasanova.net/post/3luujudlr.... This is not done by hitting an API; it's just that both apps aggregate the same information from the open network into their respective databases.
I'm pretty new to the at:// protocol, and I like what I'm reading, thanks for the write-up.
To your "This is not done by hitting an API" point; if I understand correctly, I'd argue that the _endpoints_ that you detail in your post _are_ the API. The whole point is that there's no single _central_ API, but each server that wants to be part of the network participates by hosting an API that meets the standard outlined in the protocol.
In a way it's semantics, but I'd be interested in yours thoughts on that. To either correct or confirm my understanding.
No, that’s really not the case. The Leaflet app “knows” about Bluesky posts by reading Leaflet's own database on the Leaflet servers. It doesn’t need Bluesky’s cooperation to use “Bluesky’s” public data. It doesn’t need to hit Bluesky’s API for that. And if Bluesky shut down its API completely, it would still work.
This is because a stream of all public data from all apps is being subscribed to by all apps. Whatever you care about, you save into your app’s database. Each app’s database serves as an app-specific index of the data on the network. If you want to query Bluesky posts later, you just save them as they stream in.
So every app can piggyback on data created by other apps. And anyone can run a "retransmitter" (aka a relay) like this. It's an application-agnostic aggregator over websockets. The one operated by Bluesky-the-company is most popular one, but https://atproto.africa/ is another one, and you can get one running yourself for about $30/mo; the implementations are open source.)
I explain this in more detail in https://overreacted.io/open-social/, Ctrl+F to "to a stream that retransmits events from all known repositories on the network".
Thanks for the info, that does help me understand what's going on in the protocol.
I suppose I was thinking about the app responsible for getting the data into, say, Leaflet's local database in the first place. For that app, the data structures you describe are the APIs that it consumes, for the sole purpose of populating its own database.
That gets my cogs whirring about how good a use-case this would be for SQLite. I suppose it would be somewhat appropriate for a small, private, PDS? Although, if I understand correctly, I wouldn't need to worry about that anyway if I'm using some off-the shelf PDS software, e.g. https://atproto.com/guides/self-hosting
I'm not quite sure I'm following what you're saying.
Basically, there's two main roles in the system:
- A user's personal repository -- that's sort of like Git hosting, with a server that can serve a JSON record or a stream of commits. That's PDS. It's application-agnostic. Bluesky's open source implementation of PDS does in fact use sqlite (per each user :). Each user has exactly one repo that stores data of all apps.
- An app -- that's any arbitrary app backend. Could be literally anything. These write data to user's personal repo (for the stuff user creates). They can directly ask a particular user's repo for data (like explained in the article) or they can subscribe to the commit stream and mirror the data they care about in a local database. Then it can be queried and retrieved with no delays, and also can be aggregated (e.g. calculate count of likes for a given post, even though they "live" in different users' repos).
This is chicken and egg stuff. I don't get it and I've picked on the intro of the explainer. Why would I want "the JSON"?
Yes, I did skim the "read this" link.
It's not for me.