Clients should send unknown commands to server by default about ircv3-specifications HOT 11 CLOSED

I don't know why clients would not forward commands that they don't process themselves anyways. It would be interesting to hear some insight on why some client authors made such a decision.

from ircv3-specifications.

In the case of Pidgin I think it's a technical limitation (NOTE: Pidgin is an IM client not an IRC client).

from ircv3-specifications.

I don't know why clients would not forward commands that they don't process themselves anyways. It would be interesting to hear some insight on why some client authors made such a decision.

@flashcode from weechat/weechat#242 (comment) :

There is certainly not security issue by not sending unknown commands. I would even say that the security issue would be to send them: that would mean if you mispell any WeeChat command on a channel, it would be sent to the server, which is bad IMHO.

from ircv3-specifications.

Is it really necessary to enforce this? Most clients already do this and for most clients that don't it's not too hard to set up...

from ircv3-specifications.

Is it really necessary to enforce this? Most clients already do this and for most clients that don't it's not too hard to set up...

Most of users don't know how to do this and it's tiring to always explain how to set up with one specific client.

IRC is currently talking about ISUPPORT token, but that seems difficult.

from ircv3-specifications.

Fair point. Alright.

from ircv3-specifications.

IMO this is out of scope for IRCv3; It's not a protocol issue.

from ircv3-specifications.

I don't know why clients would not forward commands that they don't process themselves anyways. It would be interesting to hear some insight on why some client authors made such a decision.

Instantbird/Thunderbird do not do this, and I'm unsure how much work it would be to add this. It is not clear to me why you'd want to do this though. There's probably a few reasons we don't support this:

1. We (attempt to) preprocess commands before they're sent, e.g. /mode +X foo would get send as MODE #currentChannel +X foo, while /mode #foo +X bar would get sent as MODE #foo +X bar.
2. We provide syntax help messages for supported commands. (And tab completion of commands.)
3. We have local commands that influence the state of the running program and shouldn't be sent to the server, e.g. the /help command, the /about command to open the advanced configuration window, etc. I guess you could check the list of supported commands first and then send it, but I feel like that could lead to surprising results, sometimes (or leakage of information).

Much more user friendly, IMO. We do provide a command (/quote) that allows a user to send raw commands to the server. I believe that this handles the WeeChat concerns above (i.e. you explicitly choose to send commands to the server).

(NOTE: Pidgin is an IM client not an IRC client)

This shouldn't make any difference, I could turn this around and say "an IRC client is an IM client"...

Regardless, this seems entirely about client UI design: totally out of the purview of protocol design.

from ircv3-specifications.

Out of scope for IRCv3. Clients are not even required to have commands to begin with.

from ircv3-specifications.

This PR proposes a feature that is not a protocol issue but the current implementations of that said feature varies from client to client because there is a protocol issue hidden in it.

Smuxi used to send unknown/unhandled commands to the IRCd as IRC command. I had to revert this behavior when scripting support was added to Smuxi to write your own commands (in a shellscript or whatever as it is language agnostic). The problem is processing the user command and decide if control should be passed to a) the IRCd b) scripts. I initially wanted to let the IRCd first process the command and if that fails continue with a scripted command. Here comes the catch of the IRC protocol, there is no reliable and generic way to tell if a command was processed or not.

from ircv3-specifications.

#112 is the ISUPPORT thing which was proposed on IRC as better way to do this. It also has the logs.

from ircv3-specifications.