feat(signer): waiting indicator + timeout for remote-signer approvals#11
Conversation
Deploying jank with
|
| Latest commit: |
cd6e121
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://1c3a3104.jank-4ii.pages.dev |
| Branch Preview URL: | https://feat-signer-approval-timeout.jank-4ii.pages.dev |
Browser smoke (real Clave bunker) → one fix appliedSmoke-tested against a live Clave NIP-46 bunker. Found and fixed one issue: Background relay AUTH leaked into the approval wait. jank signs NIP-42 relay AUTH (kind 22242) and NIP-98 HTTP auth (kind 27235) through the same Fix ( Out of scope (pre-existing, not this PR)On Clave low-trust, posting fails immediately with Gate 3 (realistic-relay smoke) — status
|
…vals Wrap signEvent for the bunker (NIP-46) and NIP-07 signers with a shared withSignerApproval helper: after a 1s delay (so instant auto-approvals stay silent) a low-key loading toast appears and auto-dismisses when the signature returns; concurrent signs reference-count into one toast. The wait is bounded by a 30s timeout so an unresponsive signer (offline bunker, closed extension popup) rejects instead of hanging the composer forever. Ported from upstream Jumble e0c4dca3. nsec/npub signers are intentionally not wrapped (instant local sign / view-only). Upstream's mobile toast-offset tweak is skipped — jank already tunes mobileOffset for its own chrome. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NIP-42 relay AUTH (kind 22242) and NIP-98 HTTP auth (kind 27235) flow through the same signer.signEvent chokepoint as user posts, so the new withSignerApproval wrapper was surfacing a "Waiting for signer approval" toast and a 30s timeout for every background relay-AUTH sign — noisy on a multi-relay deck, and it rejected AUTH signs the user never meant to approve (observed live: "subscribe auth function failed: Signer did not respond in time"). Pass the draft kind through to withSignerApproval and pass auth kinds straight through with no toast and no timeout, reverting AUTH to its prior behavior. Real user-initiated signs still get the waiting indicator + bound. Adds a unit test. Found in browser smoke against a real Clave bunker. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
99f4ea6 to
cd6e121
Compare
What
Ports the signer-approval wait indicator + timeout from upstream Jumble (
e0c4dca3), adapted to jank's signer registry.signEventon the bunker (NIP-46) and NIP-07 signers is now wrapped in a sharedwithSignerApproval()helper (src/lib/signer-approval.ts):loadingtoast appears: "Waiting for signer approval…", and auto-dismisses when the signature returns.This is squarely jank's NIP-46-heavy model — the worst UX gap of remote signing was the silent pending sign.
Scope decisions
mobileOffsetretune is skipped — jank already tunesmobileOffsetfor its own chrome; the toast inherits it.signEventonly). A bunker DM-decrypt can also hang; wrapping it is a candidate follow-up after smoke.Gates
withSignerApprovalnever touchespubkey/identity — it only races the existingsignEventpromise against a timeout, so it introduces no identity drift; the downstream per-publish identity assert is unaffected. The 30s window is generous for manual approval; on timeout the sign rejects and the caller's existing error path fires (user retries).Smoke checklist (please run before merging)
Verification
npm run build✅ (real type check)npm test✅ 857 passed / 1 skipped🤖 Generated with Claude Code