If you think AJAX changed the web experience, imagine a web with decentralized, open standards-based IM at its center. That's an exciting thought. This post introduces the concepts at issue in accessible terms, discusses some of the possible impacts of such a trend on innovation and offers some counter-arguments to Jive's rosy picture of the future.

Jive is based in Portland, Oregon, took funding from Sequoia Capital (Early Google and YouTube funders) and has an impressive customer list available on its site.

The technical details of the argument are interesting and the product due from Jive at the end of this quarter is one to watch for, but I'm interested here primarily in what this professed trend could mean for startups, mashups and users of any number of services that together could make this a trend.

Early Examples

Jive points to a number of examples. Tivo, they say, no longer requires your box to check in with the Tivo servers periodically - the server sends a signal via XMPP to available boxes when new information is published. Tivo is essentially using machine-to-machine Instant Messaging for real time communication within its service.

Dave Winer says XMPP could be the foundation of a decentralized version of Twitter. Valley golden-boy startup Seesmic is using XMPP for messaging and AOL has reportedly begun experimenting with it as well. The Google-acquired Jaiku microblogging platform used XMPP heavily. One of Jive's own open source XMPP libraries was incorporated into the source code of Google's Android Mobile OS, as well.

Let's talk a bit about what exactly this means, followed by some creative thinking about where it could lead and some arguments against this forecast.

Jabber Explained In Simpler Terms

In simple terms and to the best of my understanding, the http protocol used by web pages is said to be inefficient because it requires a user's machine to poll a server periodically to see if any new information is available.

Quite often there is nothing new and energy has been wasted. Think of how often Gmail checks to see if you've got any new emails (every two minutes) or how many times your RSS reader pings all of your feeds to see if they contain any new items. Meanwhile, the time between polling leads to a delay in updates.

That might seem like a small burden to you, but multiply that times everyone using these services and there's a lot of inefficiency. Sometimes that inefficiency can define the technical limits of what a service is able to do. On an individual level, I know I'm unable to use Google Reader because I have enough subscriptions that it times out checking every single one of them for new information. I wish it would just chill out and wait!

This is not a problem experienced in the world of Instant Messaging. While there are too many IM protocols in the world, a growing number of IM clients, including Google Talk, use the open standard Jabber, or XMPP.

XMPP lets one party signal to any XMPP server that it is available to receive any new information that's being delivered. When another party sends new content through the XMPP server, the message is passed on immediately and automatically to all recipients who are marked as available, basically.

What Could a Future Built on Jabber Look Like?

Ask yourself what a decentralized, open source infrastructure for real time communication could offer. A lot. As an RSS-head, I'd love to see XMPP let my various RSS clients do more faster and get bogged down in fewer unnecessary activities. RSS is all about speed for me but clients can only do so much so often when they have to pester someone else's server every time they want to check for new information. Those delays can be of real consequence.

The Tivo example is just one of many possibilities in the realm of machine-to-machine XMPP communication. Automated alerts are useful in all kinds of more serious use-cases and why use polling to monitor changed conditions when you can use an open source protocol that can make presence and real time communication scalable?

Counter Arguments

The primary arguments against a future powered by XMPP are two. First, so much of what's already been developed is web-centric, based on http, that the options for mashup-fodder are relatively limited for XMPP. For a service to integrate a number of new and existing communication features, making the leap to a less ubiquitous protocol might not make sense. Time will tell if things like IM, Android and software like Jive's can change the near total imbalance in marketshare between communication protocols online.

The second argument against this rosy picture of the future could be that open standards-based technology falls outside the profit model of many larger companies. If one vendor can corner their respective model with proprietary technology and charge a monopolist's premium for superior service, then a standards based competitor will have their work cut out for them. Google Talk's use of XMPP may have been the straw that broke the camel's back in IM because the chat client rode the coat-tails of so many other Google services.

It's hard to know what role these obstacles will play in the future, but it is exciting to think about the possibilities that a standards based approach like XMPP offers for real time communication. No one will want to wait for a web page to load if a significant portion of the internet starts working as free of friction as IM does today. Enable that communication to go on over a decentralized system based on open standards and you're talking about a whole new world.