Ibid chat bot
Chat bots can be controversial. Apart from the fun to be had watching a friend carrying out an inadvertent Turing test, finding the right balance between useful information and annoyance seems to be one of the harder aspects of chatbotology.
I spoke to Jonathan Hitchcock, Michael Gorven and Stefano Rivera about their work on the Ibid chat bot.
Matthew: What are you doing with Ibid that’s different to other chat bots?
Ibid team: Like all bots, Ibid has two parts: the front end, and the back end, and we like to think that there is something to distinguish Ibid in both.
On the front end, we attempt to make the bot as intuitive as possible to interact with. All commands are natural language, and our philosophy is that the plugins should try to work out what the user actually wants to know and answer that, rather than forcing him/her to learn an esoteric set of syntax before he can use the bot. Queries are bubbled through plugins in order of priority so that the most relevant reply can be given.
Secondly, on the back end, Ibid is also divided into two parts: “sources” (i.e. transports, communication mediums – IRC, jabber, email, etc) and “plugins” (modules that tell the bot how to respond to various queries). The design aims to be clean and modular: all sources and plugins are discrete units that can be enabled or disabled without breaking any assumptions elsewhere in the code. Unlike other bots where non-IRC protocol support seems to be an afterthought, Ibid plugins deal with all protocols equally (hopefully without making them all equally bad).
This modularity helps both new and existing developers. It is easy to jump straight into a small part of the code without having to understand the entire system. It is also very easy to add new sources: we had a DC chat source up and running in under a day, and a prototype GSM SMS gateway in a weekend. In addition, hot-pluggability is an important goal of the project: you can add and remove plugins and sources on the fly, without having to restart the bot.
Matthew: Who do you see using Ibid?
Ibid team: As we’ve been developing the bot, we’ve started thinking in terms of three different personas: users, owners and developers.
Users are the end-users who happen to be in IM channels where an Ibid is running — they should just see the bot as a fun and useful tool. They’ll notice people using it to google things, store factoids, check the weather, do currency conversions, and so on, and start following suit. We’ve noticed that our bots very quickly become integral to channel communities, and we try to make sure the bot’s “personality” facilitates this: the natural language interface, and the characteristic responses that the bot gives aid this. Michael and Jonathan both have Ibid instances running internally at their companies, and the other employees find them very useful.
Owners are the people that run instances of the bot — they probably run the channels too, and they need a way to integrate other things with IM. Ibid aims to make that easy. We’ve already got plugins for checking RSS feeds, working out distances, fetching tweets, and so on — the plugin nature of the bot’s features mean that as soon as a new need arises, we can churn out some code to fulfill it.
This is where the third persona comes in: the developer. Ibid is designed to have a very low barrier to entry, and to make it very easy to write plugins, so it can be used as a framework for interfacing with almost anything. It already has plugins for interfacing with Bazaar, Trac and Buildbot, and a Launchpad plugin is in development. Because Ibid is so modular, stripping out all the funky stuff to build an IM interface to a single service is pretty simple, and Ibid hopes to be a good building block for such systems. Which brings us to your next question…
Matthew: Are you hoping to attract developers to Ibid?
Ibid team: See here.
That would be a yes. In the channels where we have Ibids running, users have contributed plugins for features they want, and in one case used it as a quick way to get an IRC game up and running. We’d like more of all of those.
We’ve done our best to make it as simple as possible to write Ibid plugins. There’s still some work to go (mostly documentation), but anyone who knows some basic Python should be able to hack a quick plugin together in a very short time.
We haven’t made an initial release yet, as some of the Internal APIs have some biggish problems that need to be resolved, but the bot is packaged and already works out of the box, and we’d love for people to start using it and contributing plugins.
Matthew: The project’s a fairly heavy user of Bazaar. What made you choose Bazaar over other VCSs?
Ibid team: It was almost accidental — we didn’t have much experience with DVCS, but we definitely wanted to use one rather than, say, subversion. We saw that the Ubuntu community was punting Bazaar, which is relatively sane (compared to, say Git), and ran with it. It turned out to be a good choice: it’s simple to learn and pretty powerful. It also has a very low barrier to entry, coming from more traditional VCSs, but you can ramp up to using the advanced features in fairly small, but logical steps (which makes it very similar to python, as a learning language, I suppose).
Matthew: What aspect of Launchpad has most helped your development of Ibid?
Ibid team: We originally started with Launchpad just to get quick bug-tracking integration, but soon discovered the other features on offer. After moving the source over to be wholly hosted on Launchpad, we started to use branches and merge-requests, and these have now become integral to our development methodology. Every feature and fix that we work on is developed in a separate branch and the merge reviewed by all three of us. Waiting for reviews can stagnate development a bit when all the developers are busy with their dayjobs, but we think the results are worth it — apart from the obvious benefits of catching bugs before they’re merged into trunk, the request-and-review process keeps us all involved and aware of what is happening in the project.
I imagine that as we grow, this benefit will lessen (since not everybody will review each merge), but it is still a good way of signalling to the rest of the team that changes are happening in an area, so that if they are interested, they can make their opinions heard before the changes get finalised.
As a whole, the tight Lauchpad-Bazaar integration has been a huge bonus, allowing us to develop from a few guys committing bits of code to trunk into a community with workflows, milestones, goals and a clear vision of where we’re headed. Having the VCS and the bug-tracker and the discussion boards and everything all in one place really builds cohesion in the project.
Matthew: What would you most like to see improved or otherwise changed in Launchpad?
Ibid team: We have been moving more and more of our project management into Launchpad (throwing out Trac, and our own Bazaar repository, and our own mailing lists, and so on), but there are still a few things that we have to host ourselves: repositories for non-Ubuntu packages (just Debian debs right now, but we’d like to include RPMs, etc, in the future), the build environments to create them (we have our own pbuilders presently), documentation, and our wiki.
There are free services that provide each of the above, such as the OpenSUSE build service, and the many “create your own wiki” services, but filling those gaps would mean our project could live entirely on Launchpad, and would bring along greater integration and easier flows.
Other neat things we could use would be support for Bazaar hooks, and permanently linking merge commits with the merge request — currently we include the merge request URL in the commit log.
Basically, tighter integration of everything would make project management much easier, and let us focus more on coding, which is always a win.
Matthew: Thanks Jonathan, Michael and Stefano!
