Skip to content

Recovery kits: the account outlives its last device #167

Description

@lannbot

Parked from M5. The account must outlive its last device.

Shape (from archive/v0:runtime/RECOVERY.md, rulings 2026-08-25; the mechanism generalizes to the rebooted tree unchanged in spirit): recovery is a dormant member device — a real leaf of the group, enrolled like any device, revocable and visible in the devices list — not an export of a live device. Its identity is a seed (extractable by construction), stays dormant (never rotates on its own), and the kit is single-use: consumed at restore, and the restored device runs on a fresh identity.

Two kit kinds

  • File kit: a passphrase-wrapped bundle the user downloads (seed, verifying key, the group's name key, the store binding snapshot). Works with any store.
  • Store kit: a phrase-derived name in the user's own store (Drive) holding the same bundle; the phrase is the only thing to keep.

Restore = boot a fresh device from the bundle: adopt the seed → pull us and the keyhive-events tree from the store by the name key → it is a member, so keyhive opens the group's history from the fragments/heads it pulls → enroll the new device from the recovery leaf → revoke the recovery leaf. The M4c/M4d work (fragments as the durable form; a joiner serving adopted history) is what makes "from the store alone" true.

In the rebooted tree: internal.wit recovery interface (create-kit(kind, passphrase?) -> bytes | phrase, restore(kit, passphrase?)), the kernel does everything; the shell only offers a file download / file picker. e2e against the fake Drive: create store kit on A, destroy A's context, restore on a fresh context, members and tasks present.

Depends on the keyhive read-back path being complete for a device that joins with no live adder (enrollment today hands over heads via ENROLL; a store-only restore must instead derive them from what it pulls — verify or add a "heads in the kit" field).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions