roadmap built, next, later, still reading

A living page. Dated reasoning behind each item is in the repository's devlog; what actually shipped is on changes.

Built

• Passkey sign-up and sign-in; a per-site device key delegated by the passkey; revoke a session; second passkey.
• An AT Protocol account per person on our own data server, did:plc, handle bound by DNS.
• Records in the person's repository: vote, comment, statement, vouch, claim, verification, in our monster.attest.* lexicons, each with the person's inline signature.
• An index that follows the repository stream and verifies every record it counts.
• Profiles, vouching, proof of control over a site, domain, GitHub or Bluesky account, per-site pages, a drop-in widget, a JavaScript package, plain public reads.

Next

• Link an existing Bluesky account and write records into its repository instead of ours.
• Read Tangled vouches and Bluesky follows in as two strengths of trust edge.
• Hide records of deleted or deactivated accounts from counts.
• An accuracy pass over every reader-facing page after the pivot.
• Publish the lexicons so AT Protocol tools can resolve them, and propose the URL-subject shape to the shared app.certified vocabulary.

Later

A subjective score on any post, relative to you

Ask for any URL, any post, any record: how is this regarded by the people I trust, and the people they trust? The answer is a small scored graph with you at the centre, computed by flow from your key through vouches with a capacity limit at each step, with the paths shown so you can see why. The same page viewed by two people gives two honest answers. This is the feature the rest of the project exists to make possible.

Voting

Many votes do not need secrecy: a club choosing a date, a neighbourhood ranking street repairs, a community endorsing a proposal. Those can be done now with public signed records, one per key, with trust weighting to discount accounts nobody vouches for. We want to support several flavours: yes or no, ranked, approval, quadratic.

Secret ballots are a separate and much richer problem, and we will not pretend otherwise. A good digital election needs privacy, so nobody can see or buy your vote, and also retroactive proof, so you can later confirm your own vote was cast as you intended and counted. Those pull against each other, and the known solutions involve zero-knowledge and verifiable-shuffle cryptography we have not built. It is worth tackling eventually. Paper voting is slow and expensive enough that we vote rarely and on large bundles of questions; cheap, trustworthy digital voting would let people vote more often on smaller things, and would scale. That is a later chapter, and it will get its own research note before any code.

Place-based attestations

"If you are at this place at this time, something happens": a reward, a check-in, a proof of attendance, a witness to an event. These are usually built on blockchains; Anselm has drafted an Ethereum proposal for location-bound contracts. Public attestations can do much of it without a chain: a key reports where it is, and the claims are scored for plausibility. The cheapest defence against spoofing is physics. A key cannot be in Vancouver at noon and Lisbon at five past, so impossible jumps are discounted by a maximum travel speed, or by keeping a "ghost" that must walk the route. The body flies but the soul walks. Witnesses nearby vouching for each other add more.

Claims like these invite adversarial checks, and that is healthy. If you say you were somewhere and were not, anyone with an interest, a competitor or a skeptic, can sign a statement that you were not, with whatever evidence they have. attest does not settle who is right; it records both statements, signed and public. Weighing them is a layer on top, and a hard one, because the challenger may be lying or mistaken too. Being caught in a false claim can cost standing in any score built later, which is the point of making claims in public. The service's job is only the attestations. A great deal of machinery can be built on them.

And the rest

• Authorship claims on content hashes, and a "check this file" page.
• Scores published as an AT Protocol labeler, so any subscribing client sees a root's view.
• Claims with resolution dates and a track record per key (Brier score).
• Institutions vouching for bylines, with the byline acknowledging it; pseudonymous authors vouched for by an institution.
• A browser extension that scores what you read, from your own root, without telling us what you read.
• An endpoint for AI agents that need to weight sources.
• Key export; an npm release of the client; the first sites to use it.

Still reading

Projects readers have pointed us at, or that we found, not yet studied closely enough to say how we relate:

• NorthStar Social (nstar.social): announced as a decentralized, local-first social network, beta in spring 2026. Its pages do not yet say which protocol or how it handles trust.
• socialweb.computer: how its vouch and denounce policies are expressed, and whether it can read our records.
• Tangled: how a vouch names its subject, before we mirror ours to it.
• The app.certified lexicons: who stewards them, and how to propose an addition.
• Community Notes's bridging method, for supports and challenges once volume exists.

Open questions:

• How strong should a follow be relative to a vouch, and how fast should an edge age?
• Who may resolve a claim, and how is a resolver trusted?
• Can reads stay private without a mirror on every device?
• Whether a passkey could ever control an identity directly. AT Protocol rotation keys need raw signatures, which passkeys do not produce today.

Know a project we should read? Tell us; the ways in say how.