Hackdiary

A mail to the bots list about a web-to-IRC gateway.

Subject: [Bots] gatebot – making bots URL-addressable
From: Matt Biddulph
Date: Mon Aug 26 14:41:05 2002

I’ve put up a new experimental service that allows code to talk to IRC
bots over the web without making a direct IRC connection.

You can try it out here via a dodgy web form interface:

https://www.picdiary.com/bot/index.html

But it’s really meant as some kind of web API for access by code (e.g.
so web apps could ask the foafbot for people-related information). It
works like this:

POST to
https://www.picdiary.com/bot/servlet/GatebotServlet/some.irc.server/somebotnick
with a query of "say=what%20you%want%20to%say". The web service sends a
proxy bot onto some.irc.server and privmsgs somebotnick with what you
want to say.

You get back a simple HTML document, with a 201 Created status to
indicate the creation of a new session URL for you to read back what is
said. This session URL is given both in the HTML (for browser-based
testing) and in the HTTP Location: header. Every time you hit this URL,
it’ll give you a line-by-line dump of what have been privmsged back to
the proxy bot (obviously this will be blank if you hit the URL quickly –
if you expect an answer then poll it at some regular interval).

If nothing is said to the bot for 60 seconds, it leaves the IRC network
but the URL remains available ‘indefinitely’ (it’s kept in memory and
will die when my webserver restarts). You should also be able to say
further things to the same bot in the same session by POSTing to the
session URL with "say=whatever"

Source code (perl for the bot bits, java servlet for the web bits) is
here:
https://www.picdiary.com/~mattb/bots/gatebot-0.2.tar.gz
Apologies for any hard-coded paths or other cruftiness. The version of
Bot::BasicBot in there is slightly modified to listen on STDIN so that
the web layer can communicate with its proxy bots by spawning processes
and using STDIN/STDOUT.

There are a couple of pieces of demo client code in the tarball.
getkarma asks the infobot ‘robert’ on #pants for karma of things via a
commandline interface. There’s also an infobotkarmabot that does the
same thing but with an IRC interface.

Here’s the IRC karma bot connecting to #bots on london.rhizomatic.net:

–> robertpro (~robertpro@217.158.195.49) has joined #bots
<mattb> robertkarma test
<robertpro> robert says test has karma of 1

and the action this triggered on #gatebot (where proxy bots hang out
while they’re privmsging) on the irc network where #pants lives:

–> EUUREbot (tomcat4@pod-124.dolphin-server.co.uk) has joined #gatebot
<EUUREbot> robert said ‘test has karma of 1’

Feel free to play with this, and flame me royally if it breaks or sucks.

Cheers,
Matt.

and a later response to a followup:

On Mon, 2002-08-26 at 17:16, Mark Fowler wrote:
> Hmm. Any reason this can’t be a GET? Aside from the breaking of the
> idempotent nature of requests I mean (pah, RFCs.) It’d just be nice so
> that you can use it with Mozilla’s bookmark keywords function (where you
> can type ‘$keyword $foo’ and it looks up a url you’ve associated with
> $keyword changing ‘%s’ for a URI encoded version of $foo.)

Yeah, preserving the semantics of POST seems quite important here – this
is initiating an action, which causes the creation of a resource (both
in the sense of the URL and the process actually forked). This resource
then becomes readable in an idempotent way, its content changing as it
(hopefully) interacts with the remote bot it’s talking to.

In order to support an application such as ‘return me this information’
for bookmark-keywords purposes, I would rather a wrapper application
were used that was truly GETtable – it would make the initial POST and
poll the resulting GETtable session until it returned some useful
information. Only then would it return 200 OK and some content to the
client. A directly GETtable gatebot service would 99% of the time simply
return a blank screen to the browser because it has no way of knowing
how long to wait (if it should wait for a response at all).