Skip to content
standard.mode.place

Verification

Most themes need no verification at all. A person’s theme lives on their own account, and their DID and PDS already authenticate it — a consumer just fetches it by their DID. There’s nothing to prove.

Verification matters in one case: when a domain — an app, a website, a brand — wants to claim “this theme is ours.” Without a proof, any account could publish a theme and assert it speaks for example.com. The mechanism below ties a domain to the records it vouches for.

The .well-known endpoint — the proof

Section titled “The .well-known endpoint — the proof”

Serve a file at https://<your-domain>/.well-known/place.mode.standard.profile whose body is the AT-URI of your profile record:

GET https://example.com/.well-known/place.mode.standard.profile


at://did:plc:abc123/place.mode.standard.profile/self

Because only the domain’s owner can place a file there, this is the domain endorsing that record. A consumer verifies in two steps:

  1. Fetch the endpoint → read the profile AT-URI → its DID is the claimed authority.
  2. Confirm the DID belongs to the domain — the DID’s handle resolves to example.com (ordinary AT Protocol handle verification).

Together they’re bidirectional: the domain points at the account, and the account’s handle is the domain. Once the account is verified, its themes are the records in its place.mode.standard.theme collection — the app’s baseline being the one saved at record key default.

Serving it from a static site

Section titled “Serving it from a static site”

The file has no extension and its body is just the AT-URI. On a static host (Astro, Netlify, …) drop it in your public/ directory so it’s served verbatim:

public/.well-known/place.mode.standard.profile

A real example — mode.place

Section titled “A real example — mode.place”

This standard’s own site is the reference deployment. mode.place serves the file like this:

GET https://mode.place/.well-known/place.mode.standard.profile


at://did:plc:rvraq37xlwydvov7laldai6a/place.mode.standard.profile/self

Walk the two checks against it:

  1. Fetch the endpoint → the body is a profile AT-URI whose account is did:plc:rvraq37xlwydvov7laldai6a. That DID is the claimed authority.
  2. Confirm the DID belongs to the domain → resolve that DID’s handle; it is mode.place. The account and the domain name each other, so the link holds.

With the account verified, mode.place’s look is the theme in its place.mode.standard.theme collection saved at record key default. Notice there was nothing to compute: every value is fixed by facts you already have — the DID, the collection place.mode.standard.profile, and the profile’s record key, which is always self. This is the file.

The <link> discovery hint — not verification

Section titled “The <link> discovery hint — not verification”

On a page that has a theme applied, add a <link> in the <head> so tools and indexers can discover which theme is in use:

<link rel="place.mode.standard.theme" href="at://did:plc:abc123/place.mode.standard.theme/rkey">

This is a hint for discovery only — it says “this theme is active here.” It is not a trust signal: verification always comes from the .well-known endpoint above, never from a <link> a page can claim freely.

Why personal themes are exempt

Section titled “Why personal themes are exempt”

There’s no domain to associate. A person’s theme is reached through their DID, and the DID + PDS authenticate it end to end. Verification exists solely to bind a domain to records — where there’s no domain claim, there’s nothing to verify.

Next steps

Section titled “Next steps”