nostr/money: payment gift-wrap write races NIP-42 auth (SDK won't resend a rejected write) + no timeout on buyer writes

[orveth]

Summary

Two related write-path hygiene gaps found in the nostr audit (projects/mobee-seller-node/NOSTR-AUDIT.md, N-3/N-8). The sharper one is money-adjacent: the buyer's ecash gift-wrap write fires before NIP-42 auth can complete, and the SDK will not re-auth-and-resend a rejected write — so an auth-gated write racing the handshake is dropped, not retried. The neighbouring receipt write gates on auth explicitly; the payment write does not. Line cites are origin/dev-era e14942a.

N-3 — payment gift-wrap does not wait for NIP-42 auth (money, VERIFY-NEEDED trigger)

payment_send.rs:207-216 (send_payment, the buyer→seller kind-1059 payment):

let client = Client::new(self.keys.clone());
client.add_relay(&self.relay).await?;
client.connect().await;                       // no wait_for_connection
let output = client.send_event_to([&self.relay], &gift_wrap).await;   // fired immediately
client.disconnect().await;

• Auto-auth is on by default (nostr-relay-pool 0.44.1 pool/options.rs:21), so the client will answer a challenge — but asynchronously, on the inbound RelayMessage::Auth path (relay/inner.rs:1057-1064).
• wait_for_ok returns the first OK for the event verbatim and does not re-authenticate-and-resend on an auth-required rejection (relay/inner.rs:1379-1415).
• So if the EVENT is processed before the auth round-trip finishes, an auth-gated write is rejected and dropped; disconnect() follows immediately.

Contrast the receipt write (authorize_pay.rs:697-757), which subscribes notifications before connect, wait_for_connection(20s), and gates the send on Authenticated (:726), failing closed otherwise — because "mobee-relay requires NIP-42 AUTH for ALL writes" (:675).

The payment path works in the field (25+ paid), so the race usually wins. VERIFY-NEEDED: does mobee-relay auth-gate kind-1059 writes (not just the p-gated read)? If yes, this is a latent silent payment-write drop under connection latency. Fix: mirror the receipt path's wait_for_nip42_auth gate on the payment write (and set automatic_authentication(true) explicitly, as the receipt/seller paths do, to guard against option drift).

N-8 — no timeout on buyer write awaits

client.connect() + send_event_to have no per-call timeout in publish_draft_async (job_lifecycle.rs:1444-1447), payment_send (:211-215), and profile (:264/:318) — only fetch_events carries one. A hung relay socket blocks the MCP/CLI call indefinitely. The buzz presence loop's send_event (buzz.rs:439) is in the same un-timed class. This is the buyer-side analogue of the seller heartbeat/publish park in #173 (which covers the seller loop); authorize_pay already demonstrates the fix pattern (wait_for_connection(20s) + auth timeout) — it just is not applied uniformly.

Read-only audit; no code changed. Cross-ref #173 (seller-loop park), and the shared write path this would naturally live in under the buyer-client-consolidation issue.

[orveth]

Relay-side confirmation (operator ground truth, code @e18020a63, both deployed relays): the race is REAL and the VERIFY-NEEDED resolves to confirmed.

• handle_event checks conn.auth_state FIRST (event.rs:611-630) — unconditional, no kind exemption. A kind-1059 EVENT on a not-yet-authed connection gets ["OK", <id>, false, "auth-required: not authenticated"] and is dropped before ingest.
• The 1059 exemption at event.rs:637 covers only the pubkey-match check (that's what permits ephemeral-keyed gift-wraps) — it does NOT bypass the auth gate.
• No anonymous-write path exists for 1059 (open-read is read-only; open-ingest broadens post-auth kind scope only; HTTP requires NIP-98).

So the buyer's payment write is currently safe by timing alone: NIP-42 is a round-trip, the connection is Authenticated only after the client's AUTH response is processed, and a write fired immediately on connect races the client's own handshake. When the write loses the race, the drop is deterministic and the SDK does not resend.

Note the relay's rejection uses the NIP-42-prescribed retryable prefix auth-required: — a compliant client is expected to AUTH-and-resend on it. The correct fix is both halves:

1. Gate the payment write on auth-confirmed (mirror authorize_pay's wait_for_nip42_auth pattern) — removes the race.
2. Honor auth-required: as retryable on the shared write path — belt, and NIP-42 compliance any client should have.

No relay change needed or wanted — the behavior is correct and intended. Fix is assigned to the buyer persistent-client slice (#175), whose shared bounded auth-gated write path is the natural home for both halves.

[orveth]

Correction: N-3's core claim does not hold — the SDK does auth-and-resend

Verified against the pinned sources while scoping the buyer-client work. Posting before anyone builds the proposed fix, because the fix as described would be a duplicate of behavior that already exists.

What this issue claims: wait_for_ok "returns the first OK for the event verbatim and does not re-authenticate-and-resend on an auth-required rejection (relay/inner.rs:1379-1415)" ⇒ an auth-gated write racing the handshake is "rejected and dropped, not retried" ⇒ latent silent payment drop.

What the source shows: that is true of wait_for_ok in isolation — but wait_for_ok is not the path. Its caller, Relay::send_event (nostr-relay-pool-0.44.1 relay/mod.rs:434-470), implements exactly the behavior described as missing:

// If auth required, wait for authentication and resend it
if let Some(MachineReadablePrefix::AuthRequired) = MachineReadablePrefix::parse(&message) {
    let has_signer: bool = self.inner.state.has_signer().await;
    if self.inner.state.is_auto_authentication_enabled() && has_signer {
        self.wait_for_authentication(&mut notifications, WAIT_FOR_AUTHENTICATION_TIMEOUT).await?;
        let (status, message) = self._send_event(&mut notifications, event).await?;   // resend
        ...
    }
}

Every precondition holds for the payment path as written today:

• MachineReadablePrefix::parse matches literally m.starts_with("auth-required:") — nostr-0.44.4 message/relay.rs:78.
• nip42_auto_authentication defaults to true — pool/options.rs:21.
• has_signer() is true for Client::new(keys), which is what payment_send.rs:207 constructs.
• Both legs are bounded: WAIT_FOR_AUTHENTICATION_TIMEOUT 7s, WAIT_FOR_OK_TIMEOUT 10s (relay/constants.rs:10-11).
• The notifications receiver is subscribed before the first send, so the post-rejection Authenticated cannot be missed.

And the drop cannot be silent even if all of that fails. send_event_to records the per-relay reason in output.failed (pool/mod.rs:790+), and mobee's own payment_sent (payment_send.rs:246) returns Err("no relay accepted the NIP-17 payment") whenever relay_success is empty. The payment reducer holds at Sent and retries. There is no path where the buyer believes it paid while nothing was written.

The relay-side confirmation on this issue is sound on the relay fact (kind-1059 writes are auth-gated unconditionally). The client-side conclusion drawn from it — "no SDK resend, therefore deterministic silent drop" — is what does not survive checking the client source.

What survives

• N-8's missing wait_for_connection is real, but it is a wasted round, not a loss: a send attempted before the socket is up costs a failed attempt and a retry cycle. Worth fixing for latency and determinism.
• A new, sharper concern in its place: the SDK's resend is silently conditional on is_auto_authentication_enabled() && has_signer(). Nothing in mobee asserts either. A future "cleanup" of client construction that drops automatic_authentication(true), or a client built without a signer, removes the resend with no error and no log — and the symptom would surface far from that diff. This is the #174 hazard shape at the dependency boundary.

Proposed scope change

Drop the hand-rolled resend. Layering our own retry on top of the SDK's would make our attempt the third publish of the same event and would blur which failure the caller sees; duplicated retry logic on a money path is a hazard, not defense in depth.

Instead, in the buyer-client work (#175):

1. Set automatic_authentication(true) explicitly on the buyer client as a drift guard (the receipt path in authorize_pay.rs:701 already does this, for this reason).
2. Add wait_for_connection + the boot auth gate — this is the part of N-3/N-8 worth keeping.
3. Point the tooth at the dependency contract: against a NIP-42-enforcing fixture, a write rejected with auth-required: must still land after auth, from a client constructed the way we construct ours. That test goes red on an SDK bump that changes the resend, or on an option-drift cleanup — which is the failure we genuinely cannot see by reading our own code.

Suggest retitling to reflect what is actually actionable: the connection-wait gap plus pinning the SDK's conditional resend.