Skip to content

Add WebAuthn-based glyph recovery flow to Sigil Explorer#388

Open
kojibai wants to merge 2 commits intomainfrom
codex/add-glyph-recovery-feature-for-users
Open

Add WebAuthn-based glyph recovery flow to Sigil Explorer#388
kojibai wants to merge 2 commits intomainfrom
codex/add-glyph-recovery-feature-for-users

Conversation

@kojibai
Copy link
Owner

@kojibai kojibai commented Feb 14, 2026

Motivation

  • Provide a surgical, offline-first recovery path so a user who loses a device can rehydrate all glyphs they previously saved by proving possession of the same WebAuthn passkey bound to their Φ‑Key.
  • Reuse existing client-side WebAuthn and KAS utilities so recovery is gated to the passkey holder without backend schema changes.

Description

  • Added a new Recover My Glyphs button in the Sigil Explorer toolbar and a small status pill to surface progress/results, with a disabled state while recovery is in progress.
  • Implemented handleRecoverByPasskey which requests an assertion via getWebAuthnAssertionJson, verifies it with verifyWebAuthnAssertion, derives the authenticated Φ‑Key via derivePhiKeyFromPubKeyJwk, and then fetches the remote registry with apiFetchJsonWithFailover((base) => ${base}/sigils/state) to find matching glyph URLs.
  • Re-ingests matching glyph URLs into the local keystream using the existing addUrl/persistRegistryToStorage/bump flow so recovered glyphs are available offline in the current client registry.
  • Minimal API additions: local ApiStateResponse/ApiStateRow typings only; no server or crypto protocol changes and all logic reuses existing utilities (webauthnReceive, webauthnKAS, registry ingestion).

Testing

  • Built the project with pnpm -s build and the build completed successfully.
  • Ran lint on the modified file with pnpm -s exec eslint src/components/SigilExplorer.tsx which passed (file still has pre-existing non-blocking warnings unrelated to the new flow).
  • Exercised the UI by running the dev server and a Playwright script to navigate to the Explorer and capture a screenshot showing the new button (screenshot artifact generated).

Codex Task

@vercel
Copy link

vercel bot commented Feb 14, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
phi-network-5aii Ready Ready Preview, Comment Feb 14, 2026 6:36pm

Request Review

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ef84aa43b9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +3744 to +3747
const stored = listStoredKasPasskeys();
if (stored.length === 0) {
throw new Error("No saved passkey was found on this browser for recovery.");
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Allow passkey recovery without local key cache

This flow hard-fails when listStoredKasPasskeys() returns no local entries, but that function only reads browser localStorage; on a replacement device/browser (the main recovery scenario), a user can still have the synced WebAuthn credential while having zero local cache records, so recovery aborts before even requesting an assertion. As written, this makes the new “Recover My Glyphs” path unusable for lost-device recovery unless the original local storage is still present.

Useful? React with 👍 / 👎.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant