Plaza never authenticates to a relay. The library half is finished and unused: nip42.authEvent builds the kind 22242 event with its relay and challenge tags, message.encodeAuth wraps it, parseRelayMessage decodes the incoming ["AUTH", challenge], and Relay.authenticate sends it. Nothing in Plaza calls any of them. Every relay read loop switches on the message and ends in else => continue (in ownProfileWorker, publishEvent and fetchProfileWorker), so an .auth message is dropped on the floor.
Two live consequences. ownProfileWorker treats .eose, .closed as a satisfactory answer. For an EOSE that is right. For ["CLOSED", sub, "auth-required: ..."] it is not: the check concludes this account has no kind 0 on a relay that declined to look, and that decides whether a profile gets replaced with an empty one. And outboxHasRoom's own doc names the state: sixteen unacked notes wedge the queue for as long as the failure lasts, and a pool that all requires NIP-42 AUTH is one of the two ways it names to get there. I diagnosed this at the library level in zig-nostr/nostr#48.
It is also what NIP-29 runs into first, because a relay cannot decide whether a socket belongs to a member without knowing whose socket it is.
The part needing care: the relay tag must be the full dialed URL or the relay rejects it, and the event is signed by my key, so it needs the same signer path signAndPublish uses, possibly a bunker round trip, on a thread otherwise parked in receive().
Done
A relay that challenges gets a signed 22242 back; a subscription closed for auth is retried after authenticating rather than recorded as answered; and a relay that will not authenticate says so in its row instead of reading as offline.
Plaza never authenticates to a relay. The library half is finished and unused:
nip42.authEventbuilds the kind 22242 event with itsrelayandchallengetags,message.encodeAuthwraps it,parseRelayMessagedecodes the incoming["AUTH", challenge], andRelay.authenticatesends it. Nothing in Plaza calls any of them. Every relay read loop switches on the message and ends inelse => continue(inownProfileWorker,publishEventandfetchProfileWorker), so an.authmessage is dropped on the floor.Two live consequences.
ownProfileWorkertreats.eose, .closedas a satisfactory answer. For an EOSE that is right. For["CLOSED", sub, "auth-required: ..."]it is not: the check concludes this account has no kind 0 on a relay that declined to look, and that decides whether a profile gets replaced with an empty one. AndoutboxHasRoom's own doc names the state: sixteen unacked notes wedge the queue for as long as the failure lasts, and a pool that all requires NIP-42 AUTH is one of the two ways it names to get there. I diagnosed this at the library level in zig-nostr/nostr#48.It is also what NIP-29 runs into first, because a relay cannot decide whether a socket belongs to a member without knowing whose socket it is.
The part needing care: the
relaytag must be the full dialed URL or the relay rejects it, and the event is signed by my key, so it needs the same signer pathsignAndPublishuses, possibly a bunker round trip, on a thread otherwise parked inreceive().Done
A relay that challenges gets a signed 22242 back; a subscription closed for auth is retried after authenticating rather than recorded as answered; and a relay that will not authenticate says so in its row instead of reading as offline.