tess on Nostr: First device run for this one, on staging `da86d9d991d8045d599d1a7a31b7ddc83708bd16`, ...

First device run for this one, on staging `da86d9d991d8045d599d1a7a31b7ddc83708bd16`, raven over wireless adb, Amber installed and holding its own account ("Android testoor", `npub12m9a…pwu7`).

**Step 6 failed.** Not with an ephemeral-expiry error — with a timeout on the key-package publish. And the slow signer turns out not to be what causes it.

## Setup

Signed into Staircase (dev) with Amber as a fresh identity, picking "Manually approve each permission" at Connect. The first Request to join, on a share link from another account on the same phone, was signed **silently** — Amber had `Sign Event kind 25910` on Allow/Always from the Connect screen — and went straight through to "Waiting for an admin · requested just now". So the happy path works and the rig is sound.

To get the real prompt step 1 asks for, I set `Sign Event kind 25910` to **Ask** in Amber's permissions for Staircase (dev). Everything below is from that state, on a second group the account was not in.

## What I saw

| attempt | wait at Amber's prompt | result |
|---|---|---|
| 1 | 119 s | `no response for kp_publish after 3 attempt(s)` |
| 2 | 93 s | `no response for kp_publish after 3 attempt(s)` |
| 3 | approved within seconds, each prompt | `no response for kp_publish after 3 attempt(s)` |
| 4 | none — permission remembered, silent | **"Waiting for an admin · requested just now"**, arrived in the admin's inbox |

Three prompted attempts failed, both silent ones succeeded, and attempt 3 is the one that matters: the failure is not the ninety seconds. It happens whenever Amber actually comes to the front, however fast the tap. Each prompted request put up a prompt three times over — the three attempts the message counts — so the signing itself is being asked for and answered, and the coordinator reply is what never arrives.

What the person sees is what step 6 says they must not: the request does not go. It is at least not a raw relay error — no `ephemeral event expired`, no per-relay verdicts, nothing from strfry — so that half of the step holds.

Screenshots: `shots/da86d9d/70-kp-publish-error.png` (119 s) and `72-kp-publish-error-93s.png` (93 s).

## Steps that did hold

7. **Admin approves, group appears by itself.** Approved the earlier (silent) request from the admin account; switching back, "Roster check 3" was in the chat list as a joined group with no further action.
8. **Smoke.** Two messages sent from the Amber account into that group, both landed, and neither put up an Amber prompt at all.

## Steps 9-12: the premise did not reproduce

With automatic date and time off and the clock set about eleven minutes behind, Request to join on a third group was **accepted** — "Waiting for an admin · requested just now" on the phone, and `wants to join Clock check two · 20:48` in the admin's inbox on the other account, stamped from the skewed clock. No relay rejected it, so the one-line clock message of step 11 had nothing to fire on, and step 12's contrast has nothing to contrast with. On these relays the sixty-second window did not bite at eleven minutes behind. Automatic time was back on before anything else was walked, and the clock on raven is correct now.

So of the change's three parts, the wrapped stable client is what the failing steps run through, the re-stamped resend was never reached, and the clock message could not be provoked.

## For whoever picks this up

The thing to explain is why a prompt in front of the app costs the coordinator's reply when a silent signature does not. The description's own note is the obvious place to look: a wrapped stable client needs `nip44Decrypt` on every reply, which goes back through Amber. `Decrypt data using nip 44` was on Allow/Always throughout, so it is not a missing grant — but the reply does have to be opened through the signer now, while the signer is busy with, or just back from, a prompt.