Have commands supported by server in ISUPPORT and send those to server automatically

[Mikaela]

What was talked about #111 at IRC.

Someone else can probably also explain this issue better. Have something in ISUPPORT to list the commands that the server supports and their syntax, so clients can know that server supports those commands and send those commands to server directly without /quote. Primarily /nickserv etc.

[Mikaela]

NOTE: I still think that client command should take priority over server commands. E.g. /set, /connect...

[Mikaela]

Commands that come available as you oper/deoper? Could cap-notify be used here?

[clokep]

Commands that come available as you oper/deoper? Could cap-notify be used here?

Isn't some of this specific to the mode of the channel?

I'm a bit confused by this: I see a proposed solution, but I'm unsure of the problem being solved by it. Could you elaborate on why this is helpful?

so clients can know that server supports those commands and send those commands to server directly without /quote

But clients don't use /quote, users use /quote, so we'd have to display this list or something to the user? (Sure, this is a UI issue, but still...I don't see a reasonable way to even use this information if it was sent by the server. I'd just drop it on the floor.)

[kythyria]

The proposal I wrote was specifically because I was annoyed there was no automatic way to have a button for /znc detach <channel> show up next to /part <channel> in the GUI of a client.

[Mikaela]

I see a proposed solution, but I'm unsure of the problem being solved by it.

The probem is that there are many server side aliases, usually for services like /ns, /nickserv etc. that check that the target of command is U-lined to prevent passwords being sent to malicious user who is /nicked to NickServ (server misconfigurations allowing this happen everywheere) and can get passwords. There are also those networks that have their own commands that don't exist elsewhere for example to request a bouncer account.

The problem with #111 is that when you typo a command including password, that is sent to server and this was suggested as alternative olution.

[clokep]

The proposal I wrote was specifically because I was annoyed there was no automatic way to have a button for /znc detach <channel> show up next to /part <channel> in the GUI of a client.

That seems useful! I guess my issue with these discussion is the tying it to how the client is supposed to use the information. Thanks for the example. 👍

[Mikaela]

The example that started this is client not having /nickserv command, but server supporting it and having way from server to communicate to client that it should send /nickserv to server.

[Mikaela]

Possible another way?: Only have the server inform clients about unstandard commands like server side aliases and those that aren't in RFC or IRCv3.

[kaniini]

Unreal already has the CMDS isupport token for that. We could just use that.

Authentication and registration of accounts, however, should have a standardized interface outside of CMDS.

[SadieCat]

👎 for using ISUPPORT from me. We (InspIRCd) have far too many commands to ever fit into ISUPPORT. 👍 on the general idea of informing clients about available commands though.

[Heufneutje]

How about a command that lists all of them, and advertising that in ISUPPORT?

[kythyria]

@Heufneutje something like ISUPPORT containing CMDLIST=9af6b2, where the value is a hash or sequence number or something else that changes when the response to CMDLIST would, with the latter provoking a list of commands?

A while ago I thought of a command description format which l'm not entirely sure is quite right (note that it's meant more to provide hints for GUIs, not so much to replace a HELP verb).

[grawity]

We (InspIRCd) have far too many commands to ever fit into ISUPPORT.

So send them in two lines. Or three.

[robotoad]

@kythyria A client that performs input autocompletion and/or displays documentation in the user's language would need a complete localized syntax description and localized help text. Additionally, protocol-level commands may not always be suitable for users, who are often presented a set of commands with slightly different behavior and syntax (e.g., /part might assume the name of the active channel if one isn't provided).

The actual issue isn't commands but services which have commands associated with them. Those services are what should be advertised, and the client can support them according to their documentation, including any described commands.

[attilamolnar]

So send them in two lines. Or three.

You cannot send one token multiple times (you can but it has a different effect than what you have on mind).

[kythyria]

Those services are what should be advertised, and the client can support them according to their documentation, including any described commands.

