Feature 0
Card creation & basic resolver
Sign a card in the browser. Resolve it on scan.
Live /create/ → Worker POST → D1 → scan at /c/{profile_id}?q=…
About this feature
Why it matters
Proves the core thesis: a printed QR is a live software endpoint, not a frozen link. No app install, no account gate for scanning - any camera can read current public state.
Design decisions
Ed25519 keys generated in-browser; signed card + QR credential POSTed to /.well-known/hc/v1/cards. JCS canonicalization for cross-client parity. Profile and QR ids are base58 - stable in the printed URL forever; meaning changes via resolver status, not reprinting.
Safety · privacy · security
Private signing keys never leave the owner device unless the user exports an encrypted backup. Resolver verifies signatures on ingest and stores only public documents and status flags - not a people trail.
Limits
Control stays in this tab until you save ownership on this device on /created/ (auto-save is on by default). Operator cannot restore lost ownership. Printed URL exposes profile_id and qr_id.
Advanced: signing keys & browser storage
Owner signing material starts in sessionStorage (hc_created) per tab. Save ownership on this device copies control to localStorage (hc_wallet) for other tabs on this browser. On iOS Safari, Camera QR opens a fresh tab — see Safari keys on the help guide.
Future directions
Federated resolvers implementing the same hc/v1 API; NFC/mesh carriers pointing at the same truth; optional multi-device sync without central key custody.