Add named-modes specification

[progval]

This is a spec that has been in the making for a while, and it's finally ready for review.

It is inspired by InspIRCd's namedmode module, though they are unfortunately not compatible.

In terms of implementation, I wrote a proof-of-concept as a third-party InspIRCd 4 module that I hope to productionize when this draft is accepted.

Finally, as this is a pretty complicated spec, please avoid sending copyediting comments right away, this is probably going to be a very long thread with many changes.

rendered view

[progval]

A possible change: currently, the RPL_LISTPROPLIST syntax is like this:

RPL_LISTPROPLIST <nick> <channel> <modename> <mask> [<setter> <settime>]

to mirror the existing behavior, and to make it easier to handle optional parameters.

However, if we change it to this:

RPL_LISTPROPLIST <nick> <channel> <modename> [<setter> <settime>] <mask>

It would allow spaces in the mask, as it is always the trailing parameter

I don't want to do allow spaces in this spec (to make it easy to convert to MODE), but we may want to change this order so that we can easily allow spaces later in a new spec.

What do you think?

[slingamn]

Any thoughts on requiring that servers MUST translate MODE to PROP for clients that have enabled the capability? This opens up the possibility of future greenfield clients that don't know about MODE at all.

[progval]

@slingamn maybe a separate cap to allow gradual upgrades?

[progval]

On second thought, nevermind. We don't need one more moving part.

[slingamn]

Here's an edgy take: I think we should preemptively make this specification syntactically tolerant of spaces in mode parameters. (They can still be semantically disallowed, especially for named modes that are the equivalent of an RFC1459 mode.)

"Non-final parameters" are an ever-flowing wellspring of correctness issues. The backwards compatibility issues don't seem too bad: since the MODE parameters to +k and +b can already be sent by clients as IRC final parameters, server implementations already need to validate them to ensure that they don't contain spaces.

@emersion might have been joking but at one point he suggested using the tag value escaping syntax for this. What if we required all mode parameters --- in RPL_PROPLIST, RPL_LISTPROPLIST, and PROP --- to be tag-value-escaped?

[grawity]

@emersion might have been joking but at one point he suggested using the tag value escaping syntax for this. What if we required all mode parameters --- in RPL_PROPLIST, RPL_LISTPROPLIST, and PROP --- to be tag-value-escaped?

Sounds like an interesting idea. I would actually like the entire wire protocol to move towards something like that, leaving the :trailing wart in history.

[progval]

What about a single PROP change per line, so we can always use the space character instead? It can simplify implementations on both ends and doesn't have much of an overhead

[slingamn]

I don't have strong feelings about this but it seems suboptimal.

I feel like everyone who would implement this has ready access to a tag-value (un)escaping implementation, no?

[progval]

It mostly just "feels wrong" to me. But why not. It may not be usable as-is everywhere though; as current implementations can assume serialized values don't contain ;, but that's a minor change to make.

Though I also like "single PROP change per line" because it simplifies implementations on both ends.

No strong opinion either way.

[ValwareIRC]

Maybe bit silly request, any chance to make this use hyphen-delimited names on things that might contain spaces? Only rationale here is being able to easily automate a human-readable name from it by uppercasing the first char of each hyphen-delimited token, replacing the hyphens with spaces and (in my case) moving any vendor prefix to a badge

// Would be nice
"no-color" => "No Color"
"invite-only" => "Invite Only"

// Current when trying
"nocolor" => "Nocolor"
"inviteonly" => "Inviteonly"

It's only a little extra UI work to automatically recognize and display human readable for standardized named-modes, but thought it'd be nice and less work in the future if more things ever got standardized

Has the potential to get a little out of hand with like no-external-messages but I don't mind long mode names like that. Thoughts?

[progval]

That only works for English-only clients, though.

[ValwareIRC]

That only works for English-only clients, though.

This is very true... Still fine for clients with client-side automatic translation of things