Rejecting an old Nostr authentication after a WebSocket reconnect
A client reconnects to the same relay and reuses the last signed authentication event. The signer is familiar but the relay issued a new challenge on the new connection.
Bind the response to the current challenge
A NIP-42 authentication signs a kind-22242 event with the relay URL and challenge. The example isolates those two fields after signature verification. It prints false because the prior socket’s challenge does not match. Also verify the event kind and freshness before associating its public key with the current connection.
const issued = { relay: "wss://relay.example", challenge: "socket-2" };
const signedTags = [["relay","wss://relay.example"],["challenge","socket-1"]];
const field = name => signedTags.find(t => t[0] === name)?.[1];
console.log(field("relay") === issued.relay && field("challenge") === issued.challenge);
Resume the protected operation
Wait for the relay’s OK response to authentication. If an earlier publish or subscription was rejected for requiring authentication, retry that operation once the relay accepts the proof. Authentication events are ephemeral protocol messages and must stay out of the public event stream. Log the rejected operation and connection ID so a refresh loop can be distinguished from a permission refusal.