What we're discussing is a way to transmit that documentation, in a format that clients can actually decode. If you just advertise the service... that doesn't actually help, since this is about commands which the client doesn't know ANYTHING about. It would be fairly easy to add a DETACH token to ISUPPORT, or CHANSERV=CS but that would do nothing to actually help the client do anything with it. Maybe

:server.example.org 005 CMDDOC=http://example.org/irccommands

and retrieving that URI gives some XML version of my proposal. Or JSON, whatever.

Something like this (this is more or less off-the-cuff; I don't know how to cleanly represent all of chanserv in that:

<commandlist xmlns="http://ircv3.org/extensions/commandlist.html">
  <command uicontext="channel-menu">
    <displayname xml:lang="en">Detach</displayname>
    <doc xml:lang="en">
      Detach from the channel: Send a PART to connected clients, but don't
      actually leave the channel, instead buffering messages
    </doc>
    <verb>ZNC</verb>
    <paramlist>
      <param type="fixed"><text>detach</text></param>
      <param type="channel" auto-source="thischannel">
        <name xml:lang="en">Channel</name>
      </param>
    </paramlist>
  </command>
</commandlist>

Anything with xml:lang on it is human-readable text, and may be present multiple times for different language versions (in theory, Accept-Language headers could be used for this, but that assumes a client and httpd that can use the header properly).

e.g., /part might assume the name of the active channel if one isn't provided

My proposal covered that: the context parameter and :c affix in the inline one, and the uicontext and auto-source attributes in the XML above, are to allow the client to a) present the command in the appropriate place in a GUI (eg, uicontext='channel-menu' for a contextual menu associated with a single channel or user-channel for the name sidebar), and b) automatically do that sort of figuring out if the user enters it into the input line.

[grawity]

So, there are two distinct problems here:

1. Some clients refuse to pass through unknown commands (requiring e.g. dispatch.pl). The usual arguments are tab-completion for command names, not sending mistyped commands, "you can just alias to /quote FOO".

   This would be solved by a simple list of supported commands, such as CMDS=DETACH,ZNC; either a) sent automatically as part of ISUPPORT [the spec doesn't seem to forbid repeating the same CMDS= across multiple lines] or b) requested explicitly using CMDS or COMMANDS. [Can a command be non-alphanumeric, e.g. CMDS? to query a list?]

2. Some clients have fancy context menus for channels and users, and want to integrate e.g. ZNC features into those menus.

   This needs something more extensive, like @kythyria's XML above. (Though I'm not sure if using a side HTTP channel is a good idea – for several reasons.)

I think one of the above should be split off to a separate issue.

[robotoad]

What we're discussing is a way to transmit that documentation, in a format that clients can actually decode. If you just advertise the service... that doesn't actually help, since this is about commands which the client doesn't know ANYTHING about. It would be fairly easy to add a DETACH token to ISUPPORT, or CHANSERV=CS but that would do nothing to actually help the client do anything with it.

Well, this is how CMDS acts today. Clients refer to published documentation for USERIP, KNOCK, and so on for implementation. I'm not convinced the server should be sending user input parsing instructions. It's simpler to advertise a feature set and expect the client developer to refer to externally published documentation to implement support according to the needs of that particular client. This is a process the server should really take no part in, nor could it do so while addressing all possible use cases.

Anything with xml:lang on it is human-readable text, and may be present multiple times for different language versions (in theory, Accept-Language headers could be used for this, but that assumes a client and httpd that can use the header properly).

I think localization of interface elements should be none of the server's concern.

My proposal covered that: the context parameter and :c affix in the inline one, and the uicontext and auto-source attributes in the XML above, are to allow the client to a) present the command in the appropriate place in a GUI (eg, uicontext='channel-menu' for a contextual menu associated with a single channel or user-channel for the name sidebar), and b) automatically do that sort of figuring out if the user enters it into the input line.

