How it works

dids.lol is a few small ideas stacked in one direction. Here they are in order, without the jargon.

Records and blobs

Your AT Protocol account has a repository, and you can write records into it. A site is one record. It says what the site serves: either a manifest — a map from each path to the file served there — or a reference to a published tile plus the parameters that tile declares. The files themselves are blobs, uploaded to your own server and named in the record by content hash.

This is the whole model of ownership. The record is in your repository, signed by your identity. If you move to another server, the record moves with you. If you delete it, the site stops. Nothing about it depends on dids.lol keeping an account for you, because there is no account to keep.

The firehose

Every public repository change is announced on a network-wide stream. dids.lol watches that stream for the two collections it cares about — site records and tile records — and reacts to what it sees. You do not tell dids.lol you published; it finds out, usually within a second or two.

If the stream stops, sites already published keep serving. Nothing on the request path touches the firehose, a personal data server, or an identity lookup.

Snapshots

When a record arrives, dids.lol validates it, fetches every blob it names, verifies each blob’s bytes against its content hash, and writes them into durable storage. Then it builds a snapshot: a frozen table from every path the site serves to exactly one stored blob. Going live is a pointer swap to that snapshot, so a publish is atomic — visitors see the old site or the new one, never a half-updated mixture.

The origin, and what it never does

The server that answers your visitors does three things: match the incoming host to a snapshot, match the path to an entry, and stream the stored bytes back. It runs no code you supplied. There is no server-side rendering, no template, no dynamic route, no database on the hot path. That is a deliberate limit, and it buys the property that a given path at a given revision always resolves to exactly the same bytes.

The response headers are dids.lol’s, not yours. A fixed Content-Security-Policy applies to every site, and no field in your record can influence it. The one header you shape is the content type of a file.

Tiles, and binding by CID

A tile is a reusable bundle of static files with a declared list of parameters — a theme, a landing page, a link-in-bio layout. Anyone can publish one, and anyone can use one. When you bind a tile to your domain, your record pins that tile’s exact version by content hash.

That pinning is the important part. A tile author who publishes a new version changes nothing about your live site. You are shown that an update exists; upgrading is an edit to your own record, which you make when you have looked at what changed. A tile author cannot reach into your site, and cannot take it away either: dids.lol keeps the bytes of the version you pinned, so deleting the tile from the directory leaves your site serving.

Parameters, bound at publish time

A tile declares typed parameters — text, numbers, booleans, files, lists, and references to other records. You fill them in when you publish, and they are frozen into your record. They cannot vary by visitor, because nothing runs at request time. That is the price of the guarantee above, and it is what makes the elaborate sandboxing other systems need unnecessary here: your site is on your own domain, isolated by the browser’s own origin rules.

Validate before you write

Publishing is two steps in a fixed order. First you ask dids.lol to validate the record you are about to write. It checks the manifest, the tile you are binding, the parameters, and the redirects; it answers with the exact record to write and the address it will have; and, if you are allowed to publish it, it starts fetching your blobs straight away. Then you write that record, unchanged, to your repository.

Doing it in that order means the errors reach you before anything is committed, and the waiting happens before the publish rather than after it. Write a record dids.lol has not seen and nothing breaks — it simply takes the ordinary, slower path.

The fixed policy on your site

Every served site gets the same Content-Security-Policy, and it forbids third-party scripts. A tile cannot phone home, load an analytics bundle, or pull a font from someone else’s CDN. Sites here are static files served from your own origin, and that is the whole of what they can be.

What is kept, and what is never seen

dids.lol keeps your bytes, durably, because a personal data server is not obliged to retain a blob forever and a website that disappears is not a website. It keeps the index it needs to serve you: your domains, your records’ addresses, the snapshots.

It does not see your visitors. The origin sets no cookies, runs no analytics, and stores nothing that identifies whoever loaded your page. The management application is on a different hostname from your sites, so its session cookie can never reach them.

Where to go next

The documentation covers each of these as a procedure: getting a domain verified, writing the record, publishing a tile, and the rules the origin enforces. If you would rather read the schemas, they are published as lexicons.