Named Modes

[Alexendoo]

Currently configuring a channel as a user is not the easiest experience:

• Different ircds have different commands to display the help for modes, sometimes they conflict with the client /help command
• Mode lines are hard to disambiguate by eye
• There are varying implementations of services

It would be nice to have a mechanism to allow clients to display a window/buffer that has all the configuration in one place without requiring networks to standardise around a specific configuration layout.

An OPTIONS command could fulfil this role, the reply could contain enough information to build either a full settings GUI, drive command autocomplete or something in-between.

A minimum implementation may have option names paired up with a description and basic type (whether it takes an argument, if it's a list). A more complicated spec could allow things like sections, complicated inputs (like access rules) and more specific field types (radio buttons, checkboxes, etc).

I'd love to hear some thoughts on this, it seems there's a pretty wide scope it could sit in

---

Other specs

The key difference to existing proposals is that OPTIONS are effectively opaque to the client, they should only be used to create some form of display for the user.

Metadata

Metadata keys should be specified and listed in the registry, it's useful for things the client itself needs to access like avatars. In contrast the keys for OPTIONS are intentionally not specified, the client should not attempt to interpret their values beyond displaying it to the user.

Named Modes

Named modes covers a part of the goal, provided the names are reasonably consistent the client can use them to display help messages and the like. Uncommon modes might not be covered by the client however, whereas with OPTIONS the help text is included in the reply.

Another major difference is that OPTIONS can expose configuration beyond modes, such as services integration.

An example

To illustrate the general idea, here's a concrete scenario of OPTIONS in use, the syntax is for illustrative purposes only and may not be the best but bear with it.

Here the client requests the options list for the #ircv3 channel, additionally znc inserts its own settings into the reply

--> OPTIONS #ircv3 LIST
BATCH +outer options #ircv3 list
@batch=outer BATCH +section1 options #ircv3 section :Channel Modes
@batch=section1 OPTIONS #ircv3 LIST mode_n type=boolean value=true title=No\sExternal\sMessages :Only channel members may talk in the channel.
@batch=section1 OPTIONS #ircv3 LIST mode_L type=boolean value=false title=Free\sTarget :Anyone may be forwarded to the channel.
@batch=outer BATCH -section1
@batch=outer BATCH +section2 options #ircv3 section :Chanserv
@batch=section2 OPTIONS #ircv3 LIST chanserv_entry_msg type=text title=Entry\nMessage :A message sent to all users joining the channel.
@batch=outer BATCH -section2
@batch=outer BATCH +section3 options #ircv3 section :ZNC
@batch=section3 OPTIONS #ircv3 LIST znc/buffersize type=number value=50 title=Buffer\sSize :The buffer count.
@batch=outer BATCH -section3
BATCH -outer

The main reply of interest is roughly OPTIONS <target> LIST <key> [<param> [<param> ...]] <description> where params are keys with optional values using tag encoding

Here a key such as mode_n would be used only to inform the server of changes made by the user, the keys are opaque and would not required to be standardised across implementations.

The title param and description are for displaying to the user, as an example they may vary within a single server depending on the language of a user.

The type param is standardised and would be a hint to clients if they wish to choose a particular input field, numeric input uses a different soft keyboard on touchscreen devices for example. value is the current state of an option.

Nested batches are used to split the options into categories/sections.

Putting this all together, the client can display a screen like

Channel Modes

- [x] **No External Messages** Only channel members may talk in the channel. - [ ] **Free Target** Anyone may be forwarded to the channel.

Chanserv

- **Entry Message:** `________` A message sent to all users joining the channel.

ZNC

- **Buffer Size:** `50` The buffer count.

I spent way too long formatting this bit

Alternatives

Rather than a new command, this could be built on top of the metadata spec, it would need a few additions:

• Allowing extra keys that are not specified or part of a registry

  Aribtrary keys could be allowed as long as they follow a scheme such as vendor prefixing to prevent collisions in the future

• Attaching types, human readable names, descriptions and other such items to said keys

  A new subcommand could be added, such as METADATA DESCRIBE that functions similarly to the ideas described above

• Tying in modes somehow

[SadieCat]

We've been working on a solution for modes being extremely ambiguous: https://github.com/SaberUK/ircv3-specifications/blob/master+namedmodes/extensions/named-modes.md

[DanielOaks]

Named modes are good. Just a case of making sure that everyone actually uses the same names... and that names mean something consistent (e.g. BLOCK_COLORS shouldn't mean both block and strip colours, etc).

[dequis]

Can we change the title of this issue to PROP? Or "named modes". OPTIONS seems like a new thing but it's not really.

[Alexendoo]

I would say it's close to named modes but not quite the same.

Initially I had something similar to named modes but it didn't quite cover the use-case I was after, that is to produce a settings UI for a channel similar to weechat's iset/fset. Rather than standardising around common names the idea is to essentially provide a command to list/set configuration related to channels however it may currently exist.

Modes are a big part of this for sure but a good portion of channel configuration goes through something like chanserv.

[Alexendoo]

Additionally since it's arbitrary configuration, there are a few neat things that could happen like your bouncer could add its own section alongside the regular channel settings, or it having a complete in-client settings page if you target a certain name

[DanielOaks]

Hmm. I'm interested at seeing what this sort of idea could cover that wouldn't otherwise be covered by either named modes or server-confirmed metadata keys. Thanks for clarifying the idea, mind editing the initial post to cover this idea more explicitly?

Also, would this be an alternative to named-modes, or work alongside it, on your eyes?

[DanielOaks]

Thanks for the edit mate, I can take a read and rename this more appropriately in the morning

[Alexendoo]

Thanks. The new stuff is under the ------------. For how it would work alongside others I'm not totally sure of myself. I think merging it into metadata could be a pretty good idea having just written all that, but I'm not sure if it slightly conflicts with the original idea of having managed keys, there would still be modes to deal with also

[realJoshByrnes]

This sounds very similar to existing IRCX / IRC PROPs, possibly with the enhancement of forced BOOLEAN values. PROP #ircv3 MEMBERKEY :ThIsIsMySeCrEtKeY PROP #ircv3 NOEXTERN :True <-- Forced boolean, Is ON if not null. (or ON|OFF could be enforced)

[Alexendoo]

As I understand it PROP has the same problem as the current metadata proposal for this use case. It has a list of props listed in the spec, with no way to communicate the form/description of new ones to clients.

I think I'm going to close this and open a new thread more clearly indicating the desired use case rather than a suggested solution, as I didn't communicate this very well.

[DanielOaks]

For what it's worth, the Insp impl of this does use PROP as the command, not sure how closely it duplicates the IRCX syntax or whatever but feels fairly close. Appreciate it @Alexendoo, thanks :D