did.bot76826e95
2. Bootstrapping
Explaining the `did.bot` PDS lifecycle
Wherever possible, `did.bot` uses atproto for credentials. This has some unexpected architectural consequences: a bit like 'mTLS over atproto'.
When a `did.bot` PDS comes online, it bootstraps its own DNS, TLS, and `did:web` credentials. Then it enters an 'UNCLAIMED' state and waits for its designated operator.
`didbot operate <hostname>` claims it. The command signs in to the operator's *own* PDS in a browser and writes a `bot.did.operator` record there, keyed by the server's hostname. The `did.bot` PDS never sees that sign-in: it reads the record with no credential, on a timer.
If the operator deletes that record, or their own PDS stops answering for it, the `did.bot` PDS pauses — no new accounts, and no token works — once a grace window has passed with the record unread. Writing the record again releases the pause at the next poll. The window is there because a server cannot tell a revocation from an outage at the far end.