Repository navigation
id: design: user-held keys (custody variant b) (from #5684) #5887
Description
Summary
Follow-on design ticket from #5684 — its decomposition sketch names this as a separate design, and the parent's acceptance requires these tickets to be filed and linked. Filed in the 2026-11-04 gap pass (WS-F) so the design work exists and can be prioritised on its own merits; implementation timing is a separate decision, possibly months out.
What this design must settle
Drive/file storage of user-held keys, client-side unlock, and the new-device and lost-key flows.
Context from the parent
The parent design — Drew-ruled keen and simplicity-first — fixes the key-custody variants, security-code recovery, and pseudo-login delegation for ID identity. The parent issue carries the surrounding decisions this ticket must not re-decide; where this ticket's answer would change a parent decision, record that explicitly rather than silently forking it.
Decision record expected
Close this design with a recorded decision (on this issue or in a doc/ record linked from it): the chosen shape, the alternatives rejected and why, and the invariants implementation must hold. If the design splits further, file the splits and link them here rather than growing this issue.
Relations
Parent: #5684. Programme: epic #2056. Filed by WS-F (2026-11-04 ID design gap & expansion pass).
Activity
developing-today commentedon Nov 5, 2026
CODE-1570
dezren39 commentedon Nov 5, 2026
agent-note:v1
Triage 2026-11-05 (task 10289): well-scoped follow-on design ticket from #5684, verified open with no hard-stop labels and no decision record yet (only comment is the Kaneo link).
Ordering / authority notes, from fresh reads:
kind/designto match sibling tickets. Programme: epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056.No blocker on Drew.