CLOSED messages for relays that want to reject REQs and NIP-42 AUTH integration

[fiatjaf]

I will quote my own message from #841 (comment) to explain this:

Basically we have two distinct problems:

1. knowing why a relay is asking for AUTH
2. knowing why a subscription has failed

adding a third element to AUTH only solves them in the occasion that the two happen together.

creating a new message solves 2 and making AUTH be subservient to that (and also to OK) solves 1.

More relevant messages were posted to that other thread but should probably have been posted to this.

[monlovesmango]

some minor changes, but I approve.

personally think we should just use "CLOSE" rather than "CLOSED" to mirror the client side "CLOSE" (in the same way that "EVENT" is the same on client and relay sides and mean the same thing). seems way more consistent to me.

ps. really like the "CLOSE" verb over the ones that I suggested

[fiatjaf]

My rationale for CLOSED was that when a client is sending a CLOSE it is requesting the relay to close the subscription, but when a relay sends it it is just notifying the client that it has already been done.

Also I prefer to have different words, makes the parsing code simpler.

[arthurfranca]

ACK!! The flow is very clear now with examples and all.

Personally I would just tell relays to always send AUTH right after connection is established. It leaves less room for errors (like sending CLOSED/OK before AUTH).

[proudmuslim-dev]

Suggested change

	- `"auth-required: "` - for when a client has not performed `AUTH` and the relay requires that to fulfill the query or write the event.
	- `"auth-required: "` - for when a client has not performed `AUTH` and the relay requires it to fulfill the query or write the event.

[staab]

From #841 (comment)

I think it won't hurt at all to have a message akin to OK but specifically for REQs.

This makes sense. We could probably use the same verb for COUNT and other future read-verbs like HASH too? Not necessary to specify, just a thought.

[jb55]

LGTM

[monlovesmango]

should this also apply to nip 45?

[mikedilger]

+1

[proudmuslim-dev]

Suggested change

	At any moment the relay may send an `AUTH` message to the client containing a challenge. The challenge is valid for the duration of the connection or until another challenge is sent by the relay. The client MAY decide to send its `AUTH` event at any point and the authenticated session is valid afterwards for the duration of the connection.
	At any moment the relay may send an `AUTH` message to the client containing a challenge. The challenge is valid for the duration of the connection or until another challenge is sent by the relay. The client MAY decide to send its `AUTH` event at any point and the authenticated session is then valid for the remainder of the connection.

[fiatjaf]

Implemented in https://github.com/nbd-wtf/go-nostr and https://github.com/fiatjaf/khatru.

[fiatjaf]

Implemented in https://nostr.wine

[nostr-wine]

Ha - you beat me to it. We implemented CLOSED with the new flow for DM REQs on all nostr.wine regional relays and will work on the rest of our relays today.