A single green photon striking a small dark sensor and blooming into light at the point of contact

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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

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.

  1. 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.
  2. 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.
  3. 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.