Currently, there’s no real way to link commands sent to chat to the corresponding response. This is especially annoying in the case of commands that deal with specific users (e.g. /ban, /mod) and even though I could extract the name of the user out of the message for some NOTICE replies (which, by the way, have no username tag, which would already help to some extent) it’s still very problematic with Chinese/Japanese display names:
< PRIVMSG #satisfiedpear :/unban jptest_
> @msg-id=unban_success :tmi.twitch.tv NOTICE #satisfiedpear :たかかげ is no longer banned from this room.
There is no way to link the response to the command.
Now, a partial, easy solution could be - as I already mentioned - to add a username tag to the problematic NOTICEs.
A more complete solution of this problem (and probably many others too!) would be to implement IRCv3’s labeled-response extension.
It would enable clients to send a label tag which the server could then repeat in the corresponding reply. The same example from above would then look like this:
< @label=abc123 PRIVMSG #satisfiedpear :/unban jptest_
> @label=abc123;msg-id=unban_success :tmi.twitch.tv NOTICE #satisfiedpear :たかかげ is no longer banned from this room.
As you see, you can now easily link the reply back to the executed command, and thus, bot developers could implement their own commands on top of the Twitch chat that seamlessly make use of asynchronous APIs and reliably react to success or failure of the commands they sent.
These labels are not mandatory, the client would only send them with commands it needs to get a reply to. This would not require any changes to the on-site chat interface script since it doesn’t need to link the response back to the command that was sent - it simply displays the result anyway. (I’m sure you guys could build some awesome things on top of this as well, though!)
Please consider implementing this to help bot developers build more reliable commands.
I’m curious what a real world example would look like. I haven’t come across a situation where I’d be interested in the command response as far as my bot is concerned so far.
My point is why does it matter to the bot’s functionality. What failure would make the bot take additional action, where the original command’s parameters matter?
Well it’s basically just a nonce/state. Just echo it back.
In tmi.js, Promises are returned for most things including commands and messages. It’s typically a little more than a guess that a thing worked based on events so that it can resolve or reject. Being able to know that there was success or failure would improve the quality. My bot is built around Promises so just having a guess isn’t really good enough if there’s some sequence, logging, statistics, error detection, etc. that needs to happen.
As a real world use case, think about bots with a GUI. As a user (= broadcaster), wouldn’t you want to click a button to timeout someone and have visual feedback when it actually worked (or didn’t)? Preferably not in the chat window that’s already moving quickly and you’re trying hard to keep up?
I know, broadcasters timing out people is not a strong example, but the more generic use-case has already been summed up pretty well by Alca, and there are probably tons of people out there who have better ideas to use this. I just want to make it possible using the library I’m writing.
To be fair: it’s not just a nonce. You also have to support IRCv3 batches for when the response is multiline (probably NAMES? I don’t actually know which commands on Twitch generate multiple reply lines), as stated in the spec. Doesn’t seem too hard though.
You have CLEARCHAT for success and the NOTICE for failure. CLEARCHAT will carry over the message ID if you sent it with the timeout and the NOTICE message should be good enough for the user to identify which one didn’t work.
None of them apart from NAMES (which is only a reply to JOIN). If they’re too long, they simply break the IRC max length (you requested the Twitch-specific capabilities, should be able to handle it). Try /mods in #dota2lobby for example.
It’s not good enough if the timed out user uses a Chinese or Japanese display name, which was exactly my point in the OP.
But even without that, it makes replies much more reliable - say you send a /ban, but before it arrives at the server someone else does a /ban too. You receive a CLEARCHAT before the NOTICE because the other /ban succeeded, but your own /ban actually failed (they were banned already).
(note that I refer to /ban and not /timeout here because timing out twice is valid.)
It basically introduces another server-generated identifier for all the lines that belong to the reply to your command, and there’s definite knowledge about when the reply ends.
Also, while I’m at it, there should also be some kind of reply to a failed JOIN. The only thing you can do right now to verify that a join worked: race the join against a timeout that’s longer than your current latency, and hope your latency didn’t just increase. The fact that I had to include the word “hope” tells enough.