Hello all,

I am building a site that will allow people to chat with a variety of chatbots through a single interface. I want to build it in a manner that makes it easy for chatbot authors to advertise their bots by focusing traffic to a single site.

What would be your preferred format for a chat interface / API?

Right now I’m just building it as a standard socket - you’d receive plaintext input from the user, and send back plaintext responses.

If there’s a generally accepted or preferred way for bot i/o, I’d love to hear about it so I can try to implement this in a way that makes chatbot writers happy :D

Thanks!

That’s a real good question Paul!

Actually, representing Chatbots.org, we’re thinking about setting up a similar technology to check whether chabots.org are still alive. Based on that we want to to update their status in the system, which would allow Chatbots.org visitors to select live chatbots only’.

We might work together in this.

Would you be interested in web based chatbots or will you be looking at IM chatbots as well?

I would be happy to work together to make a status board.

I am basically making a chatbot gateway, so that you’d have:

[chatbot]—> [gateway]—> [web frontend]

Right now I’m building the gateway and web frontend. It would be pretty straightforward for me to create a page that says “these bots have used the gateway in the past N days / weeks / whatever”, which I think would accomplish what you were looking to do.

I think one of my assumptions may have been faulty, however. I’ve been approaching the gateway purely as a software developer; I didn’t really think about the fact that some bot operators may not have written the bot itself but have trained a bot using existing software. I’m not sure how prevalent that is versus people who have written their own bots.

I’ve just purchased a copy of “Be Your Own Botmaster”, I’ll take a look through that and see how it discusses running a bot.

My hope is that a gateway can be built in a way that it simple enough for people to configure their bots to use it - then it won’t matter as much if their chatbot usually communicates via the web or IM.

I would certainly appreciate any input / course corrections.

Thanks again!

From my experience, working with turinghub.com, no two chatterbot authors could agree on the best way to remotely interface to their bot. At one time, I used a method of “screen scraping” to artificially post messages and retrieve the response, but as people changed their bots over time, eventually this would become broken, or impractical to maintain.

A more useful question might be “what is the most practical method for communicating with web bots?” Pandorabots has an easy to use interface. But part of the problem with some other bots is their state information. Some bots keep track of an emotional state, a list of past utterances, and other goodies that need to be parsed and stored during each interaction.  So there is a range of possible answers to the question. Perhaps if you build it, they will come.

Good luck with your project.

Robby.

@Robby: How does Pandora track sessions? Via a cookie, a session ID or even something else?

Hi Erwin,

Pandora uses a session ID and an XML based transaction.  They have documentation on it somewhere on their site I think. One primary use for it is to enable Flash bot interfaces.

Best,

Robby.

@Robby - I haven’t seen turinghub.com before; thank you for linking to it. The thing I’m working on is actually quite similar, except people coming to the web front end will have the choice of choosing a bot to speak with, or going into a pool of people where they may be talking to a bot or to a person.

How long ago did you create turinghub.com? Do you feel that the community has changed much since then? I’m guessing that I’m going to run in to the same problems you ran in to.

I will take a look at the Pandorabots interface to see if there is some insight that can be had.

I hope that I can find a solution that doesn’t require screen-scraping. I really want to build a place where a high school kid could sign up, wire his bot into my system at 2am on a Saturday night and start getting traffic right away to test his bot and see how it does.

In the absence of a community standard, I will probably keep pushing forward with a simple socket system or something similar to Pandora’s system just to get started and then adjust accordingly.

More about the state issues. Some bots, especially those that work with a session ID, keep their state internally. Of course this requires more resources on the remote bot server side. Many bots however keep their state info on the web page your’e typing to, in the form of hidden form variables. To interface with these bots, you have to tie up your own server resources to somehow store the variables and make transactions with them.

Screen scraping can be made automatic to some degree, ie. you automatically store all the hidden variables and then regurgitate them when you send the next query. But usually, you also have to store a cookie, and depending on what language you’re doing this with, you may find resources to help with this in the form of 3rd party packages or frameworks.

I found that java servlets worked fairly well for this, using tomcat and apache to serve them, though memory management was a challenge.

I’ve also used a php approach for the bot gateway (turing hub) and it is possible to scrape hidden variables from a remote bot’s page and hide them on your own central interface page. That is one way to mitigate your server resources.

Robby.

Hi Paul,

Maybe if you build a nice socket system, you can encourage bot developers to interface with it. Make them come to you in other words.

I first developed the Turing Hub for the 2002 Loebner Prize Contest. The 2nd edition in Java was around 2005.

Good luck!

Robby.

just moved this thread to ‘development->tools’ section

Robby, I think you’re probably right; I’ll just have to make sure the system works well enough that developers want to use it.

I will probably have a better feel for what it takes once I get some bots interfaced into the gateway on my own; at which point I’m sure I’ll be back to ask for input.

May I suggest using the Simple Object Access Protocol (SOAP) and access the bot via Web Services.  Most modern languages, Java, and various MS .net languages allow you to very easily create Web-Service enabled applications, allow you to specify which public methods of your objects can be accessed via web service.  Then, simply provide the WSDL (web services description language) which specifies how to access the bot via SOAP.

Writing an app that talks to that bot via WSDL is very simple using Microsoft visual studio .net (free version now available on their site), also Java with Netbeans.

Hi Victor,

php does that too (stdClass Object) using a standard text editor. So it sounds like you made a good suggestion to Paul and Erwin:

http://www.8pla.net/SOAP/wsdl.php?say=WRITE-WHATEVER-YOU-WANT-HERE

Replace “WRITE-WHATEVER-YOU-WANT-HERE” with whatever you want to say instead.

For example:

http://www.8pla.net/SOAP/wsdl.php?say=Greetings!

NOTE: This test bot has a basic A.I. with limited responses, which was the intention,
in order to place the focus on testing all that cool tech stuff you just spoke about.

Using sockets is a solid idea too, used in online gaming for example, but the developers may have to build and send headers which may get tricky, even for senior developers. Especially while debugging remotely, say from the UK to the US, sockets may feel unforgiving at times.

Hiya Robby!

Agreed, depending on the complexity of the functionalities required, sockets may be the better option (keep it simple).  If you required more functions over the simple send-response paradigm, then I’d go with web servers.  I’ll try that site, thanks.

Sorry for the long radio silence about this. I’ve gone a bunch of different ways and found problems with most. Sockets worked decently, but it seemed overly complicated to deal with them. I started going down the SOAP path as Victor recommended, and then it hit me that there is a *perfect* protocol in place for what I’m looking to do - XMPP (Jabber protocol).

Additionally, all of the major languages have libraries to operate with XMPP already; and it has the added benefit of helping bots keep track of conversations.

I’ll have more news soon, but I’m looking forward to finishing writing this so I can get your opinions (and suggestions, perhaps!).

Thanks again for all of the great advice on this, it was tremendously helpful in figuring out which way to go

Glad we could be of assistance Paul.

I look forward to your future posts on this subject. 

I don’t want to have to develop a web application front end for my bot, I would much rather have it speak some sort of API to communicate with external world, for now anyway.

Then perhaps I may write a simple “thick” client in visual C# or something to communicate with it.  I want to keep my bot cross platform (Perl) which of course can run anywhere.  But since most people have Windows, I will probably write the thick client as either Win32.exe or perhaps Java, and communicate with the server where the bot will run, via an API.

Although I have done a lot of web app work, I find it is often a pain, browser compatibility issues, you name it.  A nice thick installed client is the way to go.

I’m going to do some ‘googling’ on XMPP also.