ircv3-specifications
ircv3-specifications copied to clipboard
ircv3
Add extended-isupport
Rather than adding more numerics can we just require that it gets batched?
Yeah, that would be a cleaner solution. I wonder if this would be hard for older servers to implement?
Could you mention that:
- as before, ISUPPORT messages are additive (ie. if a new ISUPPORT overwrites or adds values, but the absence of a value does not mean it's not present anymore)
- specify the
-prefix to remove a key? I don't think this existed prior to this spec.
as before, ISUPPORT messages are additive (ie. if a new ISUPPORT overwrites or adds values, but the absence of a value does not mean it's not present anymore)
Not sure how to phrase this. Maybe:
As usual, servers can update or delete existing values by sending additional
RPL_ISUPPORTmessages in adraft/isupportbatch after the initial batch.
But maybe you want something more precise?
specify the - prefix to remove a key? I don't think this existed prior to this spec.
It's in modern: https://modern.ircdocs.horse/#rplisupport-005
specify the - prefix to remove a key? I don't think this existed prior to this spec.
It's in modern: https://modern.ircdocs.horse/#rplisupport-005
Also worth noting that Modern gets it from from the original IETF draft isupport specs.
Changes look good. No need to force push updates, makes it a bit harder to review. I squash commits on merge anyway.
Alternatively, instead of spec'ing that servers must send the ISUPPORT list when the cap is enabled, we could guarantee that VERSION works pre-reg and recommend that clients send it after enabling the cap.
I would be slightly more comfortable with allowing VERSION pre-registration --- the "edge-triggered" API has always bothered me a little (on the other hand, I haven't been able to identify any concrete problems with it).
VERSION has a wrinkle where you also get RPL_VERSION, so presumably you would get RPL_VERSION outside the batch and then a batch of RPL_ISUPPORT? We could add a command like ISUPPORT that just sends the RPL_ISUPPORT.
Just specifying an ISUPPORT command that can work pre-reg works for me. Regarding batch, I feel like this was already discussed, but what use case does batch enable? My implementation just incrementally updates the ISUPPORT list whenever an 005 is received, I don't have a need for an end of isupport marker.
@jwheare there is a note on this here: https://github.com/ircv3/ircv3-ideas/issues/124#issuecomment-2130183063
tl;dr it allows the UI to be updated atomically, reducing "flicker".
Ok so maybe define the ISUPPORT command to require use of a batch if the cap is enabled? But leave the existing automatic isupport sent post reg unbatched. Would that work?
That wouldn't work if the server wants to send an atomic update of more than 13 tokens.
A new ISUPPORT command has been introduced, and the RPL_ISUPPORT list is no longer sent when the capability is enabled.
Looks good, I merged support for this in ergo and deployed it on my staging server ircs://files.stronghold.network
I've finally got some time to implement this in Goguma! Here's the patch: https://codeberg.org/emersion/goguma/pulls/2
Ergo's implementation seems to have a small bug: there is an extraneous chathistory param in the batch parameters.
flutter: [3] <- :files.stronghold.network BATCH +1 chathistory draft/extended-isupport
flutter: [3] <- @batch=1 :files.stronghold.network 005 * AWAYLEN=500 BOT=B CASEMAPPING=ascii CHANLIMIT=#:100 CHANMODES=Ibe,k,fl,CEMRUimnstu CHANNELLEN=64 CHANTYPES=# CHATHISTORY=100 ELIST=U EXCEPTS EXTBAN=,m FORWARD=f INVEX :are supported by this server
flutter: [3] <- @batch=1 :files.stronghold.network 005 * KICKLEN=1000 MAXLIST=beI:60 MAXTARGETS=4 MODES MONITOR=100 MSGREFTYPES=msgid,timestamp NETWORK=OraStage NICKLEN=32 PREFIX=(qaohv)~&@%+ STATUSMSG=~&@%+ TARGMAX=NAMES:1,LIST:1,KICK:,WHOIS:1,USERHOST:10,PRIVMSG:4,TAGMSG:4,NOTICE:4,MONITOR:100 TOPICLEN=1000 UTF8MAPPING=rfc8265 :are supported by this server
flutter: [3] <- @batch=1 :files.stronghold.network 005 * UTF8ONLY WHOX draft/CHATHISTORY=100 :are supported by this server
flutter: [3] <- :files.stronghold.network BATCH -1
With a small workaround for the broken batch type, it seems to work fine:
Sorry about that. I fixed it in https://github.com/ergochat/ergo/pull/2197 and redeployed.
Fine to merge this as is, but would the non draft cap name be more self explanatory as prereg-isupport? The format is not being extended by this afaict.
The name "extended-isupport" was picked because the cap also introduces a new batch and a new command. I'm fine using any other name if you prefer.
early-isupport was also suggested by @SadieCat to avoid the potentially confusing "registration" term being used. Anyway, no need to change the draft cap, but merged version should be. Hopefully someone remembers when the time comes!