changes a public revision log

Newest first. Decisions and reversals are recorded here as they happen, including the ones that make earlier pages wrong; those pages get corrected, and the correction is logged too. The full working notes are the dated entries in devlog/ in the repository.

2026-09-24 · The index follows the firehose; handles resolve by DNS

The service no longer trusts only what it wrote. It subscribes to its data server's repository stream, verifies each record's inline signature against the repository it sits in, and indexes it; an unsigned record in one of our collections is ignored, and a deleted record is retracted. A record written into a repository by any other client now counts exactly as one written through our widget. That is the property the fold was for.

Handles bind to identities by DNS: each account gets a _atproto.<handle> TXT record with its DID, the AT Protocol way, so Bluesky's resolver already answers for attest.attest.monster. The wildcard certificate for handle hostnames is still not issued by the host's edge; with DNS binding it is no longer needed for resolution.

2026-09-24 · Records now live in repositories

The fold's first working step. Sign-up still makes a passkey; it now also creates a repository account on our AT Protocol data server, with a handle under attest.monster and a did:plc in the public directory. Upvotes, comments, statements, vouches and claims are written into that repository as records in our own lexicons (monster.attest.*), each carrying the person's inline signature from the device key their passkey delegated, in the shared app.certified.signature.defs#inline shape. The service indexes what it wrote; anyone can read the records back from the repository, or from a relay, without us. Retracting deletes the record. The service has a repository of its own for the verifications it signs. The log and the previous record format are gone; the test database was wiped. Every test passes against the live service, including a record verified from public data alone.

Not yet: the index still comes from what we wrote, not from the firehose; handles do not yet resolve over HTTPS on their own hostnames, pending a wildcard certificate; linking an existing Bluesky account is not built. The integrator page describes the new record; the technical page still describes the old log in places and will be corrected in the accuracy pass.

2026-09-24 · The pivot: attest becomes an application on AT Protocol

Two readers of the launch essay changed our architecture within a day of shipping it. One pointed at badge.blue, a specification for signing AT Protocol records, and at socialweb.computer, which reads a vouch graph to decide who may bid for compute, and made the argument that storing attestations as records on the protocol lets everyone borrow meaning from shared lexicons: Tangled's follows and vouches signal different levels of trust and another builder reused them without asking anyone. The other pointed at Hypercerts, which turned out to carry a whole shared vocabulary for attestation on AT Protocol, with badge.blue's signature proofs already in production.

We read them and concluded, honestly, that most of what we had built or planned already exists there and is better replicated than ours would be: identity with a public directory, signed repositories relayed by a firehose, a shared record vocabulary, and millions of accounts. What does not exist there is what we care most about: statements about URLs, DOIs and file hashes rather than about protocol records; a key the person holds; and trust scored from a root the asker chooses.

So the decision, taken the same night: keep the application and fold the fabric. Sign-up stays a passkey. Every record still carries the person's own inline signature from a device key the passkey delegated. But records now go into an AT Protocol repository, on a data server we host or on the person's own Bluesky account, in the shared record shapes where they fit and in one small lexicon of ours for URL and hash subjects. attest becomes the index, the scorer and the widget over those records. The first spike that night ran a data server on our host, created a real did:plc account, wrote a record in our own collection with an inline signature, and watched it appear on the firehose. The About and technical pages still describe the standalone design in places; they will be corrected page by page as the new one lands, and each correction will be logged here.

What this cost us: one day of building the standalone version, and a launch essay that describes it. What it would have cost not to pivot: a service nobody else's tools could read.

2026-09-23 · Custody, profiles, vouching, proofs, sites

Revoke any session from your own page. Add a second passkey, approved by an existing one; remove one with another's signature. Profiles at /@handle showing who vouched for a key and whom it vouches for. "I know this person" with the cost shown. Proof of control over a website, a domain, a GitHub user or a Bluesky handle, checked and signed by the service's own key. A page per domain with its most-attested pages. Reader feedback added an "Other work" section to About and a table of borrowed practices to the technical page.

2026-09-23 · attest.monster, mascot, essay

The domain, with the old host redirecting so passkeys have one origin. The test database was wiped in the move. The mascot, a creature holding a cat's cradle. The launch essay, Foundations of Trust, on Substack.

2026-09-23 · Pass 1

Passkey sign-up, per-site device keys by delegation, signed records (upvote, comment, vouch, statement, retract) about URLs, an append-only log, plain cacheable reads, a widget for static sites, and an end-to-end test that verifies a record from the log alone. Built in one day from a prior-art catalogue of 48 efforts read the day before. Source public under MIT the same evening, first at anselm/attest, then moved to orbitalfoundation/attest.

2026-09-22 · The catalogue

Forty-eight prior efforts read and tabulated before any code, with the conclusion that nothing combined ordinary sign-up with a held key, signed statements about arbitrary URLs, a read endpoint for static sites, and trust by bounded flow with burnable identity. That conclusion still stands; the pivot above is about where the records live, not about that gap.