Problem
Under the #575 policy, NIP-98 HTTP auth tokens (kind 27235) are deliberately never auto-approved or remembered. Every such request therefore requires a fresh manual approval + biometric step. On-device this round-trip takes ~5–8s. Web clients enforce a short per-request NIP-98 auth deadline (a few seconds), so they time out and surface "Could not authenticate..." even though Keep signs the request correctly.
This is not a Keep signing bug — it is a UX/policy tradeoff: the #575 security stance is fundamentally slower than what a web client expects for near-instant auth.
On-device evidence
Tested latest keep-android debug build on a Pixel 9a against readstr (https://readstr.privkey.io:8444/reader), bunker relay bucket.coracle.social. All kind-27235 NIP-98 events signed successfully (success=true):
- 20:38:25 request → 20:38:33 signed event_id=9e9851d6 (8.1s)
- 20:39:42 request → 20:39:47 signed event_id=e4a75d03 (5.6s)
- 20:40:44 request → 20:40:52 signed event_id=fc1c4ece (8.1s)
readstr authenticated and loaded initially ("0 unread"), then showed a red "Could not authenticate..." banner. The latency is dominated by the mandatory manual-approval + biometric step. When approval is fast enough the request authenticates; when it lags, readstr's auth deadline elapses before Keep finishes signing.
Proposal
Add an opt-in, Amber-style timed-remember for NIP-98 (kind 27235) auth, scoped to a specific client + relay, with a short time clamp. An already-authorized bunker client could then perform repeated NIP-98 auth without re-prompting on every request, fixing the web-client timeout while keeping the default behavior unchanged.
Tradeoff
HTTP auth tokens are sensitive, so this must be:
Context
See keep-android bead keep-android-84y for the reproduction and timing data.
Problem
Under the #575 policy, NIP-98 HTTP auth tokens (kind 27235) are deliberately never auto-approved or remembered. Every such request therefore requires a fresh manual approval + biometric step. On-device this round-trip takes ~5–8s. Web clients enforce a short per-request NIP-98 auth deadline (a few seconds), so they time out and surface "Could not authenticate..." even though Keep signs the request correctly.
This is not a Keep signing bug — it is a UX/policy tradeoff: the #575 security stance is fundamentally slower than what a web client expects for near-instant auth.
On-device evidence
Tested latest keep-android debug build on a Pixel 9a against readstr (https://readstr.privkey.io:8444/reader), bunker relay bucket.coracle.social. All kind-27235 NIP-98 events signed successfully (
success=true):readstr authenticated and loaded initially ("0 unread"), then showed a red "Could not authenticate..." banner. The latency is dominated by the mandatory manual-approval + biometric step. When approval is fast enough the request authenticates; when it lags, readstr's auth deadline elapses before Keep finishes signing.
Proposal
Add an opt-in, Amber-style timed-remember for NIP-98 (kind 27235) auth, scoped to a specific client + relay, with a short time clamp. An already-authorized bunker client could then perform repeated NIP-98 auth without re-prompting on every request, fixing the web-client timeout while keeping the default behavior unchanged.
Tradeoff
HTTP auth tokens are sensitive, so this must be:
Context
See keep-android bead keep-android-84y for the reproduction and timing data.