NIP-46 bunker requests have no timeout and surface raw signer errors to users #19

New issue

Closed

opened 2026-07-08 11:30:36 +00:00 by laoc · 2 comments

laoc commented

2026-07-08 11:30:36 +00:00

Owner

Found while investigating #4.

NostrConnectSigner requests have no timeout: if the remote signer (nsec.app, Amber) is asleep on the first sign request of a session, the UI hangs in "Applying changes…" forever. After a reload the bunker is awake and signing works — matching the "first try fails, works after reload" report in #4.
Remote signer error strings are surfaced verbatim to the user (e.g. the suspected "exceeded quota" message) with no context about where they come from.

Needs: a timeout + user-facing "waiting for your signing app…" state around NIP-46 sign requests, and wrapping remote errors with a hint that they come from the connected signer. Note commit ed7cf6d9 fixed the stuck-queue variant for NIP-07 extensions only; bunker accounts were left untouched.

Found while investigating #4. 1. `NostrConnectSigner` requests have no timeout: if the remote signer (nsec.app, Amber) is asleep on the first sign request of a session, the UI hangs in "Applying changes…" forever. After a reload the bunker is awake and signing works — matching the "first try fails, works after reload" report in #4. 2. Remote signer error strings are surfaced verbatim to the user (e.g. the suspected "exceeded quota" message) with no context about where they come from. Needs: a timeout + user-facing "waiting for your signing app…" state around NIP-46 sign requests, and wrapping remote errors with a hint that they come from the connected signer. Note commit ed7cf6d9 fixed the stuck-queue variant for NIP-07 extensions only; bunker accounts were left untouched.

laoc added the

bug

label

2026-07-08 11:30:36 +00:00

laoc referenced this issue

2026-07-08 11:35:42 +00:00

Sharing a calendar event with a community fails on first try, works after reload #4

laoc referenced this issue

2026-07-09 09:37:02 +00:00

Sharing a calendar event with a community fails on first try, works after reload #4

laoc commented

2026-07-09 10:10:32 +00:00

Author

Owner

Core fix on branch fix/issue-19-bunker-signing (unit-tested): bunker (nostr-connect) accounts keep their signing queue but the signer is wrapped so signEvent rejects after 90s ("…the signer did not respond") instead of hanging on a sleeping remote app, and remote error strings are rethrown with attribution ("Your remote signing app reported an error: exceeded quota") instead of surfacing raw. Follow-ups still worth doing here: a "waiting for your signing app…" UI state during pending NIP-46 requests, and the same wrapper for nip04/nip44 encrypt/decrypt (DM flows can hang the same way).

Core fix on branch `fix/issue-19-bunker-signing` (unit-tested): bunker (nostr-connect) accounts keep their signing queue but the signer is wrapped so signEvent rejects after 90s ("…the signer did not respond") instead of hanging on a sleeping remote app, and remote error strings are rethrown with attribution ("Your remote signing app reported an error: exceeded quota") instead of surfacing raw. Follow-ups still worth doing here: a "waiting for your signing app…" UI state during pending NIP-46 requests, and the same wrapper for nip04/nip44 encrypt/decrypt (DM flows can hang the same way).

laoc commented

2026-07-09 10:29:44 +00:00

Author

Owner

Confirmed by Steffen; merged to dev. UI waiting-state and nip04/nip44 wrapping remain as optional follow-ups (see previous comment).

laoc closed this issue

2026-07-09 10:29:44 +00:00