archon

Why it exists

The constellation's one-change-authority rule says the owner of a thing is the lowest layer that can define its canonical bytes, validity conditions and versioning without higher-layer vocabulary. Point that rule at Ed25519 and it answers at once: key derivation, signing, verification, the canonical key spelling and the PEM codec are RFC 8032, RFC 5280 and RFC 5958 — they need zero Bitspark vocabulary. thesmos had carried them for years, and its own repo inventory diagnosed why that was drift rather than design: thesmos is where the constellation puts anything that must be tri-core byte-pinned — a capability — while its charter names a domain, authority. Identity had drifted in for the capability.

archon is the correction, and the name is the split. In Athens the archons held the offices; the θεσμοί were the laws laid down that bound them. archon is who bears the office; thesmos is the law that binds it. thesmos deleted its own key layer when the extraction landed — there is one implementation, and it is here.

A concrete example

A key is spelled exactly one way, ed25519:<hex>, and decoded by exactly one guarded routine: encode_key / decode_key, with seed_from_hex / pubkey_from_hex / signature_from_hex refusing anything that is not exactly 32 or 64 bytes — the length guard thesmos had repeated by hand at roughly thirty call sites, written once. verify collapses every shape failure to false in all three languages, because Go's stdlib ed25519.Verify panics on a wrong-sized key and a floor must not.

Above the primitives sits domain-separated signing — sign_in_domain / verify_in_domain, Ed25519ph with the domain as RFC 8032 context — so one key can serve many protocols and a signature from one domain verifies in no other, and never raw. The domain is the caller's; archon registers none.

Curve arithmetic is not written three times. Each core binds its language's mature, audited Ed25519 (ed25519-dalek, Go's stdlib, @noble/ed25519). What archon writes three times is its encodings — because an encoding only one core can read is not a floor. That distinction is the whole discipline of the repo, and a byte-pinned conformance harness (three cores, 180 case-checks, run on every push) is what proves it holds.

What it unlocks

archon is a pure leaf: dependsOn: [], and that is not modesty — it is the property that makes it usable. A node daemon, a custodial lens, or logos itself can link archon without pulling in a value model, a reasoning engine, or the admission law. Both direct consumers do: stele takes identity from archon and law from thesmos, and thesmos itself compiles against archon's key layer. Anything that would add an edge out of archon should be suspected of belonging somewhere else.

The value proposition is deliberately not universal, and the honest form names where it does not apply. logos could have taken archon as the backend for its opt-in leaf-signature helper; measured, it should not — that seam never spells a key as text, so archon's distinctive surface would be dead weight, and introducing ed25519:<hex> beside logos's existing canonical hex would create the second spelling archon exists to eliminate. One canonical spelling instead of three is a reason to adopt archon in a repo that has zero, not in one that has one.

What's next

The floor is in production and frozen at its charter, which was measured narrower than first proposed — identity itself, not succession, proof of possession or "the principal". Above it, an sdk/ with exactly one dependency (the floor) carries proof of possession with mandatory channel binding and a signed envelope that is JWS and never JWT — no expiry, issuer, audience or key-id, each being policy or a second spelling of the key. The first proposal to grow the floor further — typed decoders, an SDK tier, an archon CLI — is written down as a growth plan, proposed, not ruled. Connection setup is not in the sdk and never will be: it is the transport, and that is kosmos's.