This is Part 1 in a series of blog posts about my adventures programming chatterbots for instant messengers in the early 2000's. In this series of posts, I'll focus on one instant messenger at a time and dive into the interesting quirks and challenges we botmakers faced when programming bots for them.
The order of the posts will roughly start "from the beginning." This is Part One: AOL Instant Messenger.
First, the thing that got me interested in chatterbots in the first place. That would've been SmarterChild, a commercial chatbot created by ActiveBuddy, Inc. -- a company that would go on to try and patent the very concept of chatbots, change their name a couple times, get bought by Microsoft, and never be heard from again.
SmarterChild was a bot that you would chat with in plain English (like Siri nowadays), or you could do things like ask it for weather reports or movie showtimes. It was an AOL Instant Messenger bot at first, and later on was ported to MSN Messenger.
As an interesting quirk I discovered about SmarterChild some years later: I think its screen name technically had AOL Administrator privileges.
AOL Admin screen names had some special behaviors: they can not be blocked or warned and they have no rate limits. SmarterChild could not be warned (as I'm sure a lot of users found out for themselves), but had anyone tried to block him? If you had, you'd discover that SmarterChild could not be blocked. He'd still appear online on your buddy list, and could still chat with you, but if you moused over his name your client would say "Blocked".
I discovered this the hard way with one of my AIM bots: it had the 'feature' where a user could tell my bot to IM another user, and somebody made my bot send a message to SmarterChild. The bots started replying to each other in an endless loop, so I tried telling my bot to block SmarterChild to make it stop, but SmarterChild could not be blocked.
I had to take my bot down and program in a "soft block" feature, where my bot would simply ignore messages from users rather than depend on protocol-level blocking. It's a feature I kept in every bot I built since.
So, I wanted to know where I could run an AIM bot of my own. I found a site called RunABot which would offer free hosting of AIM chat bots. You could configure and program them on the RunABot website, and then download a client program to actually sign them on to AIM for chatting with humans. The bot would usually take a second or two to reply to user messages, as it always had to ping the RunABot server for replies.
RunABot itself had some interesting features. To start out with, you'd choose a "Base Brain" for your chatbot to be built on. Basically, if somebody asked your bot something that it didn't specifically know how to answer, it would fall back to its Base Brain to answer the user instead.
One of the base brains was Alice, which is a Loebner Prize winning chatbot personality with tens of thousands of replies built in. Naturally, this was the best base brain to go with, as it made your bot smart automatically before you even begin programming it.
The other base brain was ELIZA, based on Joseph Weizenbaum's psychotherapist simulation bot that tries to sound smart by repeating users' own questions back at them. This bot would most often reply with things like "That is interesting. Please continue." or "You aren't really talking about me, are you?" to things users ask, which is a lot less impressive than Alice. With the Eliza base brain, the heavy lifting is on the individual bot maker to program their own replies.
Any time RunABot was experiencing heavy load, the free bot accounts were all downgraded to Eliza. (I was a kid and couldn't pay for a premium account). This started happening more and more frequently, so I started to look for alternatives for running AIM bots.
RunABot's reply engine was based on AIML, and so naturally I discovered The ALICE A.I. Foundation and other AIML-based bots and decided to go with AliceBot Program D, a chatbot written in Java that allegedly worked with AIM, ICQ and IRC.
Already, there were some improvements over RunABot: I wasn't reliant on a third party host, my bot could always be based on Alice with no downtime, and my bot would respond instantly to its messages rather than taking a few seconds. The support for IRC was cool, too, and I configured it to use that. The ICQ support wasn't working, though; it was likely programmed against an older version of the protocol.
After running an AIM bot on Program D for a while, I started running into some issues with the protocol (that RunABot actually knew how to catch and work around properly): rate limits and AIM's warning system.
A long time ago, AIM had a system called "warnings" (they don't have this system anymore; AIM still exists today, by the way!)
In a conversation window, next to the "Block" button was a button labeled "Warn". When you 'warned' a user, they would get a little percentage number next to their screen name (in chat windows and in buddy list windows); each warning could add +20% to this number for a maximum of 60% (hitting "Warn" three times). You could only click "Warn" once per received message from the user, to a maximum of three.
The higher a user's warning percentage is, the more that user's rate limit suffers. If a user had no warning level, they could send, say, 5 messages within 2 seconds just fine. But when the user gets to, say, 60%, they might only be allowed to send one message per 10 seconds. The rate limit was global, affecting all your chats, so at a high warning level you can't chat very much with anyone.
The idea behind this was to limit spam bots on the network and allow users to 'warn' others about how spammy a particular user is. If you got a random message from a stranger and saw they already had an 80% warning level, you could probably guess they've been angering a lot of people already.
The warning percentage would slowly decline over time until it reaches 0% again.
With chatbots, warnings from users could essentially act as a denial-of-service attack. A malicious user could chat with your bot long enough to receive three responses, warn your bot three times and get it at a 60% warning level. At this point the bot's rate limit is so damaged that it can barely chat with any other users, and could eventually be kicked offline by the server if it does exceed its rate limits too often.
As an interesting quirk and history lesson, the Warning feature was internally called "Evil". As in, at the AIM protocol level the event is named "evil". This article, "The Rise and Fall of AIM, the Breakthrough AOL Never Wanted" mentions this from their point of view as well.
RunABot had an interesting position of power with their bots: if any user on AIM were to warn any AIM bot hosted by RunABot, that user would end up being "soft blocked" by all RunABot bots. They would just stop responding to any messages by that user; every single RunABot bot would block a warner system-wide.
Program D didn't manage its own rate limit, and it also had no handler for warnings. An AIM bot on Program D was a sitting duck for trolls to take down. This was one of its biggest problems for me.
So, I decided I'd dig a bit deeper to find a better way to run AIM bots, one that knew how to handle warnings and rate limits. It was also around this time that I wanted to run an MSN Messenger bot, but more on that in the next article. So, I Googled "MSN Messenger bot" and found a website called WiredBots that provided barebones Perl bot templates -- one for AIM and one for MSN.
The AIM bot had support for handling warnings, and I somewhat liked it: if you warn the bot, the bot would immediately warn you in revenge, block you (using a protocol-level, temporary block!), and add your screen name to a list of warners. When the bot restarts (signs off and back on), you're unblocked so you're able to message the bot again; but upon doing so, the bot would immediately warn you and then temp-block you again.
It was a bit mean, but at least it defended itself against warners.
It wasn't until I was running my own bots that I could modify the source code to, that I started to hear about the names that AIM's protocol goes by.
The initial Perl bot templates from WiredBots used a Perl module named
Net::AIM (CPAN) to connect to AIM. It turned out that the AIM protocol used by this module was named TOC, or "Talk to OSCAR"; it was a simpler AIM protocol used by mobile and third-party clients. It acted as a wrapper around the OSCAR protocol, which is the 'real' AIM protocol (also, ICQ uses it now, too!)
A notable feature
Net::AIM lacked was support for setting its buddy icons. There was another Perl module available,
Net::OSCAR (CPAN) which implemented an OSCAR client and supported more features. Before long, the TOC protocol was discontinued anyway, and all AIM bots had to be using OSCAR now.
While Microsoft and Yahoo were fighting against friendly SmarterChild-like bots on their platforms, AOL eventually decided they should embrace the chatbots.
Before this point, the only AIM bots that had AOL's blessing were SmarterChild and its friends. They were using AOL Admin screen names (I suspect) and had no rate limits and had millions of users. Us mere mortals running our own chat bots couldn't really compete with that.
So, AOL added a feature where you could make a normal AIM screen name into an official "bot screen name". This would remove the rate limit for sending messages from that screen name, but it had the limitation that the screen name isn't allowed to initiate new conversations, only to respond after being messaged first.
Some botmasters liked that feature and used it, but for me, I always liked the bot having the ability to message a user out of the blue. (For example, one user could tell the bot to send a message to her friend).
There's not much more to add about AIM or its bots.
Some may be surprised to find that AIM is still alive and kicking; I'm actually signed into it right now. It also hasn't changed very much over the years: they got rid of the warning system, but not much has been added or changed while Microsoft and Yahoo still continued adding feature bloat to their messengers.
Watch out for Part 2 of this IM Bots series where I'll talk about MSN Messenger and all the fun, clever things we could do with it.