Tags: irc, programming, security
If you’ve been on IRC for any substantial period of time, you will have encountered an IRC bot. Whether it was NickServ or ChanServ or your favorite channel’s operator’s pet bot, you will have interacted with an automated client designed to ease and simplify your IRC experience.
This should come as no surprise. Constructing and running an IRC bot has been a programming rite of passage for decades, and isn’t going away anytime soon. As a consequence of this there are tens of thousands of unique IRC bots, many of which are still running unused and undetected.
This isn’t a huge problem in and of itself (apart from bugs and security holes in the bots themselves), but it would be nice if channel operators and users alike had a way to easily identify bots in their channel(s).
IBIP makes that possible.
IBIP, or the IRC Bot Identification Protocol, is exactly what it sounds like: a protocol for identifying IRC bots.
It standardizes two things: a trigger, listened for by all IBIP-compliant bots, and a PRIVMSG sent by all IBIP-compliant bots in response to the trigger.
The trigger is simple:
Or, as a complete PRIVMSG:
1 PRIVMSG target :.bots
Where target is a channel or nickname.
In response, IBIP-compliant bots are expected to send a response like this:
1 Reporting in! [language] information
Once again as a complete PRIVMSG:
1 PRIVMSG target :Reporting in! [language] information
[Perl]. This section is purely optional. If multiple languages are used by the bot, they should be slash-separated.
The two optional sections may be used without their partner, but the information section may not be surrounded by brackets in any circumstance.
Therefore, a complete response would look like this:
1 Reporting in! [Ruby] See my !help command for a list of commands.
These two simple rules quickly become very useful for finding and enumerating bots. A sample session might look like this:
1 2 3 4 5 6 Talking on #channel. <john_doe> .bots <bot1> Reporting in! [C] <bot2> Reporting in! <bot3> Reporting in! [Java] http://example.com <bot4> Reporting in! Version 2.8.56 running on Debian GNU/Linux x86_64
Each of those responses was valid, making each bot IBIP-compliant.
Although this might seem like a source of spam, it can be very useful for
channel operators and users alike. If an operator would like to keep a cap on
the number of IRC bots in the channel at any given point, they can simply issue
.bots command and manage all enumerated bots with a script that matches
Similarly, channel users will be able to issue
ascertain which (if any) bots can be used to perform channel tasks.
There are two large drawbacks to IBIP’s modus operandi:
.botstrigger with a contrived response, like
Reporting in! [Human] Th1s ch4nn3l suX0rs!. It’s a matter of opinion whether or not this type of scripted response actually constitutes an IRC bot itself.
.botstrigger over and over, resulting in a deluge of useless messages. The best way to prevent this is to institute a cooldown period within each bot, although simply auto-kicking or muting users who spam the trigger would also suffice.
With an administrative bot and occasional intervention by human operators, both of these pitfalls can be avoided.
In summary, IBIP can be a very good thing for the Wild West of IRC and IRC bots. If enough large frameworks/bot authors add compliance (a very simple affair, by any measure), every user will be just one message away from accessing otherwise hidden services.
If you are an IRC bot author, please consider adding it to your bot. It’ll make me very happy.