NIP-91: Extension Negotiation

[Semisol]

This NIP adds an extension negotiation scheme for clients and relays to negotiate new protocols. The intended goal is to replace NIP-11 for the discovery of relay supported features.

An extension feature negotiation scheme is also included.

[mikedilger]

Might I suggest doing this with HTTP headers on websocket connect?

According to websocket standards we are supposed to be using the Sec-WebSocket-Protocol header and specifying something like "nostr" because there are plenty of websocket servers out there that are not nostr relays. But we never did anything like that.

By using an HTTP header you won't need another round trip. Also, if the relay doesn't support it you won't get a response header but the relay will continue talking to you, whereas with a new command the relay might drop the connection because you are speaking gibberish.

[Semisol]

According to websocket standards we are supposed to be using the Sec-WebSocket-Protocol header and specifying something like "nostr" because there are plenty of websocket servers out there that are not nostr relays. But we never did anything like that.

This does not allow negotiating specific protocol parameters, or gating access behind AUTH. This also is problematic as you can only pick 1 protocol, and does not allow you to know what protocols the server could have offered but didn't pick.

By using an HTTP header you won't need another round trip. Also, if the relay doesn't support it you won't get a response header but the relay will continue talking to you, whereas with a new command the relay might drop the connection because you are speaking gibberish.

The relay sends the first command, PN-OFFER, which does not add a round trip as it is sent at the same time the connection is opened, and only protocols that need parameter negotiation need another round trip.
A relay which will drop the connection on an invalid command is also defective.

[Semisol]

Updated the NIP to be more accurate about its goals.

The x/ namespace has been removed, to encourage standardization

[buttercat1791]

@Semisol could relays use this to negotiate accepted kind numbers?

One might have a relay, for instance, that does not store parameterized replaceable events. Could this NIP be used by the relay to indicate this limitation to the client? Then the client would know not to try to published parameterized replaceable events to the relay.

This is distinct from merely indicating a supported NIP, as relays may support kind ranges that are not yet part of any widely-accepted NIP.

[Semisol]

@Semisol could relays use this to negotiate accepted kind numbers?

One might have a relay, for instance, that does not store parameterized replaceable events. Could this NIP be used by the relay to indicate this limitation to the client? Then the client would know not to try to published parameterized replaceable events to the relay.

I expect that most NIP-11 data for indicating capabilities and features can be moved here, even giving different users different privileges.

[mikedilger]

This does not allow negotiating specific protocol parameters, or gating access behind AUTH. This also is problematic as you can only pick 1 protocol, and does not allow you to know what protocols the server could have offered but didn't pick.

I'm not saying to use Sec-WebSocket-Protocol itself, make up a new header. Put in the client's requested features. Then the server sends back that same header with the supported/accepted features. Of course in the way I envision it, the client starts the negotiation not the relay.

You are right it is not gated behind AUTH. I can't think why it should be.

A relay which will drop the connection on an invalid command is also defective.

NIP-01 does not define what a relay should do if it receives a command it does not understand.

[Semisol]

NIP-01 does not define what a relay should do if it receives a command it does not understand.

Again, in this case, the communication is initiated by the relay. A majority of clients and relays I use currently ignore and send errors on unknown commands, not close the connection.

[Semisol]

I'm not saying to use Sec-WebSocket-Protocol itself, make up a new header. Put in the client's requested features. Then the server sends back that same header with the supported/accepted features. Of course in the way I envision it, the client starts the negotiation not the relay.

@mikedilger Also, the problem here is you now break compatibility for all web clients.

You are right it is not gated behind AUTH. I can't think why it should be.

A goal of this NIP is to replace NIP-11 for relay information, which includes things like event constraints.

[staab]

This seems too structured/interactive for nostr. NIP 11 is annoying in some ways, but it does the job for most things. For other things, #1434 seems preferable since it's more concrete.