IM and RSS: Rome is on Fire

Last August, Marshall Kirkpatrick (another Portland resident) posted an entry to TechCrunch about a company called FeedCrier which:

… makes it easy to receive rapid notification of new items in an RSS feed by IM

I bookmarked the link on del.icio.us, noting offhandedly that it would probably be easy to do something like this using Wildfire and Rome Fetcher… Almost 5 months to the day later, I’m really proud to say that it wasn’t easy, but it’s definitely doable, albeit with a slightly different aim.

If you swing by my website (instead of viewing this post in your favorite feed reader), you’ll see a list of ‘subscription options’ in the right hand navigation bar: RSS, AIM, Yahoo, MSN, Google Talk and Jabber / XMPP (the full set of IM services thanks IM Gateway Plugin). Clicking on RSS takes you to the feed so you can subscribe with a feed reader, clicking on any of the others results in a fancy schmancy dialog box (courtesy of YUI), into which you can plug in your preferred instant messaging username … click ‘subscribe’ and AJAX will send a request to the Wildfire plugin I created (proxied by mod_proxy), which will then send you an IM to confirm that you really want to receive alerts for this feed. Click the link in the IM and you’re off and running. The service then polls the feed you subscribed to at regular intervals, sending you a message if it finds something new. It supports all the feed formats that Rome supports and also supports XML-RPC pings (my blog is configured to ping the service when I post something to my blog).

I’ll be the first to admit that the UI sucks and that the dialog box should show a confirmation, that the YUI stuff is really heavy (380K of JavaScript and CSS to make a dialog box? sheesh!), that it’s not a ‘professional’ service like FeedCrier, and that I haven’t passed the code by the Wildfire team yet (I’m hoping they’ll accept it as a plugin that’ll be included as part of the base Wildfire distribution) but I’m really excited about the idea of RSS to IM in general and this implementation in particular for the following reasons:

  • As far as I know, all of the existing RSS to IM services (immedi.at, Zaptxt, Rasasa and the aforementioned FeedCrier) are hosted services. If I subscribe to your feed via any of the above services, I’ve got a relationship with them, not with you. If you’re a hip publisher, you’re probably sending pings their way, but you don’t know who is subscribed to your feed. You probably don’t have access to the list of subscribers (and as a subscriber maybe you wouldn’t want them too, but I’ll get to that in a second). With this plugin and an instance of Wildfire, you can go one to one with your customers, rather than working through some third party. Said another way, given the ability to run a Wildfire server, what company wouldn’t want to offer a ‘subscribe to this blog via IM’ as part of the ‘subscribe via email’ and ‘subscribe via RSS’ feature set?
  • Because you host it, you might configure the server in such a way as to give it access to feeds on your intranet, feeds that are completely inaccessible to *all* of the above services. What’s that you say? Your internal feeds are protected by Basic Authentication? That’s ok, the plugin can retrieve protected feeds as well. Specify the username and password in the URL (http://username:password@yourserver/feeds/my.xml) and you’re golden. So if you work at a big corporation that’s producing RSS feeds like rabbits produce baby bunnies, don’t fire up your desktop feed reader. Get someone to set up a Wildfire server and then pester them to install the plugin for you.
  • It’s truly instant: one of the things about RSS to instant messages is that you’d hope that you do get notified or alerted *instantly*. The reality is that it takes two to tango: for FeedCrier to alert you instantly when a feed is updated, they have to have the cooperation of the publisher, the publisher has to send them a ping when the feed is updated. Since the plugin supports XML-RPC pings, you as a publisher can configure your blogging software (or whatever else produces your RSS feeds) to send standard XML-RPC pings to the plugin, so while polling is supported, it should be the exception to the rule.
  • Finally, as a subscriber, the thing that’s valuable is that you a) get your content and b) that you get it instantly. You could care less about FeedCrier or any of these other services, you want your content now. So (and this is what I’d I’d get to earlier) you might be willing to give up the anonymity that RSS normally provides in exchange for immediate access to the information you want (or maybe anonymity isn’t a big deal to you at all). In other words, for truly valuable information, this service puts publishers in a position of power: subscribers get their fix instantly as long as they cough up their instant message information.

If you’ve gotten this far, thanks for reading. I’d love to hear your feedback. And don’t forget to subscribe. You know, to get your fix.

6 thoughts on “IM and RSS: Rome is on Fire”

  1. Aaron, this is stupendous! What an awesome mashup of IM and web technologies. That notifications can now be instant for important content rocks, and the internal use case illustrates the power of blogging and IM for inside the firewall.

  2. Okay, I’m a bit late to the party here. I just stumbled across this blog. I’m the founder of Feed Crier.

    Great to see a self-hosted system for Feeds over IM. It’s the wave of the future and I think we’ll see a lot more of this sort of thing.

    Feed Crier doesn’t rely entirely on periodic polling, either. Instead, it learns the update habits of the particular feed and adjusts it’s polling patterns to match. It also accepts pings, watches public ping servers, and generally tries to be smart about how it checks for feeds. By doing all this, we’re able to deliver feed updates in near real time.

    Intranet feeds are certainly something that’s harder for us to do, but we’re testing a system with some partners that will allow the intranet to push feed items to us for alerting. Instead of trying to drill through the firewall, we place an agent inside that relays alerts to us.

    In the end, Feed Crier is just another way to keep up to date on feed content, an alternative to web and desktop feed readers. We’re trying to make it as smooth and seamless as possible.

  3. I stumbled across your blog today and found this particular entry very interesting. I work on a team that has been developing JBI components and open sourcing them to java.net. Today we happened to demo our latest release which is an RSS Binding component, and one of the demonstrations was with our XMPP Binding Component. We used Wildfire to send an instant message and to our XMPP Binding Component and then published the message to an RSS Feed, using BPEL to orchestrate everything. We will be putting a video demonstration on how to do this on our project site. We would be interested in your feedback or questions that you might have. I’m also interested in seeing if I can do what you described using our Binding Components.

Leave a Reply to Chad Gallemore Cancel reply

Your email address will not be published. Required fields are marked *