NIP-42: CLOSED in response to REQ when not authenticated

[verbiricha]

When submitting REQs to relays that require NIP-42 auth, some of them (for example eden.nostr.land) will send back an AUTH message and keep the REQ open until the client is authenticated, sending events for the REQs after successful authentication. Others (for example filter.nostr.wine) will send back a both an AUTH message and CLOSED message for the REQ with the auth-required prefix.

Is it possible for NDK to detect the second scenario and re-send the REQs that were CLOSED due to lack of authentication after successfully authenticating? I also think it'd be nice to include the reason string from the relay's CLOSED message when emitting the close event on a subscription, thoughts @pablof7z ?

[fiatjaf]

The message is CLOSED, not CLOSE, right?

[verbiricha]

Yes, the messages from relay to client is CLOSED not CLOSE, sorry for the confusion. Enviado desde Proton Mail móvil

…

-------- Mensaje original -------- El 31 dic 2023, 13:41, fiatjaf_ escribió:

The message is CLOSED, CLOSE, right? — Reply to this email directly, [view it on GitHub](#171 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AWAGFU22UPPC57XXHAHS7DTYMFMQVAVCNFSM6AAAAABBIF3XOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSHEZTSNBZG4). You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeremyd]

I am seeing this as well. I am trying to find in the code where it sees the CLOSED message from the relay itself, but as far as I can tell NDK is not tracking these kind of messages at all. It only closes subscriptions client side, it has no idea when a relay sends CLOSED on a sub, it only knows about EOSE.. Not sure how to work around this yet or if it can be fixed. Ideally you could subscribe to a CLOSED from the relay just like EOSE, and re-send the subscription after auth.

[jeremyd]

I ended up delaying the subscription until after auth, pasted some example code here if you are curious.

#246 (comment)