From: jefftep@cs.utexas.edu (Jeffrey Grills)
Newsgroups: alt.irc
Subject: Writing a good bot (was: lookup for bo documentation)
Date: 8 Apr 1992 22:46:12 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: grit.cs.utexas.edu

Well, this is a topic I'm capable of discussing in full since I've just
written a bot.  I wrote it in perl, and execute it with the -e option
of IRC.  The benefits of this approach are almost innumerable -- you
have real variable storage so you can "remember" things.  Perl, being
the string-oriented language that it is, makes this task much easier
than a comparative program in lisp, c, c++, awk, or sed.  The bot
will get 1 line of input for any message sent across the net.  You
can parse the message, and determine if it is a system notification,
a message to the bot, or just channel chatter.  Appropriate action
may be taken upon the input, then.

The bot never automatically says anything to a channel.  All communication
is done through messages to and from the bot.   For a user to access
the bot, they must first send a message to the bot telling it who
they are (a login name) and a password.  If it is successful, the
bot then allows them to execute commands on it.  If five
minutes elapse without receiving a message from a user, they
must re-enter their password to allow them to do anything.  This
prevents people from quitting irc, and someone using the same nick
to execute commands.  You should investigate the use of the ON
command to better handle this situation.

The commands are broken up into classes that may be assigned to users
either in those classes, or on a command-by-command basis.
Some of the commands are very tame, and some are dangerous, so you may
allow those you trust varying amounts of access to your bot/account.
For instance, the bot has a command that will make the user a channel
operator (if, of course, the bot is one).  This facilitates making a
bot a channel "master".  It can be left alone to operate, and only
those who have accounts on the bot could become channel operators
(or those people that they op...).  Another small feature is users
of the bot may leave messages for one another.  When a person logs
onto the bot, they receive all messages for them that the bot has
saved.  This facilitates communication between the bot owner and
the users.

Another command allows the user to make the bot type something
into the IRC as if it was typed by a person, and another allows
it to evaluate perl code typed in by the user.  These two
commands are *extremely* dangerous -- someone using the "type"
command could make the bot exec "rm -rf $HOME" and then you'd
loose everything.  With the capability to execute perl code,
the damages could be worse.  The least a person could do, would
be give themselves full privledges on the bot.  

Anyways, the bot has several safety precautions built into it.  If
it gets kicked off a channel, it sleeps for a specified time (stored
in a variable you can change at run time), and then attempts to 
rejoin the channel.  This alleviates the auto-join/auto-kick problem.

I've not yet implemented the next idea, but will very soon.  If the
bot is alone on a channel (which it can determine by executing a 
WHO command when it first logs on, and keeping track of sign-on's
and sign-offs), it could execute a mode -i for the channel.  Thus,
we'd never strand a channel.  Even now, when a person with
the "type" command privledge logs on to the irc, they could
make the bot type the command manually, and the channel would be open
again.  This would make many IRCops much happier.

The bot has complete on-line administration.  It allows a person with
full privledges to create or delete accounts, assign or remove
privlidges, ect.  This has proved to be more useful than I would
have thought, so I advise this approach too.

The bounds are almost limitless with this approach.  Keep it in mind.
Please test bots on new channels, so you don't annoy users of
current channels.  Please think of the ramifications of *each*
command you write into the bot.  If done correctly, this is a useful
tool.  If done sloppily, the network traffic could be very costly
and the annoyance to users burdensome.

-- 
-------------------------+--------------------------------------------------
jeff grills              | "Sometimes i see myself so clearly, because I
jefftep@cs.utexas.edu    |   see nothing at all.  This feeling of emptiness
Undergrad Lab, UT Austin |   flees my soul, leaving even less behind."  -me
Newsgroups: alt.irc