Could Instant Messaging (XMPP) Power the Future of Online Communication?
Enterprise collaboration company Jive Software posted today about a theory it's advancing on the rise of XMPP (called Jabber in IM) for powering communication services hosted in the cloud. The company also announced that it will include what it says will be the first XMPP-powered document sharing and collaboration tool in the forthcoming 2.0 release of its product Clearspace.
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.
The changes that XMPP could enable for web innovation in general are quite interesting. "It turns out," writes Jive co-founder and CTO Matt Tucker, "that all of the problems that had to be solved for instant messaging make the protocol perfect for cloud computing."
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.
2 TrackBacks
TrackBack URL for this entry: http://www.readwriteweb.com/cgi-bin/mt/mt-tb.cgi/3176
FOLLOW RWW ON TWITTER
RECENT JOBS
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
The XMPP integration in Android is really interesting, it seems the Google Android team are pushing XMPP as the default communications layer for the mobile OS.
The web is crying out for a standardized push solution. HTTP hacks created to push data to clients are overly complex and resource intensive.
I think Matt Tucker is right on the money.
Posted by: Craig Baker | January 24, 2008 8:23 PM
"The web is crying out for a standardized push solution."
Absolutely. I hope this was wrapped around the http models so we did not have to deal with extra ports. Unfortunately Jabber so far seems too clunky to mesh well with the browser. I hope it gets better.
Posted by: Joseph Pally | January 24, 2008 9:46 PM
It's been interesting to watch everyone's reaction to Matt's assertion. Some of the comments I'm seeing on Digg and the Jive post appear that people think Matt is suggesting XMPP replace HTTP, which is not what he's saying. He's referring to it as the protocol of choice for services that require two-way communication. No need to replace a one-way protocol where it's called for, such as downloading a page. Marshall gets it right when he ponders if it is the future of online communication, not as a replacement for all other protocols used for services that don't require a dialog.
Posted by: Justin Kistner | January 24, 2008 11:55 PM
I rarely leave comments like this, they add no value, but this had to be said: fantastic blog post.
Posted by: Stefan Constantinescu | January 25, 2008 1:37 AM
I reckon there is huge potential for the use of XMPP on the Web. Quite a few Web systems simulate push - why not just use push where appropriate? Wherever URIs are used as identifiers (which is perfectly viable in XMPP data), compatibility with the Web is possible. However I do think that to exploit the potential we need to get beyond thinking of the Web in terms of HTML in the browser, and the whole client-server architectural view. Personally I suspect the old notion of agents is probably an appropriate abstraction for 21st century web development, except reworked for the linked data model of Semantic Web technologies.
See also: Graph Farming (pdf)
Posted by: Danny Ayers
|
January 25, 2008 1:39 AM
Since Google-acquired Jaiku microblogging platform using XMPP and since Google Android team incorporated XMPP into the source code of Android Mobile OS, XMPP may dominate the future online communication.
Posted by: k.s.reddy | January 25, 2008 2:24 AM
I wanted to chime in and agree with the comment Justin made -- I'm not proposing that XMPP replace HTTP by any stretch. :) But, I do think that there's a class of applications like cloud computing where HTTP is running into architectural limits. Still, Marshall gets it right in mentioning the many hurdles that would need to be overcome before truly widespread adoption of XMPP for this use case. Until then, I think there will be more and more individual services created when the pro's greatly outweigh the con's -- as was the case for the cloud features we're building into Clearspace.
Posted by: Matt Tucker | January 25, 2008 3:38 AM
ISS (Instant Syndicating Standards) is a set of open standards that blends the Web and the XMPP in an elegant way. It maps identities and information exchange in both these worlds.
Posted by: Nick Vidal | January 25, 2008 4:30 AM
Nick, that's really interesting! I didn't know about ISS and just wrote this post . I haven't checked it out yet but ISS seems to be similar to what I was thinking of.
Posted by: Martin | January 25, 2008 5:37 AM
(your openid login thing isn't working, at least for livejournal ids)
Couple of things - first, the key benefit for IM isn't XMPP or protocol definition, it's the inclusion of presence in the experience. The key benefit of this change will be that authentication, and theoritically cross-network communication, will be easier now for AIM users. For example, google's IM uses XMPP, so if the authentication works as documented, you should be able to add AIM contacts in your google IM now (I haven't tested this.
IM bots, or automated clients, have always been "just over the horizon" so to speak, given that nearly everyone uses IM in some fashion, but never has really taken off. I wrote a framework to make bots easily years ago (link on my name above, I think) and it still gets downloads every day, but the people using it are usually hackers trying to do something different, but with little potential. I did make some IM games using the bot for a couple of movies a few years ago, but once again, it never got as viral as anyone hoped. And it was tough to get MSN and AIM to clarify if they would even allow it or not.
I'd look at this as validating a standard, but little else. Nothing new is possible with this change that wasn't possible before (or easier for that matter).
Posted by: Duncan Lamb | January 25, 2008 6:27 AM
It would be nice to see something like RSSPing using XMPP.
http://www.rssping.com/
Posted by: andy simmons | January 25, 2008 8:13 AM
Integration of XMPP and the web holds a great potential for end-user applications as well, especially when you make XMPP a first-class citizen in the browser—have at look at the paper of the presentation I did at XTech, "Real-time user-to-user web with Mozilla and XMPP", or at its implementation in SamePlace shared apps.
Posted by: Massimiliano Mirra | January 25, 2008 11:52 PM
Nick, that's really interesting! I didn't know about ISS and just wrote this post.
Posted by: bedava oyunlar | January 26, 2008 4:14 PM
This is indeed a very nice article! And I think the keyword here should indeed be 'agents'. As we are moving towards autonomous (semi-)intelligent agents we need solutions like XMPP!
Right now I'm building a non-intelligent Twitter service and the only way to do that is integrating with their Jabber bot. This is the first step of machines communicating with machines communicating with humans. I will do an extensive and detailed writeup of how I built this service at the end of this week (with all sourcecode).
The web is indeed screaming for synchronous solutions, that's why we have hacks like JSON, AJAX-polling, juggernaut (javascript push through flash). But I think XMPP for the time being will be used for the rather tightly integrated systems like agent-2-agent, although it is not unthinkable that things will start sprouting in the browser/server space.
Bottom line is that solutions like this are a given when moving from a reactive web to a proactive web!
Posted by: Dominiek ter Heide | January 27, 2008 9:22 PM
hi there, my trackbacks does not work. just would like to say thanks for this plugin, appears on my “must-have” list
Posted by: Aşk şiirleri | February 7, 2008 10:27 AM
Prima Sache! Man kann auch einfach einen anderen Nutzernamen eingeben und bekommt dann dessen Fotostream.
Posted by: msn nick | February 7, 2008 10:28 AM
Nick, that's really interesting! I didn't know about ISS and just wrote this post.Thanks
Posted by: Oyun | February 7, 2008 1:48 PM
receiver magazine -at the intersection of communication technologies, pioneer thinking and digital playfulness
See more under: http://www.receiver.vodafone.com
Posted by: sascha | February 10, 2008 11:05 AM
ty admin
Posted by: Msn nick | February 13, 2008 11:22 AM
Here's a practical followup on this story:
http://dominiek.com/articles/2008/2/15/how-to-build-a-twitter-agent
Posted by: Dominiek ter Heide | February 15, 2008 3:25 AM
thanks admin
Posted by: Hicran Dizisi Kanal 7 | February 16, 2008 12:18 PM
thanks admin veri nice
Posted by: Hicran Dizisi Kanal 7 | February 16, 2008 1:25 PM
thank you rww :)
Posted by: sinema izle | February 16, 2008 5:56 PM