Over at the Voxeo Developer’s Corner blog, I’ve posted an article and sample code that shows how to add reporting to your IM bots with Google Analytics.

Using [Google's] mobile support, you can now add Google Analytics to your IM bots. Any time someone sends a message to your bot, the interaction will be sent to Google Analytics and will show up in your reports alongside your web traffic.

Apparently our account with our DNS provider has lapsed. We apologize for the downtime. DNS service has been restored and IMified.com as well as bot.im bots should be resolving soon.

Update 10:34am est: All IMified sites and bots should be resolving properly

Last month we announced the ability to “SMSify” your applications by providing you with a free SMS enabled phone number to connect to your IMified applications. We had a limited number of phone numbers available and quickly ran out. Today, we have added a bunch of new numbers to the pool and re-enabled the sms tab in the bot settings page. Grab one while they’re still available. Check out our previous post on the addition of SMS to IMified for more info.

Join us on October 7th for a free webinar when we will be teaming up with Voxeo’s VoiceObjects team to talk about building multi-channel applications that work across IM, SMS, twitter, the web, and voice.

Topic: IMify your voice application! Exploring new ways of customer interaction with Voxeo VoiceObjects and IMified

Date: Wednesday, October 7th, 2009
Time: 8am PDT, 11am EDT, 5pm CEST

Speakers:
Dave Hoff, Senior Engineer, Voxeo
Tobias Goebel, Sr. Presales Consultant, Voxeo Germany

Abstract: With the acquisition of IMified and VoiceObjects, Voxeo has demonstrated its clear commitment to be the number 1 provider of Unified Self-Service™: the idea that one and the same service definition can drive dialogs in any modality available to end customers, be it voice, video, SMS, USSD, IM, Web, or even social networks.

This jam session introduces IMified, Voxeo’s hosted platform for Instant Messaging bots, and explains how VoiceObjects can be utilized to build dialogs that extend the scope of customer interaction to Instant Messaging networks such as Yahoo, Skype, AOL, MSN, or Google Talk, but also other text-based channels such as SMS or Twitter. Learn how to IMify your existing VoiceObjects application with minimal developer effort but maximum customer impact.

If you can’t attend on Wednesday, we will post a link to an archive of the webinar for viewing later. Hope to see you Wednesday!

Some developers saw their Twitter bots begin replying multiple times to every message yesterday. We apologize for that and are working to prevent it from happening again in the future.

For those interested in the technical details of the issue, here’s what happened.

Our application has an exemption from Twitter’s normal API rate limits. Where normally users are only able to make 150 requests per hour to the API, each of our servers are able to make 20,000 requests per hour, and requests made from our servers to a Twitter ID do not count toward that Twitter ID’s normal 150 per hour rate limit. This exemption allows us to respond to messages within moments of them being sent to your Twitter account as well as allowing us to manage a large number of Twitter accounts.

Because the number of requests we need to make to process your messages varies depending on how many messages are sent to your bot and how many messages you send from your bot to other people, we constantly re-evaluate the API rate limit status of each server. This ensures that we always have enough remaining connections to reply to messages. Our system checks with Twitter to see how many API calls are remaining and how long before the rate limit count is reset. We then increase or decrease the pace of our API calls to fit within the remaining limit.

Our normal workflow is to check the rate limit, adjust our API pace, then connect to every Twitter account we’re monitoring, download new messages, and post replies. Then we start the process again.

Unfortunately an issue with Twitter’s API exposed a race condition that we hadn’t anticipated. For those unfamiliar with race conditions, they occur when two processes attempt to do the same thing at the same time or when they both attempt to modify the same data. Each process is unaware that there’s another process doing the same thing, resulting in inconsistent and unpredictable results.

Yesterday, Twitter increased our rate limit unintentionally. Instead of each server making 20,000 requests per hour, we suddenly were allowed to make 20,000 requests per second. Our code that constantly adjusts the pace of our API calls performed it’s magic and sped up our system. Instead of processing your messages every few seconds, we started processing them several dozen times per second. Often, in an attempt to keep up, our system would attempt to process the same message multiple times simultaneously, causing a race condition. This resulted in your replies being posted several times. Sometimes another race condition occurred, causing us to re-process the same messages we’d already downloaded earlier in the day. These two issues combined to post your replies several times, sometimes over the course of several hours.

Some users saw this compounded by an unrelated issue. One of our servers went offline and when it came back, the Twitter process did not properly restart. This prevented us from processing messages for some Twitter accounts. When we restarted it, some of these accounts had a backlog of messages to process. The restart happened after the race condition issue appeared, resulting in this backlog of messages often getting processed multiple times. So instead of just a couple of messages getting multiple replies, many messages were replied to multiple times.

We’re taking several steps to prevent this from re-occurring. We’ve added some sanity checks rate limit logic to ensure that we don’t hit the Twitter API at an unreasonable pace, even if Twitter tells us it’s okay to do so. We’re in the process of adding safeguards that will guarantee that multiple processes don’t attempt to fetch and reply to the same account at the same time. To prevent the race condition from happening again while we work to implement these safeguards, we’ve placed an artificial cap on the volume of our API requests. This may cause your Twitter bots to respond more slowly than normal until we finish fixing the issue. We anticipate releasing the fix and lifting our self-imposed cap within a few days.

When we started IMified, we had some ideas for a couple of simple apps that ran over IM. It turned out that compared to developing a web app, sending and receiving instant messages was complicated and required understanding of all sorts of arcane rules and techniques. We wished for an easy way to send and receive instant messages. So we built a service that allowed anyone that can build a web app to plug into IM networks.

Ever since then, one of the most requested features has been SMS support. Heck, we’ve found ourselves wishing there was an easy way to send and receive text messages. Compared to delivering a web app,  sending and receiving text messages is complicated and requires understanding of all sorts of arcane rules and techniques.

Hey, that sounds familiar.

Starting today, you don’t need to understand short codes, SMS gateways, routing, DIDs or the silliness that different carriers inject into the whole process. In fact, you don’t even need to write any new code. Your existing IMified app can work over SMS.

Adding SMS to your app couldn’t be simpler. Just log into your account and select your app. Under Network Settings, click the SMS tab. Click activate and we’ll assign you a phone number.

Any text messages that get sent to that number will be delivered to your app just like an instant message. There will be a userkey, a message, and all the goodies you already know and love. Your app’s response will be sent as a return text message to the sender. You can send out text messages by sending to the user’s userkey.

If you want to respond differently to SMS users, you can do so by checking the network field in the message to your bot. Just like we already tell you if the message came from AIM, Jabber, Twitter or any of our other networks, we’ll also tell you if it’s coming via SMS.

IMified will be offline tonight, 8/17, starting at 11pm est for approximately 2 hours. We will be migrating IMified from its current DC to its new home at Voxeo. Service should resume as normal after we flip the switch.

We have created a system status blog at http://status.imified.com. Please check there for updates.

The IMified platform will be offline for 1-2 hours on 8/4 starting at 12:00 am EST. We will be deploying a number of bug fixes, interface updates, and a fix to a bug causing authentication issues when adding Yahoo bots.

We’ve just released a couple of handy features for your bots. First, we’ve added Google Talk as a network that you can add to your bot. Our Jabber bots have always allowed GTalk users to talk to them, but with this addition, you can have a Google Talk Jabber ID for your bot. Hook it up and add yourbot@gmail.com as an option for your users. Or if you’re using Google Apps for your domain, you can tie yourbot@yourdomain.com to your bot.

Next, a few oft-requested features have been added to the API. Get a list of all your users, update your extended status, and connect multiple bots to the same URL.

Update Status allows you to set the extended status message for your bot. Some IM clients show this in the friends list right alongside the bot’s name. Just send your status message to our update status method and tell us which network you want to add the status message to. Update status on Twitter, and we’ll post the message to your timeline.

We now send you an extra field when a message comes into your bot — your bot key. This allows you to know exactly which bot a message came in to. Why would you need to know that? Using this, you can connect several bots to a single url, and use the bot key to determine which bot the message was to.

And finally, if you want to grab a list of all your users at once, we have Get All Users. It returns the same familiar information as Get User does, but with a list of all your users. We also hand you a count of your users so you’ll be able to see at a glance how many you have.

Our goal with IMified is to allow you to write one application and have it work over any text-based channel. Be that public IM networks, private XMPP networks, or now Twitter.

If you have an existing IM bot, you can now connect a Twitter id to it. You don’t need to write any special code, deal with Twitter API rate limits, or do anything new with Twitter. Things will just work. Simply log into your account, select your application, and activate Twitter.

After you connect Twitter to your app, we’ll start sending you all the direct messages and mentions (aka @ replies) that it gets. Your app responds to those just like any other incoming instant message and we send your response back to the other person. If they sent you a DM, we’ll respond via DM. If the message was a mention, we’ll reply in kind. You can also push messages to Twitter users, sending them an @ reply or a direct message.

You might want to handle some formatting differently in Twitter than you do in your IM messages. To help you with that, we tell you if the message is coming from Twitter, AIM, or another network.

Want to try it out? We’ve got a demo set up called Gridlock. Send your location to gridlock@bot.im on Jabber or gridlockbot on AIM, Yahoo, or Twitter. The application will reply with any known traffic incidents that are reported by the Yahoo Traffic API.

To help you get started with building your own Twitter and IM applications, we’ve published the PHP source code for Gridlock. We’ve updated our API documentation to include information about Twitter.

And if you’re a user of Twitter, follow us at @imified and @voxeo.