• First generation: was done on a single processor, usually for process control in military systems.

• Second generation: within a Local Area Network, usually for a financial trading room.

• Third generation: applied across the whole Web/Internet, what we call the real-time Web.

In each generation a stack has emerged, and secure messaging has been key to that stack. The names change and the scale of the prize and challenges certainly changes, but the basic issue remains the same: delivering messages reliably and quickly. In this post, we trace the steps from the second generation to the third generation to see how the real-time Web might play out.

Generation 2's Winner: The Teknekron Information Bus Story

I worked with the technology's second generation. My company took on the challenge of delivering market prices from multiple sources to hundreds of traders in a trading room, enabling new apps based on real-time calculation. The solution had to scale to maybe 2,000 traders, which is laughably small by the standards of the real-time Web. But you did not want to face a roomful of furious traders if your system was down for three minutes or delayed prices by 15 seconds. The reliability and latency requirements were very stringent.

The company that emerged as leader, Teknekron, coined the term "Information Bus." It did very well by coining the term, because it established Teknekron as a market leader; it followed the "get mindshare first, and then go for market share" strategy. Vivek Ranadive, the visionary founder and CEO, describes in his 1999 book "The Power Of Now" how the term came to him. He was schooled as a hardware engineer and was appalled by how much more chaotic (i.e. error- and delay-prone) software projects were compared to hardware projects. Looking at why, he realized that the concept of a "bus," which is the device that all hardware components connect to, could be applied to software.

Ranadive understood that real-time, event-driven systems would not be limited to financial trading, and he executed brilliantly on that insight. He sold Teknekron to Reuters, the company's main rival in trading systems, but retained the right to use the technology outside of financial markets. That offshoot became TIBCO (The Information Bus Company), which at the time of writing is a publicly traded company valued at $1.6 billion, with annual revenue of over $600 million.

But TIBCO did not leverage its position to dominate the third generation. Another company tried that and blew a lot of money in the attempt.

KnowNow: Lessons of a Blow-Out

KnowNow worked through $50 million in funding before throwing in the towel in July 2008. It was going to update the message bus to the Web using RSS. It was still an enterprise play.

It had a strong management team, top-tier VC (Kleiner Perkins), and strong technology. Why did it fail? Three big reasons stand out:

• Generation 3 is a tougher technical challenge. Generation 2's state of technology was perfect for local area networks using Ethernet, where the user device was always connected and where we measured users by the thousands. With generation 3, we are dealing with millions of users who are offline some of the time, and the network bandwidth available for messages is not under their control. In other words, it is one big bear of a technical challenge!
• Companies are reluctant to invest millions of dollars in closed software when open standards clearly always win on the Web. Companies can instead experiment very cheaply using consumer-centric RSS tools and open source.
• KnowHow was early. The hype on real-time enterprise did not last long enough, and it hit the trough of disillusionment.

Contenders for the Real-Time Web Message Bus

We have probably missed a few, so please tell us about them in the comments. These are very different types of solutions, but they are working towards a similar objective. First, we will list them and then attempt a bit of categorization:

