Wishlist: /botnotice command

[a-raccoon]

4.4.3 Bot Notices

      Command: BOTNOTICE
   Parameters: <channel> <nickname,s> :<text>

   The BOTNOTICE message is used similarly to NOTICE.  As with NOTICE,
   automatic replies must never be sent in response to a BOTNOTICE
   notice.  The difference between NOTICE and BOTNOTICE is the addition
   of a target parameter and how the NOTICE is received by the target
   client or clients.  The first parameter is the channel from which the
   NOTICE is to appear to have been sent to, and the second parameter is
   the actual target client (or clients) who should receive the NOTICE.

   Only clients with channel operator (+o) status may be able to send
   a BOTNOTICE command for a given channel.*  Whether the issuing client
   is a bona fide automaton or just a client user is unimportant to the
   function of this command.  The purpose is to permit bots and client
   scripts to interact with and address users in the context of a
   channel.  This allows client programs to know where to paint the
   notice text so it can appear in the channel window instead of a
   status or query window that the user isn't interacting with or
   currently paying attention to.

   **Many bots do not utilize NOTICE as they should (see: 4.4.2), because
   the authors of those bots know that standard NOTICEs tend to go
   unnoticed, and missed.**

   Examples:

   BOTNOTICE #Twilight_zone Angel :Welcome to the channel!
                           ; Message sent to Angel in #Twilight_zone

   :Wiz NOTICE #Twilight_zone :Welcome to the channel!
                           ; Message from Wiz to Angel in #Twilight_zone

   See PRIVMSG for more details on replies and examples.

   * Channel op status is not necessarily necessary, and the command can
   ideally be used by any helper bot or client script without being any
   more abusable than regular /notices or /msgs.  Client /ignore and
   /filter commands already silence channel-targeted notices when said
   user is placed on ignore.

[uplime]

How is this any different than NOTICE <nicks> :message? Where they are "painted" is completely up to the client. None of the clients I have ever used have even written notices to a status window (by default at least). It seems almost silly to make a command (a) breaks many current clients, and (b) is just for people too lazy to configure their client.

[Xenthys]

I won't debate about the idea itself, but about its implementation.
As said by @ntchambers it will break many current clients, as something like that must be implemented on both sides, not only on the IRCd. Unless that goes in a RFC (maybe submit it to the @IRCv3 workgroup), most clients wil never implement that just for freenode, even if it is a large network.
Or maybe I am wrong and you have an idea to have it already compatible and working as intended?

[grawity]

I don't see how it could break anything, assuming the server translates it to a regular NOTICE #chan but only routes to a specific user. It has been successfully implemented in other ircds this way, though usually with PRIVMSG (I think UnrealIRCd has a module for it).

Alternatively, the server could translate it into a NOTICE target but prefix the message with [#channel], since various clients already recognize ChanServ notices marked this way.

Though I'd like it to be @context=#channel NOTICE target ... instead, but that needs work – both in terms of ircd code and the obligatory ircv3 bikeshedding.

[Xenthys]

That effectively is a mean I did not think about. However, routing notices that appear as public to only one client can be a bit frowned upon, as clients will not be able to say if it really is a public NOTICE or if it is a BOTNOTICE, so it could be misleading.
For the alternative prefixed notice, we fall under a client compatibility that is not everywhere. I am currently using @HexChat and it does not seem to support it properly.

[jevolk]

@a-raccoon This is a great idea! It looks like we'll be implementing it in Charybdis as the command WHISPER as a reincarnation of the former ircx module (command aliases always available). This time there will be a CAP which allows the server to send the client the actual WHISPER command, falling back on NOTICE otherwise.

@grawity > Though I'd like it to be @context=#channel NOTICE target ... I'm not sure what that is but it's not IRC protocol! Let me suggest the following IRC alternative instead: CONTEXT #channel\r\nNOTICE target ...\r\nCONTEXT *\r\n

[grawity]

@jevolk: If it wasn't IRC protocol before, it is now. In fact the ircd you're working on was the first to implement support for this syntax.

[a-raccoon]

To address the first 2 comments, no, there is nothing that would break any clients or that would require clients to implement anything new. All clients already provide support for channel targeted notices, as grawity had pointed out. The client doesn't see any new commands or responders for /botnotice as this is basically an alias for existing NOTICE, much like /remove is an alias for existing PART.

To address the 4th comment, by Xenthys, yes, it could lead to ambiguous interpretation of channel-notices and possible confusion between whether all users received it or just one. People might not know whether they should boisterously complain to the channel about receiving channel notices, or not. :)

