ircv3-specifications
ircv3-specifications copied to clipboard
ircv3
autocomplete client tags
These are two new client tags, to allow autocompletion of bot commands.
It's not yet implemented and some parts are not written yet, but I'd like your opinions on this
From out-of-band discussion about how this should interact with transient / no-store TAGMSG (context on https://github.com/ircv3/ircv3-ideas/issues/68), a suggestion:
- Make
!the transient tag prefix - Accordingly, rename the draft versions of these tags
+!draft/autocomplete-requestand+!draft/autocomplete-reply, and the final versions+!autocomplete-requestand+!autocomplete-reply
An alternative suggestion was to make all TAGMSG transient by default, and add a new tag that can be attached to messages that should be stored. I weakly prefer using a prefix, but I'm very open to being convinced otherwise.
I wrote a quick implementation of this as a Limnoria plugin; if client devs want to try it, I have a bot on testnet.oragono.io named Limnoria (and also in channel #limnoria) so you can send commands like @+draft/autocomplete-request=whoa TAGMSG limnoria
I think to build a useful client implementation of this, I'd need to have a way to know that a nick is a bot that accepts commands, with what prefix, and that it can respond to autocomplete requests. Is that something you imagine being solved by metadata?
In private, it shouldn't be an issue to always send a request.
In channels, it remains to be decided. I see three options:
-
always send autocomplete requests to channels when pressing TAB doesn't have a match in the nick list (cons: potentially spammy + privacy issues?)
-
assume bots accept the same commands as
PRIVMSG #channel :botnick: commandandPRIVMSG botnick :command, so the client can send autocomplete requests in private even when typing a message in a channel. (cons: this is not true for all bots (eg. eggdrop) + you can't use short prefixes like!or@) -
using channel metadata (cons: more complex + depends on a pending spec)
It's still not clear how a client can detect whether a private message is to a bot at all, and the privacy implications of that are a non-starter for me.
In private they don't need to detect the message is to a bot, they can send completion requests systematically
Right, sending auto completion requests to every user that I have a private message conversation with is a privacy non-starter.
In terms of detecting a bot at all, Insp has the BOT=<modechar> isupport token which, when enabled, adds a B to the WHO flags of the user: https://github.com/inspircd/inspircd/commit/31815edd6a6b98434bace5359234d2b47397ee0a , we've implemented this as well in https://github.com/oragono/oragono/pull/1117 . I'm not sure whether any other servers implement this or if Insp came up with it though.
@jwheare I get there are privacy issues, but how is it different to send completion requests to "anyone" vs "anyone who says they are a bot"?
For sure, there is an added risk of spoofing/intercepting. That's not an argument in favour of just spamming it to everyone though.
Maybe the solution from a client-implementation perspective is to require quite explicit user interaction to activate this thing.
Yes, indeed, that sounds like the right solution in PMs.
As an alternative to metadata, what about making bots send a tag to say "hey I am a bot, please offer the autocompletion dialog"? (similarly to what OTR does with its magic whitespaces)
Hmm forget it, that's an ugly hack.
@DanielOaks That sounds like a good idea. IIRC, Unreal has a +B mode too, and makes it visible in whois (335, RPL_WHOISBOT). So if we combine both, it would work for channels (via WHOX) and PMs (via WHOIS)
It looks like Unreal, Insp, and us all do the BOT isupport token, and then expose it with RPL_WHOISBOT and in the WHO flags, so yeah. We should probably write it as a spec if nobody else has already.
I think I'm going to pass on implementation support for this as it stands. We can add this back to the roadmap if support picks up from other devs.