User Modes ISUPPORT Parameter

[andymandias]

It would be useful to have a USERMODES parameter (similar to the existing CHANMODES parameter) in order to provide users with immediate feedback on whether their MODE messages are valid. That would potentially cut out a send and reply from the command verification process. Since user modes are always type D (according to horse docs), the parameter could be a simple list of all available user modes.

I believe the list of available user modes in RPL_MYINFO cannot be relied upon for this purpose, since there is no mechanism for updating that information if it becomes out of date. E.g. if connecting to a bouncer and the initial list sent in RPL_MYINFO is a placeholder since the upstream network has not yet been selected, then there is no established mechanism for sending the upstream network's user modes once it has been selected.

[ValwareIRC]

What sort of use-case do you have in mind for the need to validate if usermodes exist? I think CHANMODES is mainly to show the expected syntax of the MODE by its group, and I know there can be things like channel desync's if you changed the existing channel modes on the server after the client has connected if it didn't re-issue the respective ISUPPORT tokens, but I can't think what validity checking you'd need for usermodes? I'd assume if the server is setting a mode on you then it's valid and exists, no?

[SadieCat]

InspIRCd already sends USERMODES in this way because we have some user modes that take parameters. I think some clients already parse it but I can't remember which (possibly Kiwi?).

https://github.com/inspircd/inspircd/blob/816c0d1f0c86fed4e9461c01e56d04950433a13c/src/coremods/core_mode.cpp#L390

[progval]

While this is redundant with named-modes I think it's worth adding this token because the token is a quick win, while the named-modes spec can be tough to implement.

[andymandias]

What sort of use-case do you have in mind for the need to validate if usermodes exist?

The use case I had in mind is validating a user's /mode command pre-send. E.g. if the user has forgotten the mode letter for the mode they want to (un)set and enters a user mode that is not available, then we can notify them. One could always send the MODE message and have the server validate the message (or not) by its reply, and one could reasonably prefer that method, but I find the shorter the feedback loop the better the user experience.

Having the list of available user modes also means we could present them to the user, if they request it, to help them remember what user mode(s) they're looking for.

That InspIRCd has user modes that are not take parameters, which I wasn't previously aware of, means it would have utility beyond what I originally had in mind.