Xenthys: So, what if we used a pseudo-prefix to the channel name? Like @#foo and +#foo, but ?#foo to indicate it was sent privately with a channel context.

BOTNOTICE #Twilight_zone Angel :Welcome to the channel! -- sent by Wiz :Wiz NOTICE ?#Twilight_zone :Welcome to the channel! -- Received by Angel

The problem with implementing /whisper is that it's a whole new command for clients to have to interpret. And the clients that currently recognize WHISPERs display and treat them much like a CTCP ACTION or /me. The command was never intended for bot usage, and isn't as distinguished as NOTICE is, as a response to automation.

The reason I also wish to call it BOTNOTICE is psychological. It gives implicit intent, meaning and approval of use by bots for private bot responses to channel contexts. Eg, when somebody issues a !command in a channel, or when a game bot needs to address specific players directly.

<WolfBot> Welcome to another game of Werewolf!
<WolfBot> There is a wolf among us! Figure out who it is!
-WolfBot:?#werewolf- Angel, you are the WOLF!

[a-raccoon]

Does anybody have a test server that can be set up to issue ?#channel prefixed channel-target notices, so I can see which clients handle the unknown ? meta-prefix gracefully or not?

[Xenthys]

Using a pseudo-prefix is a solution, but as you said, we need clients to support it, that's why I talked about the @IRCv3 working group instead of just making a feature request for ircd-seven.
Besides that, as a guy who uses bots a lot, I recognise it would be handy, but here again it's all about CAP support, as a lot of bots will probably never use it and continue to send NOTICEs and/or PRIVMSGs.

[a-raccoon]

I don't understand why CAP need be involved. That's for a whole different subset of functionality. Worst case scenario, the ? prefix is implemented and is conveyed in 005 PREFIX=, or we implement without a pseudo-prefix, and simply re-purpose the #channel target notice as a #channel contextual notice. I prefer the latter of the two, since #channel targeted notices are very rarely used and in its current implementation are typically considered useless and abusive. A non-feature that should be (and often is) disabled because it has minuscule practicality and high incidence of abuse.

All IRCDs already prohibit non-ops from /notice @#channel, and non-voice from /notice +#channel, and /most/ simply prohibit regular users from sending a /notice #channel, either out of the box, or via ubiquitous channel mode. We should be able to safely re-use the output of a channel notice without much fuss and little education on the matter.

[grawity]

@Xenthys: Ah, it's mostly the receiving side that needs CAPs – or rather, the server needs them to know whether the recipient needs the message to be down-converted to a magic NOTICE, or if it can accept the new syntax directly. This is the same whether one uses tags or WHISPER. But for the sender (bot or client), CAP doesn't become mandatory...

I just noticed Twitch IRC also has a whisper command. Looks like their variant expects a magic PRIVMSG from the sender, but sends out a WHISPER to the recipient. (Kinda opposite of what I expected.)

[a-raccoon]

If CAP is used to alert on a non-standard ? prefix, then it's the fallback to no-prefix that I implore, so bot authors don't just dismiss this as something most client's don't support. Then we're back to square one, and abuse of PRIVMSG.

[a-raccoon]

Why CAP instead of 005 PREFIX=(ov)@+?

[grawity]

@a-raccoon: Because they're nearly opposite. 005 tells clients that the server supports something; CAP lets clients tell the server that they support something (and agree to use it).

It's STATUSMSG, not PREFIX, by the way.

[a-raccoon]

I was basing my comment on the pretense that all clients already support what I am asking for. Because they do. Just throw in a prefix symbol into STATUSMSG (ie `STATUSMSG=@+?), or use no prefix at all. Again... clients . already . support . BOTNOTICE. Because they already support channel targeted notices.

CAP literally cannot be used for this, because a client cannnot NOT support this.

[ghost]

Instead of a magic prefix, why not just make it a private notice like ChanServ's ENTRYMSG? WeeChat for example already shows private notices in the form [#channel] message in #channel, distinguished as a PvNotice. This would require more clients to support it, but you cannot rely on clients showing a regular channel notice in the channel either. Some default to showing it in the current window (mIRC), others in a random window where the sender is present (HexChat), and some others in the status window (Irssi, WeeChat).