notes the thinking, as it moved

The Future Times wanted articles with a claim at the top and readers arguing against it on the left and for it on the right. Every response would be signed from the first one. We asked how little the site itself could hold: a sign-in it checks fresh on each visit and no table of users, or responses written to a public ledger that the site never stores.

Why should a site bundle its articles with its own votes, comments and accounts? We concluded that a separate service could carry all of that using parts that already exist. Ordinary sign-up creates a keypair, each vote or comment is a signed record about a URL, and one public address returns those records for a static site to show.

Anselm described the problem as being fed pollutants with no scoring at all, "like the food and drug administration, or a river". PageRank once scored sources, and platforms moved to scoring single items or nothing. So we decided to score emitters: the people and outlets who publish, rated by what they have said and who stands behind them.

Identity is not bound to a soul. Someone who behaves badly can drop an identity and begin earning trust on a new one. That only works if newcomers start with nothing and trust grows slowly, so a fresh name gains nothing. We took the rule from Friedman and Resnick's paper on the cost of cheap pseudonyms, which at that point we had only seen cited.

Attestations are signed public records, so anything counted from them is public as well. A site that adopts attest gets votes, comments and reach for its pages without running any of it, and its competitors can see the same numbers. We chose public standing over private metrics. Private dashboards are some other service's job.

We read and tabulated 48 prior efforts. None combined an ordinary sign-up, signed statements about any web address, a read endpoint a static site can use, and trust that flows from a starting point with limits. The nearest five each lacked at least two of those. We set aside the staff-run outlet raters because they are proprietary and score along a left-right axis.

The first plan scored everyone from one founder's key, and the catalogue had already flagged a single seed as something to avoid. So every score now names its starting point, chosen by whoever asks: trusted by people you trust, never "trustworthy" in general. Cheng and Friedman showed in 2005 that no single global score can resist fake accounts, while a score computed from a chosen source can.

We decided that negative statements do not flow through the graph the way vouches do. A challenge is shown beside a score, weighted by the trust in whoever made it, but it lowers nobody's standing by spreading. What lowers an emitter's standing is their own record: claims that turned out false, and vouches for people who turned out badly.

Anselm: "I don't feel like one needs to bind a key to a person - a key itself builds rep." So an emitter is a key, and "person", "site" or "byline" are things its holder may choose to prove about it. Signed statements became the shared foundation. Scoring became one client reading them among many, which settled who owns the score before the question came up.

We found a 1999 working-paper version of Friedman and Resnick and read it in full. It supports starting newcomers at zero. Its authors, though, recommend committing to one pseudonym per community, the opposite of a burnable identity. We kept the right to walk away and accepted the social cost the paper describes. We found no one who argues for free identity change as a goal.

The systems that fetch and cite sources for AI models need to weigh those sources now. So reads should accept a starting point and many addresses at once, as well as serving one page widget. A browser plugin that looks up every page you visit would collect your browsing history. Reads therefore have to stay private even though the statements are public.

We first advised against using attest as the sign-in for other projects, so it would not become a single point of failure. Anselm's answer changed that. His projects are public, and what each one needs is people signing, vouching, upvoting and commenting, so one shared identity is right. We then designed for an outage: identities live in a public directory, records are signed by the person and can be checked by anyone, and only new sign-ins wait.

The first build used a passkey on the person's own device in place of a key the server holds. A passkey asks for a fingerprint or face every time it signs, which would mean one prompt per upvote. So at sign-in it signs one 30-day permission for a key that stays in that site's page, and that key signs from then on. We built it as a standalone service in one day, in record shapes compatible with AT Protocol so it could move later.

We bought the domain attest.monster the same night, and the launch essay went out on Substack as "Foundations of Trust: Attest.monster". Two readers' replies to it changed the architecture the next day.

Readers pointed us at badge.blue, Hypercerts and Tangled. On AT Protocol, Bluesky's network, those projects already have most of what we had built or planned: identity in a public directory, signed repositories copied across the network, and a shared vocabulary, all better replicated than ours. We kept what was missing there: statements about web addresses and files, the person's own signature, and scores from a chosen starting point. Records moved into AT Protocol repositories and attest became the index, the scorer and the widget. It cost one day of building and a launch essay that described the old design.

