Your website lives in your repository.

dids.lol turns an AT Protocol record into a live website on a domain you control. You write the record to your own PDS, point your domain here, and the site is live — no account, no password, no upload step beyond the record and its blobs.

How it works

Four steps, and you own the first and the third.

  1. Write a record

    A lol.dids.sites.site record in your own repository names what the site serves: files you uploaded, or a published tile you bind by reference.

  2. bard indexes it

    The record reaches the firehose, bard validates it, fetches every blob, verifies each one against its CID, and materializes a snapshot.

  3. Point your domain

    Two DNS records: a TXT that proves the domain is yours, and an ALIAS or CNAME to go.dids.lol. A certificate is issued on the first request.

  4. Your site is live

    Requests resolve to exactly one blob, byte-verified before it is served. Updates reach the edge within seconds of the record landing.

Two things you can publish

A site

A domain and the bytes it serves. Carry the file manifest inline, or bind a tile and supply the parameters it declares. Redirects, a not-found page, and the well-known responses are yours to set.

The site record →

A tile

A reusable, parameterized bundle anyone may bind to their own domain. A binding pins an exact version by CID, so publishing a new tile changes no site that already uses the old one — the site owner upgrades when they choose.

Tiles →

What you keep

The record is yours and lives in your repository; move your identity and the site moves with it. bard keeps a durable copy of your bytes so the site keeps serving, and never executes anything at request time — no server-side rendering, no dynamic routing, no request-time code. The origin sets no cookies and learns nothing about your visitors.

Everything the interface application at app.dids.lol can do, any tool can do over dids.lol/xrpc with the same lexicons. It is a convenience, not a gatekeeper.