For developers
passless replaces the account with a fact. A service either holds a user's public key and recognizes signatures from it, or it does not know the user exists. There is no third state, and there is no third party.
The shape of the protocol
handle_seed = BLAKE3(NFC(handle)) # any Unicode; never leaves the device handle_proof = derive(handle_seed) # the public lookup key on the network device_key = derive(device_secret, seed) # hardware-bound; never stored on disk identity = handle + fleet of devices # each device signs as the user
- Claiming. An unclaimed handle costs one ~1-second memory-hard proof of work: trivial for a person, uneconomic in bulk. First to finish owns it. No authority admits or refuses anyone; there is no registry of the permitted. Multiple handles per human are likewise not forbidden, because there is no forbidder, but reputation accrues per handle thru lived interaction and never transfers, so a handle nobody lives in earns nothing and vouches for nothing.
- Authentication happens once, at identity creation. Everything after is verification: cheap, continuous confirmation that a signature came from the same key. Sessions, logins, and resets are not simplified. They are absent.
- Devices are a fleet. A new device is signed in by an existing one (near-tap or a short pairing phrase). Any device can revoke any other. One identity may be live on many devices; a device asserts exactly one identity at a time.
- Contact is mutual. The network only ever sees hashes; a handle is exchanged human-to-human, out of band. Two parties can reach each other only after each adds the other. Reachability is consent.
- Recovery is threshold reconstitution. User-chosen custodians (minimum three, threshold at least three) can restore the mathematically identical credential after total device loss. No re-enrollment anywhere, because services never knew anything but the public key, and the public key does not change.
Design doctrine
- No secrets at rest. Keys are derived when needed from things the user holds. A stolen disk holds ciphertext and hashes.
- Absence, not denial. A query without the key returns silence indistinguishable from nonexistence. "Permission denied" confirms a target; passless systems never do.
- The wire is the spec. Everything serializes as VSF: every field typed and length-declared, BLAKE3 provenance and signatures inside the format, no external schema for two readers to disagree over.
- No single lock. Key exchange (CLUTCH) runs eight primitives from four unrelated mathematical families and combines them; an attacker must break all eight simultaneously, including one unbroken since 1978.
- Determinism everywhere. Same inputs, same bytes, every platform. If two conforming implementations disagree, at least one has a bug, and the format makes that provable.
- Trust nothing you cannot check. Binaries self-verify their signatures. Time comes from consensus, not a server's word. The endgame for device secrets is open, auditable silicon, and until then the limits are stated out loud on the reviewers page.
Conformance
Adoption is the goal. Capture is the failure. The line between them is three requirements, and an implementation is passless only if it meets all three. The patent non-assertion pledge attaches to conformance, so these are not recommendations.
- Custodians are user-elected and portable. The user names their own recovery custodians and can replace them at will. A conforming implementation MUST NOT make any vendor, account, or cloud the sole recovery path, and MUST allow a custodian set held entirely outside the implementer's control.
- Attestations are issuer-indistinguishable at the verifier. A relying party MUST NOT be able to learn, from a conforming attest, which vendor's hardware or software produced it. No implementation may be a "premium" human, and no verifier may be handed a way to rank humans by chip.
- Device secrets are owner-provisioned. The hardware secret is generated on the device, from on-device entropy, at the owner's initiative. It MUST NOT be injected at manufacture, escrowed, mirrored, or readable by the implementer, so it cannot be revoked, cloned, or compelled.
Everything else is negotiable. These are not. An implementation that fails one is a passkey with better marketing, and the pledge does not cover it.
The code
- Photon
- The reference application: fleet enrollment, CLUTCH key exchange, rolling-chain encrypted messaging over a Kademlia DHT. Running on a live, open network since July 2026.
- tohu
- Device identity oracle: platform secret to derived keys, nothing exfiltrated, nothing stored.
- ihi
- The one-way derivation primitives between a handle and its public proof.
- VSF
- The serialization layer everything above speaks.
All of it MIT OR Apache-2.0. A patent non-assertion pledge is coming to the front page. It covers every implementation that meets the three conformance requirements above, and none that does not. The intent is simple: build passless things freely, forever, and nobody gets to close the door behind them.
What to build
Anything that currently begins with a login screen. The interesting question for your app is not "how do I add passless auth" but "what does my design look like when the user is simply known," because that deletes your account system, your reset flow, your email verifier, and your session store in one move. Start there.