I'm not on board with involving the server in a client's interface or the behavior of its user input parser. It seems like a shifting of responsibilities, turning the client into a dumb terminal in which the server is dictating user interaction.

[grawity]

I'm not on board with involving the server in either a client's interface or the behavior of its user input parser. It seems like a shifting of responsibilities, turning the client into a dumb terminal in which the server is dictating user interaction.

Given how many custom modes and commands various servers already have, I'd say that ship has long sailed; many things are done through /quote and /mode where the client just provides the input line. (And that, IMHO, is one of the largest failures of IRC.)

If anything, it would be better if the server could teach the client how to properly present its features instead of having to a) hardcode them based on server type or b) point the user at web docs or HELPOP.

It's a bit sad that almost no existing clients even provide easy management for custom listmodes (which have been announced in ISUPPORT for decades).

[robotoad]

Given how many custom modes and commands various servers already have, I'd say that ship has long sailed; many things are done through /quote and /mode where the client just provides the input line.

Lack of standardization between networks is a problem, but surely the solution isn't dynamically constructing an input parser over the wire. Proper documentation and advertisement of feature sets that clients can adopt modularly is the better answer, in my opinion.

[dwfreed]

[Can a command be non-alphanumeric, e.g. CMDS? to query a list?]

Negative; RFC1459 limits the command token of a line to either a sequence of letters or 3 numbers, no symbols or the like are allowed.

[kythyria]

@robotoad So you're basically proposing that if I write a new module for ZNC, for instance, I have to at minimum configure aliases on every single client if they support that at all, and more likely actually modify said clients. Or if I'm a server developer or network operator and add a new function or alias, I have to get every single client my users use to be changed before they can even recognise the command exists, something that may not be possible given that the command may be quite niche.

IRC clients never had a tremendous amount of logic in them. Besides, I meant this as hints rather than a MUST, and you're proposing we solve the problem... by not solving it at all. Requiring clients to hardcode support for each and every command is the current thing, and it's not working, else this issue wouldn't exist.

We aren't proposing anyone change their parser. I don't know where you got that from, since it's a really dumb idea. What I was proposing is a way to indicate what parts of each nonstandard command can come from context, at the same time as where to add this to a GUI, if anywhere.

@grawity You left out /msg: There are STILL networks that don't support /ns or /nickserv, for instance.

But yes. I only came up with the XML to add localised human-readable stuff to it; I'd much rather do it in-band (if this was XMPP, that would be in-band if there weren't already ways of doing this sort of thing). An in-band format is much nicer.

[Mikaela]

In addition to ZNC-specific commands, ZNC also has alias module that allows defining custom commans on ZNC level that again are server side commands to whichever client is attached.

Sorry, I forgot to say this earlier and I think this is important to know in this issue.

[DarthGandalf]

Server-side aliases are not specific to ZNC...

2015-02-21 13:21 GMT-08:00 Mikaela Suomalainen notifications@github.com:

In addition to ZNC-specific commands, ZNC also has alias
http://wiki.znc.in/Alias module that allows defining custom commans on
ZNC level that again are server side commands to whichever client is
attached.

Sorry, I forgot to say this earlier and I think this is important to know
in this issue.

—
Reply to this email directly or view it on GitHub
#112 (comment)
.

[robotoad]

@kythyria

We aren't proposing anyone change their parser. I don't know where you got that from, since it's a really dumb idea. What I was proposing is a way to indicate what parts of each nonstandard command can come from context, at the same time as where to add this to a GUI, if anywhere.

Unless I've misunderstood, what I see proposed is server-dictated client interfaces, specifically user input processing and GUI placement. I don't agree with intervening in client interface design, and I doubt it would see support from client developers.

[SadieCat]

Proper documentation and advertisement of feature sets that clients can adopt modularly is the better answer, in my opinion.

That is not something which is ever going to be feasible. Not when servers can define arbitrary commands.