On AT Protocol the hosting server signs a person's repository, and the person usually holds no key of their own. That worried Anselm. Records can carry an extra signature, so every attest record also carries one from the key the person's passkey authorised, which anyone can check with that key alone. He agreed to fold on that condition.

We had planned a button to turn everyone you follow into vouches. A reader showed that Tangled keeps follows and vouches separate, and that another builder reused Tangled's vouches as a ready-made trust graph. We dropped the button. Follows and vouches from elsewhere are read in as different kinds of edge, and a scorer can weigh a vouch above a follow.

With the fold decided, we started a public revision log, newest first, and wrote the pivot as its first entry. Pages that the decision made wrong would be corrected, and each correction logged.

The FAQ opens with the question readers ask most. Our answer is the things no one else offered: statements about web addresses, scholarly papers by their DOIs, and files, plus the person's own signature and scores relative to a chosen starting point. If Bluesky, Tangled or Hypercerts add those, attest has no reason to stay separate, and we would join them.

If the person's key signs each request, the server needs no session and no cookie. That was the design already, and we checked that nothing sets a cookie. The browser keeps a session note and a key that cannot be copied out of it. Signing in with Bluesky later had to meet the same rule.

Basic vouching overlaps with social bookmarking, in the line of Delicious and Pinboard. A bookmark files a page under your tags as a signed record in your own repository. Filing is not endorsing, so an upvote stays a separate, deliberate act.

We read Kaliya Young, Kevin Triplett and Drummond Reed's work on decentralized trust graphs, and set out principles in reply. Trust passes along, weaker at each step, and depends on context. Mutual vouches count for more. A community can be a member of the graph, and a person is a community of agents acting for their will. There is no proof of personhood by biometrics. We had wrongly implied that attest's scoring would stop at direct connections, and the roadmap was reordered around these principles.

OpenHaven catalogues decentralized tools and rates each for how easily a company, funder or government could capture it. It gives AT Protocol 3 out of 5. Reading it added three items to the roadmap: tags on a vouch, so trust can be contextual; a recovery key the person holds that outranks the service's own; and a public rating of attest's own capture risk.

Kaliya Young's verdict on the field, as Anselm relayed it, was "the plumbing exists but it is ugly", and we worried attest was incomprehensible to a newcomer. The home page now tells the story first and moves the technical material one door away. We ruled out photoreal generated people on a site about trust and used painted illustration, credited as generated.

We wrote down the motive under the project. Power drifts to centers without anyone deciding it should, centers attract people who should not hold them, and the crises that matter most are ecological. The design rules that follow: do not hand off trust, make power legible, fix rules before power arrives, and assume the founders will not stay good.

Joe Germuska asked whether attest worked only with accounts created on its own server. It did. Now anyone with a Bluesky or other AT Protocol account can sign in with their handle. Their records go into their own repository, and attest asks permission to write only its own record types, not their posts or follows.

Sign-in from another site opened a popup, and on iPhones and in apps saved to the home screen that often fails or loses its way back. Sign-in now falls back to sending the person to attest and back. Matchmaker switched its own sign-in to attest the same day, the first other project to do so.

Until this date, the public log named the site behind every sign-in made through attest. People "probably don't intend to signal to other people about where they sign in." Sign-ins now name the site only as a salted hash, published only once something signed under it is published, and the old entries that named other sites were deleted.

We took a second look at Trustgraphs, Jake Hartnell's project. attest captures trust: sign-in without a crypto wallet, and signed records in people's own repositories. Trustgraphs computes trust and proves the result, but asks for a wallet. Its design gave us ideas to adopt, starting with confirmation doubling a vouch's weight. Another lets trust flow through a page to the person proven to run its site, which squares scoring emitters with scoring pages.

On 2026-09-28 the roadmap gave agents accounts of their own. After reading WorkOS's auth.md, we reversed that. An agent has its own key, and the person approves it with their passkey under limits anyone can read: which kinds of record, how many a day, for how long. What it writes counts as the person's. Agents earn no trust of their own.

We considered attest acting as an OpenID Connect sign-in provider, so tools that will never load our widget could still let people in with their attest passkey. We set aside accepting Google or Microsoft sign-ins, because that puts a large company back in front of the person. Later that day we read OpenVTC, an LF Decentralized Trust lab. Its browser plugin puts a passkey into the person's public identity record, which suggested publishing attest passkeys there too.