A claim about you is not true until you sign it
Verification over a directory/1 record: a countersignature from the party a claim is about, an audit of what a website can prove, and a badge that carries a date. Ed25519 over the canonical assertion, verifiable offline from two published keys.
An organisation can publish an assertion about another one. This is what makes the other one’s agreement a verifiable fact rather than an unanswered claim: an Ed25519 countersignature over the canonical assertion, checkable offline from two published keys, by anyone, forever.
`@flashyos/directory` says what the estate knows; `@flashyos/countersign` is the proof the record layer has no opinion about. A countersignature is an Ed25519 signature from the party a claim is about, over the canonical assertion, checkable offline from two published keys by anyone, forever.
The signer needs no account and gives us nothing: their key is generated in their browser and never leaves it. The CLI resolves and fetches records, grades them as of a date, invites a counterparty to sign, applies what came back, and verifies every countersignature against a JWKS.
The schemas and the conformance suite are served at the URLs their own `$id` fields claim, so an implementation in any language can fetch them without importing anything of ours.
Installing it puts these commands on your path — read from the package’s own manifest, so this list cannot drift from what you actually get.
flashy-countersignflashyos-countersign-adoptionA countersignature is checkable offline forever, so its honesty does not depend on us staying up: recompute it from two published keys. The directory schemas and the 23-case conformance suite are served at the URLs their own $id fields claim, and a route test in the marketing app fails if a schema is published without being served — because a schema that 404s points every outside implementer at nothing. Verify it yourself with `npx @flashyos/countersign conformance`.
Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.