Unless I've misunderstood, what I see proposed is server-dictated client interfaces, specifically user input processing and GUI layout.

Nobody is saying that clients should be rigidly forced to follow the servers instructions. A client could use the information in @kythyria's proposal however they want.

[kythyria]

@SaberUK Exactly. The sort of hints I intended are things like "this command is related to joined channels" (MODE +m PRIVMSG, PART), "this command is related to a user in a channel" (MODE +v, KICK), "this command is related to a user anywhere" (WHOIS, WATCH+), and so on.

Where, if anywhere, a client puts commands in its GUI is unspecified, other than "near built-in ones that have the same hint". In fact, my original motivation was to allow parameters to be implied when a command is typed, the way the first parameter of PART usually is.

[kaniini]

Please use something less heavy than XML for this.

[robotoad]

That is not something which is ever going to be feasible. Not when servers can define arbitrary commands.

In my opinion, the existing client capability system is the appropriate solution for network extensions that introduce new message types. Relationships between commands as well as recommendations for presentation should be codified in a specification.

Nobody is saying that clients should be rigidly forced to follow the servers instructions. A client could use the information in @kythyria's proposal however they want.

If the client is free to ignore most of the information and instead enable custom functionality for certain commands, then we're back to KNOCK, CNOTICE, CMDS, and so on.

It's incorrect to conflate protocol-level message commands and user input commands, for reasons previously stated. This proposal appears to be rooted in concern over clients' handling of unrecognized user input. As a fallback, a client could check an unrecognized command name against CMDS and forward the raw input if a match is found.

[SadieCat]

In my opinion, the existing client capability system is the appropriate solution for network extensions that introduce new message types. Relationships between commands as well as recommendations for presentation should be codified in a specification.

It's incorrect to conflate protocol-level message commands and user input commands, for reasons previously stated.

How do you propose writing a specification to handle the fact that every major server implementation allows users to define arbitrary aliases which is a feature which is widely used by basically every single IRC network?

As a fallback, a client could check an unrecognized command name against CMDS and forward the raw input if a match is found.

As previously mentioned, ISUPPORT is not nearly big enough to fit all server commands into. There is nothing in the ISUPPORT spec (or in existing implementations) that allows a single token to be split across lines if it does not fit into a single 512 character message and if you are going to define a new message you may as well include information about how the parameters are formatted to to allow clients to give hints to the user about how to input the command.

[HelixSpiral]

I think they meant using multiple ISUPPORTs to send all the tokens, not to split a single token across multiple ISUPPORTs.

[SadieCat]

@shawn-smith I don't think that is feasible considering you either have a set amount of tokens (in which case there wouldn't be enough when you run out) or you have to define a method of guessing the next token e.g. TOK1,TOK2,TOK3 which would require special ISUPPORT parsing and you may as well just define a new message for it.

[kythyria]

@SaberUK Like in #114? (it's a somewhat cleaned up version of my gist from some time ago)

[robotoad]

@SaberUK

How do you propose writing a specification to handle the fact that every major server implementation allows users to define arbitrary aliases which is a feature which is widely used by basically every single IRC network?

Correct me if I'm not understanding your question; I don't see a problem with a network specifying a vendor-specific extension for its unique message types.

As previously mentioned, ISUPPORT is not nearly big enough to fit all server commands into. There is nothing in the ISUPPORT spec (or in existing implementations) that allows a single token to be split across lines if it does not fit into a single 512 character message and if you are going to define a new message you may as well include information about how the parameters are formatted to to allow clients to give hints to the user about how to input the command.

How will the hints be localized? What if a client has no user commands? Why the conflation of protocol messages and client text commands?

[jwheare]

Closing due to lack of support for proposal in #114

[MaxLeiter]

Mentioned on IRC, 👍 for me on this. Would love discussion to re-open. Can massively improve client capabilities (like adding autocomplete for non-spec commands)