AT Protocol: A Technical Introduction
/2026-04/session/2-main/
Speaker: Daniel Holmgren (@dholms.at)
Participants who chose to record their names here:
- Johannes Ernst (@j12t@j12t.social, @j12t.org)
- Jeremiah Lee (@Jeremiah@alpaca.gold)
- Cagan Mert Islek (@cagan@cmislek.me)
- Jayne Samuel-Walker (@tcmuffin@toot.wales)
- Anca Mosoiu (@anca@mastodon.xyz)
Website: https://atproto.com/guides/understanding-atproto
Notes from presentation
-
W3C DIDs for identity
-
JSON or CBOR https://cbor.io/
-
Everything (post, interaction) is a record that has an at-uri
- Chat discussion: Your blocklist is public. https://atproto.com/blog/block-implementation
-
Repositories give positive proofs of both deletion & completeness/coherency. “If your current copy of this hash, then you have the current copy of their data.” by using a Merkle search tree.
-
Personal Data Server (PDS) hosts user’s account and repository. Self-hostable or use a provider. Fairly easy to migrate between PDSes.
-
Chat discussion:
- Sounds like a Solid POD
- Same dream, better implementation (AT Proto’s).
-
-
Relays: web socket of all changes coming from the PDSes
-
Lexicons: Similar to JSON Schema, but with a few specific needs unique to the use case
-
Chat discussion: “What if JSON-LD were usable?”
-
Specifically, open union for sub-lexicons. For example, posts might include images, videos, link embed cards.
-
Published as Records, identified by reverse domain name, anyone can publish and use a published lexicon. Can evolve and there is a recommended practice for versioning.
-
-
OAuth 2.1 + client id meta data docs: answers the question of: How do clients register with authorization servers when there are many authorization servers and many clients?
- Chat discussion: I wish for more adoption of GNAP RFC 9635, as OAuth 2’s successor. https://www.rfc-editor.org/rfc/rfc9635
-
Moderation: PDSes decide who they want to host. Applications decide what they want to crawl/index/serve. Labels annotate data in the network. Labels are ingested by apps and can affect display of content.
-
AT Protocol and Activity Pub are bridged elegantly with Bridgy Fed https://fed.brid.gy/
-
AT Protocol now has an IETF working group, specifically working on data model, repositories, PLC as a DID method (controversial because it’s centralized, but now Swiss association taking over, only 1 person of 5 people on board is from Bluesky)
-
Recent talk on PLC governance “Bringing Self Sovereign Identities to the Masses via ATproto - ATmosphereConf 2026” https://www.youtube.com/watch?v=ro2bSKmUKdI
-
ATMosphere talk by Daniel: “Defence against my boss being evil” talk: https://www.youtube.com/watch?v=9z0z-Qu66yM
Q&A
- Q: Bluesky started this as a Bluesky thing. How do you see Bluesky working with the community?
- How does innovation happen? Consensus seems to only get codified by Bluesky.
- Daniel: Bluesky is working with several other implementations and trying to build consensus. Many things don’t need the overhead of an IETF process.
- How is privacy preserved with deleted content?
- Daniel: Working on a permission data protocol so not everyone can crawl and get blasted out to the world. Right now everything is public, everything gets broadcast. Think of blocking as an anti-pattern in the same way the open web wants to not block certain browsers or data. Permissioned data is a separate protocol to put boundaries on your data.
- Where is the human readable identifer location? Can the identifier be represented in non-Latin charactersets?
- Daniel: The handle that is bi-directionally linked URL. You can do whatever you can do with a URL. Limitation is punycode and clients can make decision on how that’s displayed.
- Are you aware of people using such handles? Would it be reasonable for me to read the firehose to look for them?
- Daniel: Bluesky doesn’t translate punycode to humanreadable, he thinks.
- Is there any schema validation on the data on a PDS or is that the responsibility of the app reading the data?
- Daniel: PDS right now enforces a
$typeand the type is the same as the collection, but other implementations might not enforce it. It’s a permissionless network, so people can jam whatever they want into a record. The PDS should try to prevent garbage data. Bluesky’s does. Looking at cached lexicon so that PDS validates on write to help prevent an app from distributing bad data. - Threat models: Bluesky shutting down apps? What if Bluesky shuts down access at PDS to keep apps from accessing it?
- Daniel: Align incentive model so that it hurts the business model if the data is not open. If we cut off access to open data, we cut out access to features that differentiate the platform for many people (choose your own moderation, custom feeds, etc).
- How does the expensive AppView not create a centralization problem?
- Daniel: Check out the last talk (linked above). Encouraged to be a large provider, but also encouraged to be collaborative to have a larger network. Bluesky is more valuable in a wider network of applications. Company is ideologically aligned on this.
- Less concerned about shutting down or going evil. The big guy has side effects that have
- led to things on the web we didn’t really want. It seems dangerous for Bluesky being the
- biggest one.
- Daniel: “Bluesky will enshittify at some point”. There is a difference betweeen AppViews enshittifying SMTP. The PDS data is signed, can be rebroadcast, it’s inexpensive to access (compared to the web like a search engine). Shares the same concerns, but feels the threat model is different than Google search.