27 JUL 2026

Publishing and resolution

How community.lexicon.* NSIDs resolve: DNS to DID to schema record. Plus how to verify the chain and pin an offline copy your SDK can trust.

Publishing and resolution


This guide is for developers who want to understand how community.lexicon.* schemas are published and resolved on the AT Protocol network, and how to verify or harden that resolution in their own libraries, applications, and services.

(Photo by NEOM on Unsplash)

How resolution works

AT Protocol lexicon resolution turns an NSID into a schema document in three steps. Taking community.lexicon.calendar.event as the example:

  1. DNS names the authority. The NSID's domain segments reverse into an authority domain (community.lexicon.calendarcalendar.lexicon.community), and a TXT record at _lexicon. that domain names the DID that publishes the schema:

    $ dig +short TXT _lexicon.calendar.lexicon.community
    "did=did:plc:mtr7qrqtcyseedx3jyr5o7db"
  2. The DID locates a repository. That DID (@lexicons.lexicon.community) resolves to a DID document naming its personal data server, like any AT Protocol identity.

  3. The repository holds the schema. The schema is a com.atproto.lexicon.schema record whose record key is the full NSID:

    at://did:plc:mtr7qrqtcyseedx3jyr5o7db/com.atproto.lexicon.schema/community.lexicon.calendar.event

What Lexicon Community publishes

The @lexicons.lexicon.community identity is a dedicated, lexicon-only repository: it holds exactly the published schema records and nothing else; it never posts and never will. Every _lexicon.<namespace> record under lexicon.community points at it. The human-editable source of truth remains the lexicons repository; records are published from it when changes merge.

Verifying resolution

Three independent ways to check any community.lexicon.* NSID:

  • DNS: dig +short TXT _lexicon.<namespace>.lexicon.community; expect did=did:plc:mtr7qrqtcyseedx3jyr5o7db.

  • Direct fetch: com.atproto.repo.getRecord against the identity's PDS with collection=com.atproto.lexicon.schema and rkey=<NSID>.

  • A resolver: tools like Lexicon Garden or goat lex resolve perform the full DNS→DID→record walk for you.

Offline verification and hardening

SDK and service developers who don't want a runtime dependency on live resolution can fetch the entire published schema set in one unauthenticated request: the repository exports as a CAR file (a content-addressed archive containing the repository's Merkle Search Tree):

GET https://eurosky.social/xrpc/com.atproto.sync.getRepo?did=did:plc:mtr7qrqtcyseedx3jyr5o7db

The CAR carries a signed commit over the tree, so an embedded copy is verifiable offline: import the CAR, verify the commit signature against the DID document's signing key, walk the MST, and extract the com.atproto.lexicon.schema records. Pin a copy in your test fixtures, regenerate types from it, or ship it with an application that must work without network access. Refresh it on your own schedule.

To make the verification chain complete, also download the PLC directory audit log for the identity:

GET https://plc.directory/did:plc:mtr7qrqtcyseedx3jyr5o7db/log/audit

The audit log is the identity's full operation chain, and it is self-verifying: each operation is hash-linked to the previous one and signed by a rotation key the earlier operations authorized, so you can validate the chain offline and derive the DID document, including the signing key, without trusting a live directory response. Pin the audit log alongside the CAR and you have a fully self-contained bundle: the log proves the key, and the key proves the CAR.

Questions

If resolution misbehaves or the docs here don't match what you observe, say so on the forum: a resolution bug is exactly the kind of report the community wants fast.

atprotocollexiconslexicon-community

Enjoyed this article?

Join our free newsletter and never miss an update.


Related Articles