Skip to content
standard.mode.place

Colophon

The facts of how place.mode.standard.* is built, hosted, and identified. Not needed to use the standard — this is for anyone auditing, forking, or building on it.

Identity

Section titled “Identity”

The standard is authored by a single AT Protocol identity, separate from any personal account:
Handle mode.place
DID did:plc:rvraq37xlwydvov7laldai6a
PDS tngl.sh (Tangled)
Lexicon authority DNS TXT _lexicon.standard.mode.place → the DID above

The lexicon schemas are published to this account’s PDS as com.atproto.lexicon.schema records; the DNS TXT record establishes that standard.mode.place is their authority. The same DID doubles as the project’s Bluesky and Tangled presence.

Source & hosting

Section titled “Source & hosting”

Two repositories, both on Tangled (the AT-Protocol-native forge), both MIT-licensed:

  • lexicons — the schema source, authored in TypeScript with prototypey and compiled to JSON (bun run lexicon:emit). Uses Bun.
  • standard.mode.place — this documentation site: Astro + Starlight, deployed to Netlify at standard.mode.place.

There is intentionally no npm package — no resolver, CSS emitter, client library, or framework plugin. Consumers use @atproto/api directly against the published schemas — or generate their own typed client from the lexicon JSON with @atproto/lex-cli (the lexicons repo’s lexicon:gen script runs exactly that as a round-trip check); the reference code in the guides (Publish a theme, Render themes in your app) is illustrative, not a dependency. Third-party tooling is a community contribution, not part of the standard.

Lineage: standard.site

Section titled “Lineage: standard.site”

The project’s structure is modeled 1:1 on standard.site — the same shape of a personal standard on AT Protocol: a lexicons repo and a docs site on Tangled, a project DID with DNS handle verification, a .well-known verification endpoint, and a Bluesky presence. The substance is what differs: standard.site’s theme lexicon carries four flat color fields (a palette); this standard carries the full intent system. The two are designed to interoperate — a site.standard.publication could reference a place.mode.standard.theme URI instead of its inline basic theme.

AT Protocol features leveraged

Section titled “AT Protocol features leveraged”

The standard is deliberately thin, leaning on capabilities the protocol already provides:

  • Blob storage for fonts. A fontDescriptor can carry a file blob (a font uploaded to the author’s PDS) instead of an external src URL — so a theme is self-contained and its fonts travel with a PDS migration, with no CDN dependency to rot. → Schema › fontDescriptor
  • Firehose & collection enumeration for discovery. An indexer watching com.atproto.sync.subscribeRepos, or querying listReposByCollection for place.mode.standard.theme, can build a directory or gallery of published looks — with no custom infrastructure the standard has to run.
  • OAuth for viewer resolution. An app learns who the viewer is (their DID) via AT Protocol OAuth, then fetches their theme from their PDS. No app-password exchange, no custom auth. → Render themes in your app
  • Additive, backwards-compatible growth. Records can’t be tightened once they exist on the network, so the schema grows only by optional additions; a breaking change to the core would require a new themeV2 NSID. This is why the core is frozen and new intents/aspects arrive as optional fields.

Verification

Section titled “Verification”

A domain proves it owns a set of theme records by serving its profile AT-URI at /.well-known/place.mode.standard.profile; a personal look needs no verification (its DID and PDS authenticate it). The full mechanism is on the Verification page.