• Gnip: an independent venture whose monetization model relies on it being a hub that different sites can connect to.
• Tornado (FriendFeed's Python-based Web server technology, which was open sourced by Facebook): this uses PubSubHubbub.
• RSS Cloud: promoted by Dave Winer, with WordPress as a marquee partner.
• PubSubHubbub: promoted by Google (and FriendFeed/Facebook), with SixApart as a marquee partner.
• XMPP The technology with which IM clients interoperate. Being used by Yammer, Present.ly, and Drop.io.
• Twitter.
• Facebook.
• TIB: an enterprise solution from TIBCO.
• MQ: an enterprise solution from IBM.
• Sonic: an enterprise solution from Progress Software.

Here are the categories they fall into:

1. Enterprise
   TIB, MQ, and Sonic all fall into this category, and there are more. They will find it hard to make the transition to the real-time Web for two reasons. The first is technical. Connecting millions of users over a low bandwidth network via HTTP is very different from connecting a few thousand users over a corporate network. The second is commercial: they monetize by selling licensing fees to enterprises. But that is not the primary way in which the real-time Web will be monetized. Still, these are big profitable companies with the right tech chops, so they cannot be dismissed.
2. Open source and open standards
   Tornado, RSS Cloud, PubSubHubbub, and XMPP fall into this category. They have differing purposes but also a lot of overlap. XMPP is low level and not affiliated with any big company. RSS Cloud and PubSubHubbub are most similar to each other. Tornado is a Web server. But they all face the issue that an open standard takes a long time to evolve and consolidate into a winner. Before that happens, we will likely see more entrants, making the choice even more confusing for developers. So, developers may hedge their bets and go for commercial/de facto standards.
3. Commercial hub
   Gnip is the purest example of this. It aims to get traction by being simpler to implement than the open-source/open-standards offerings. It is a bold strategy from a strong team of entrepreneurs and investors. For something as big as this - basic plumbing for the Web - it feels like a bit too much reliance on one company.
4. Traffic plays
   Twitter and Facebook are the major players here. They might become de facto standards because the biggest issue is traffic. Developers will build where there is traffic as long as two conditions are met:
   • It works technically (i.e. latency at scale). Twitter has some credibility issues here.
   • It is open and transparent - i.e. anyone can connect without fear of the game changing on them. Facebook has some credibility issues here.

The Technical Challenges

First, we have to address the question of "What does real time mean?"

In each generation, the gurus of the previous generation get sniffy about the definition of real time ("What do you mean one second is real time? We measure in micro-seconds!").

It depends on the usage case and technical possibilities. Real time within a single processor is obviously faster than real time over a LAN, which is faster than real time over HTTP for the whole Web.

Real time, practically speaking, means "orders of magnitude faster than how data has been delivered in the past, and faster than most people think they need today." So, RSS Cloud is faster than RSS, and Twitter search is faster than Google search, and IM is faster than email.

In generation 2, the thinking evolved through three approaches:

1. Polling. It soon became obvious that this would not scale.
2. Broadcast, which put too much load on the client.
3. Multicast, which became PubSub.

Most current Web HTTP-based real-time systems are still in the polling phase (i.e. subscribers poll publishers to see if they have an update), which clearly won't scale. The newer approaches fundamentally enable a publisher to say, "I will tell you, the subscriber, when I have an update, so you don't need to poll me." It's a geek's way of saying "Don't call us. We'll call you."

For a good technical primer on how this works and a discussion of the differences between RSS Cloud and PubSubHubbub (mercifully shortened to PuSH), check out this post.

Sticking My Neck Out to Guess the Winner

Twitter. Why? It has the traffic and is open and transparent enough to win confidence. But two big problems remain:

1. It has to reveal its business model. Only then will partners feel confident that they understand its strategic direction.
2. It has to prove it can get good latency at scale. Its early history of fail whales makes people justifiably skeptical.

The winner will likely be the platform that hosts the killer app. Most platforms get traction through a killer app. In the second generation of real time, that killer app was market data for financial traders. What will it be in the third generation? We will explore this in a future post.

What to Name This Generation?

"Message/Information Bus" worked for generation 2. It took a key concept from generation 1 - the hardware bus - and applied it to a local area network.

That does not work so well for generation 3, the real-time Web. For now, we talk about a Web-wide real-time message bus because there is no better alternative.

The new term may have something to do with "status," because the status update is a central concept in social media. Perhaps something like "StatusFabric" or "StatusNet" or "StatusWeb" will emerge.

Hemlock joins services like Notify.me (our review), Urban Airship (our review) and others in offering developers a way to get hip to the real-time, just like the big guys at Facebook, Twitter, etc. Some of these implementations are open source, like Hemlock, and some are not. It's clear though that the developer world is ready for some real time technology to build on.

On the downside, it's just for Flash. Flash is more than popular enough, though, so we suspect this will fill a real need. Given that it's open source, forking the code to tie the XMPP part to other interface methods doesn't seem unlikely either.

If you'd like a refresher on the basics of the real time web, check out our Intro to The Real Time Web.

Using Particls with Twitter:

For Twitter users, just follow @particls on Twitter. To track something, start your request with 'd particls.'

Example:

d particles follow "web 2.0"

will track all references to "web 2.0" on Twitter.

d particles follow "web 2.0", "web 3.0"

will track all references to "web 2.0" and "web 3.0"

Using Particls via IM:

If you would rather use your instant messaging program to be alerted about your tracked keywords, you can do so with any XMPP client, including Google Talk. To get started, just follow particls@particls.com. You can then use the following commands to begin tracking keywords:

follow "web 2.0"

will track all references to "web 2.0" on Twitter.

follow "web 2.0", "web 3.0"

will track all references to "web 2.0" and "web 3.0"

Will a Simplified Service Save Particls?

For whatever reason, the original RSS tracking and alerting service provided by Particls never quite caught on. Perhaps it was just a little ahead of its time. The service aimed to help us address our RSS/information overload issues before some of us even had any to address. But the concept behind the service was solid: a desktop ticker, instant prioritized alerts, easy sharing of RSS items, simple feed subscriptions, and so on. In fact, that version of Particls sounds a lot like one of our favorite desktop apps today, Snackr, which does many of the same things but launched nearly a year later.

We thought Particls 1.0 was a good first attempt at managing those sorts of issues, but it was not without its problems. The program was a Windows-only client, had some UI challenges, and, from personal experience, hit an older laptop's CPU just a bit too much.

Later, the company split the Particls solution into half, with one half becoming Engagd, an attention management engine, and the other half becoming Particls 2.0, the visualization and alerting engine. From the sound of it, those two projects have now been abandoned - the company notes that all resources have been diverted to the new project, Fountain.

Oops, a DM Limit

Unfortunately, there is one major concern regarding the new service, and it's not really Particls' fault. Currently, Twitter API limits direct messages to 5000 per day for whitelisted accounts. That will severely impact what the service can do using DMs.

Here's a video of Chris pondering this issue:

This API limit is a clear example of the sort of thing a company would gladly pay Twitter for access to, if only there was the option. It's unfortunate that Twitter's hard-set limits are actually affecting the abilities of other companies to innovate around the core product.

Yet that won't stop them from trying. For the record, Particls is not the first service to attempt to implement the missing Twitter Track feature. For example, the Twitter toolkit from TweetLater also provides this functionality. However, the difference between the two services is that TweetLater provides tracking via an emailed digest - not real-time alerts as Particls does.

Will Fountain be a Success?

Whether Particls Fountain will succeed where previous incarnations did not is something that's yet to be seen. However, the company is now actively working with the community and letting them drive the development. This critical step is vital to making a successful product, so it's encouraging to see the interaction.

Through the UserVoice site, 100 or so testers have already begun providing feedback about Fountain. They - and you - will be the people voting on the next step for the service, whether that's tracking your alerts history on the web, receiving an email digest, adjusting alerts through a web-based dashboard, or something else entirely.

If you want to give the service a try, you can do so today; just follow the instructions above. Besides UserVoice, you can also give feedback directly to the creators of Particls on Twitter: just follow @ashleyangell, @stephenkelly, and @chrissaad.

Pull: RSS

Traditionally, RSS readers pull feeds at a regular interval (usually somewhere between 15 and 60 minutes). In a real-time world, that, of course, is far too slow. Services like FeedBurner introduce even more lag into this system, so that it can often take half an hour or longer before a new post appears in Google Reader. Notifixious itself polls every feed about twice an hour.

Pull Smarter

Thanks to FriendFeed's new Simple Update Protocol (SUP), some of the heavy lifting of regularly polling thousands of RSS feeds can be reduced, but as of now, only a small number of services actually support this new protocol. Notifixous also monitors the public activity of ping servers, similar to what PubSub is doing with its new (though still unreleased) product.

Push: XMPP

Currently, Notifixious can only get 'real' real-time updates through XMPP from Identica, Seesmic, LiveJournal, and Sixapart's TypePad and Vox blogging communities.  Genestoux notes that he would like to see every content provider use XMPP in the future.

Giving Back: Can Notifixious Replace Gnip's Abandoned XMPP Project?

Maybe the most exciting idea here, however, is that Notifixious plans to share an XMPP and SUP feed with the rest of the community. Gnip, of course, at one point promised to do something very similar, but, in the end, pulled the plug on this project.

Other companies like ZapTXT or Pingie offer a similar service - though we have also seen far too many promising services like Rasasa or Immidi.at close before they could ever live up to their promises. Our experience with these services has been quite mixed, however. We will have to wait and see if Notifixious can deliver on its promise.

Notifixious' Service Right Now

As for the Notifixious service itself, the company will send its updates to your cell phone, IM account, or email address. You can sign up for feeds individually, or import an OPML file.

If you want to send your own real-time updates from your blog to Notifixious, you can use the company's plugins and widgets for TypePad, Vox, Blogger, MovableType, and self-hosted Wordpress sites.

As an alternative, Heuer proposes to use a decentralized network based on XMPP, where data is only exchanged between friends and transmissions are encrypted. One might argue that XMPP still relies on servers, though it is surely a more decentralized system than the monolithic reliance on one service provider.

The talk mostly focused on the technical and privacy aspects of sharing semantic data like Friend-of-a-Friend (FOAF) information through an XMPP network, but it also introduced the Diki bookmarking and tagging application, which you can download and start from here.

Diki

Diki is the first implementation of these ideas and is available as a Java application that allows you to create a new account, import your delicious bookmarks, rate your friends' bookmarks, and which automatically encrypts your communication by using the OpenPGP standard. It's clearly still a prototype, but it raises a lot of interesting questions.

If you want to delve deeper into this topic, you can download the presentation here (PDF), or read the actual paper (PDF). If you have some bandwidth to spare, you can also download this presentation and all others from this week's Chaos Computer Congress from here.

XMPP/Jabber, the Open Source real-time communication protocol popularized by Instant Messaging that many have hoped would serve as foundation for a real-time web of the future, has become too much trouble to support and will no longer be a supported protocol at Gnip. More than just one protocol, it's a story of long tail developer communities and the ambitious startups forced to make resource decisions.

Marcoullier says there are simply no open source Jabber servers that are capable of the kind of robustness that a social media ping server requires. If a major vendor came to Gnip and said they wanted data streamed to them exclusively in XMPP, the company would continue the practice, but the long tail of tiny consumers that want their data that way is taking up too much resources. The company's top priorities are data delivery and maximizing the number of publishers participating in their program.

Our top priority as industry watchers is to cheer for radical innovation online, something that is in some cases more likely to come from the marginal developers making up the Long Tail that Gnip is herein limiting its support for.

Does This Matter?

This move may be less significant than it seems, though, too. The real-time communication experience is still available via basic Restful push, Marcoullier says, but for now XMPP in particular will be turned off this week.

When Gnip launched, we thought that XMPP in particular and protocol transformation in general were key to its value proposition. Months later, the company says that there is data normalization occurring but no protocol transformations are being performed.

Gnip now has a total of five developers, most recently adding enterprise data specialist Michael Barinek onto the team. The company has significant momentum even if today's announcement feels like it's losing some sexy sheen.

We hope that Gnip can continue to advance its goals of making the social web faster and more scalable. While we're disappointed that this hyped protocol is giving them too much trouble, we hope that a future web of real-time communication can come to us promptly none the less.

As for the protocol Jabber, it is used in many messaging products on the Web - from Twitter to Google Talk to Meebo, and more. It's also used to make AOL's AIM, Yahoo Messenger, and Microsoft Windows Live Messenger interoperable. To explain more about what Jabber the protocol is, here is an extended excerpt from a post Marshall wrote in January:

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.

See discussion around this on the post Could Instant Messaging (XMPP) Power the Future of Online Communication?.

It's standards based, it will bring real-time "presence" to social networks unable to invest the resources to build out the feature for themselves and it sounds like a very good idea. None the less, we do have some concerns about how much social graph, user activity and advertising data Meebo is about to get its hands on.

Prelaunch partners in the initiative to date include PopSugar, Tagged, Pixo, Addicting Games, The Insider (CBS), DanceJam, Flixter, MyYearbook and SparkArt. Readers may not have heard of many of these services (unless you've been spammed by Tagged) but several of the sites do have significant user numbers.

Meebo hopes that by announcing the service now they will amass more partners before launch in Fall. The company says that though social networks have an unusually high average "time on site" between 20 and 30 minutes - Meebo numbers are dramatically higher. Chat sessions tend to stay open for between 2 and 3 hours each, the company says. Meebo says its 1 year old "Rooms" feature, group chat sessions with media sharing and embeddable in HTML web pages, now see an aggregate 28 million unique users each month. That's an insanely high number that could grow substantially when 1 to 1 communication is rolled out across partner social networks.

Partner networks will be able to choose whether to allow their users to chat with contacts on other IM networks from inside their sites. In other words, you may be able to hang out at Flixter and talk movies with friends from your AIM contact list who aren't on the site at the moment. We hope that the networks will choose to enable this much open communication and Meebo says that at least a few have already said that they will.

Who's not in? The stuffed shirts at LinkedIn won't be able to ping eachother instantly with business questions, they aren't taking part in the campaign so far. Neither is Ning, home of enough niche social networks to choke an army of horses. We'd like to see Ning go Meebo, but they are one of the few Web 2.0 startups on the market that's raised more money than Meebo already. Ning has raised $60 million, Meebo $30 million plus (VentureBeat).

There's More Money on the Table

These partner networks will share in the revenue served up by Meebo inside the chat window.

Meebo had a "come to Jesus" moment in April when it made a new hire and announced that it would be moving towards offering uniquely useful, crowd-pleasing advertising. We don't know how sophisticated this new advertising is really proving to be, but we stand behind our statement in April that cynics questioning the company's gargantuan valuation of $200m+ are wrong. Meebo is rocking the market and this new campaign is only going to make that more true.

Show us an infrastructure play that's based on open standards (Jabber/XMPP in this case) and we'll show you an innovation that we're excited about. IM is truly one of the most engaging features of the web and we expect that the users of many niche social networks will be excited about this partnership campaign.

What About User Data?

The one question we have about this otherwise fantastic sounding idea is this: is Meebo going to get its hands on too much user data? By powering IM across a list of social networks and being the choice for chat on AIM, Yahoo Messenger, etc. for millions of people - Meebo is going to have a great picture of who is friends with whom and exactly where.

The company told us that the open standard XMPP/Jabber makes this less frightening than it might be, but we're not so sure. Meebo will likely have a great deal of knowledge about all our "social graphs" as well as the user and advertiser activity on all the sites it partners with. Will users rise up and demand data portability? Will second tier social nets guard their traffic and ad data? Don't bet on it. We hope that the developer community will at least call loudly for Meebo to open up user data to it, so that innovation can spring from the company's huge store of information.

In the mean time, here comes a really great chat experience in a whole lot of new places.

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.