search

ircv3 / ircv3-ideas

46 stars 3 forks source link

Two way value negotiation in CAP #51

Open emersonveenstra opened 4 years ago

emersonveenstra commented 4 years ago

Idea for CAP negotiation, adding client -> server cap value negotiation. Now that we're getting much more modern and powerful IRCds/clients, this could be useful to selectively take advantage of client/server features while still retaining backwards compat.

Overview

Capability values in CAP LS will have the syntax <cap>=<allowed values>:<default value> where <allowed values> can be either a comma separated list of values, or a range of numbers with the syntax <lower bound>..<upper bound> (delineator up for debate).

Clients will then REQ these caps with the value they wish to have from the allowed options. If the client doesn't send a value where the server specified them, the default value will be used. If a client sends a value not in the allowed options, the server will NAK it, with the NAK having the allowed values in it.

The ACK will contain the final value of the capability negotiated for the client.

CAP LIST will display the caps with the value that has been negotiated.

C: CAP LS 302
S: CAP * LS :userhost-in-names draft/line-length=512..2048:512 draft/language=en_US,es_ES,ro_RO:en_US
C: CAP REQ :userhost-in-names draft/line-length=1024 draft/language
S: CAP * ACK :userhost-in-names draft/line-length=1024 draft/language=en_US
C: CAP REQ :draft/language=en_UK multi-prefix
S: CAP * NAK :draft/language=en_US,es_ES,ro_RO:en_US multi-prefix
C: CAP END
[client registers]
C: CAP LIST
S: CAP nick LIST :userhost-in-names draft/line-length=1024 draft/language=en_US

The usecases I can see now are the two in the example, as well as more granular negotiation of message-tags and/or batch types.

jwheare commented 4 years ago

Interesting, but is there a reason this needs to be a version bump? Can't this just be used for specific caps that need it?

emersonveenstra commented 4 years ago

It's going to depend on how clients handle value lists in version 3.2, e.g. if they would interpret draft/language=en_US,es_ES,ro_RO:en_US as having values of en_US, es_ES, and ro_RO:en_US, or sasl=PLAIN,EXTERNAL:PLAIN being interpreted as having PLAIN and EXTERNAL:PLAIN. Might be something to look at how specific clients handle it

jwheare commented 4 years ago

Oh if you want to change it for existing CAPs maybe, but are there any examples where that's actually useful. AFAIK PLAIN is already the default for sasl.

jwheare commented 4 years ago

To be clear, "value lists" aren't a thing in the protocol, they are defined per CAP.

emersonveenstra commented 4 years ago

Oh if you want to change it for existing CAPs maybe, but are there any examples where that's actually useful. AFAIK PLAIN is already the default for sasl.

I don't have any examples, I was erring on the side of caution in case there were and I didn't know about it.

To be clear, "value lists" aren't a thing in the protocol, they are defined per CAP.

Ah, I see that now. That might be more of a breaking change, since it wouldn't be able to be a free-form value with this, they would all need to conform to the syntax specified above so clients can parse them. Or do you think that wouldn't require a version bump either?

SadieCat commented 4 years ago

PLAIN is already the default for sasl.

In client interfaces maybe but theres no default mechanism defined for SASL afaik (and I don't think we need one).

jwheare commented 4 years ago

If you only apply this rule to new/draft CAPs, there's no need for a version bump to LS. If you want to retroactively use this on existing ones, then you would, but I don't see a need for it.

emersonveenstra commented 4 years ago

If you only apply this rule to new/draft CAPs, there's no need for a version bump to LS. If you want to retroactively use this on existing ones, then you would, but I don't see a need for it.

Agreed, I'll edit it