The site record

A site is one lol.dids.sites.site record in your repository. Its record key is the hostname, lowercase, in IDNA A-label form — so the record for example.com has the key example.com.

Source

Every site record has a source, and it is one of two things.

An inline manifest carries the files directly: a map from each path the site serves to the blob served there, plus the response fields that go with it. Paths start with /, contain no .. and no backslashes, and collapse repeated slashes. Every manifest needs a / entry — that is the page served at the root.

A strong reference names a published tile and pins its exact version by content hash. When you bind a tile you also supply parameters, an object satisfying what the tile declares. Parameters are permitted only with a tile; an inline manifest takes none.

Redirects

redirects is a list of rules evaluated before the manifest is consulted. Each has a from, a to, and a status.

The rule that catches people: to must be a literal key that exists in the effective manifest. Not a pattern, not an external URL, not a path that merely looks right. The app offers a select over the manifest's keys rather than a text field for exactly this reason. A redirect pointing at a key that is not there makes the record invalid, and validation will tell you so before you write it.

notFound

notFound names one resource to serve for requests that match nothing. It carries a status, and the choice matters:

• 404 is the ordinary case: a real not-found page.
• 200 makes it a single-page-application fallback. Every unmatched path serves that document with a success status, so a client-side router can take over. Use it if — and only if — your site is a single-page application, because it means a genuinely missing page no longer reports as missing to anything that checks.

wellKnown

By default dids.lol answers two well-known paths on your behalf. wellKnown lets you turn either off.

atproto serves /.well-known/atproto-did. Read this before you disable it, and before you enable it on a domain you use as a handle. That path is how the AT Protocol resolves a handle to a DID. If your domain is also your handle, the answer served here must be the DID your handle actually points at, or handle resolution breaks. If you have any doubt, and your domain is your handle, serve that file yourself from your manifest.

rasl serves the resource-map endpoint that lets a tool discover the site's structure and the parameters it was published with.

Publishing

Write the record with putRecord under the hostname key, in the repository the domain is registered to. Validate first — see Validate before you write — and submit exactly the record validation returned. Editing it after validation is not an error, but it changes the record's hash, which means the work the service already did on your behalf no longer applies and the publish takes the slow path.

Deleting

Deleting the record deactivates the site on the next firehose event. The registration, the DNS, and the certificate survive. Publish again and the site comes back without re-verification.