Instant Messaging wars – and the winner is…

We all suffer daily with the problems of Second Life’s IM chat system, and the issue is pretty simple to explain: SL’s IM is obsolete. Even ICQ, when it was launched as the first ever instant messaging system, had more functionality and ease of use.

Linden Lab is well aware of that, and has long since promised a complete overhaul of its IM system. Not unsurprisingly, many residents frowned. We all know how much Linden Lab loves to reinvent the wheel a few times – but notable exceptions have surprised us in the past, so I wonder if they’ll go the “standard and open-source way” this time, or if we’re just getting Wheel v. 2.0.

The IM Wars of the (recent) past

Around 1999, Linux (and other open-source OS) users were left in the rain when it came to instant messaging. People had to live with clones of ICQ and only dream about sophisticated protocols like MSN’s, AOL’s, or Yahoo’s. They had been around for a while, and, of course, only supported Windows (and the Mac to a certain degree – often with very crippled versions). Worse than that, at those days, it looked like every month would bring us a new IM system, forcing people to create new accounts, download new clients… and get their friends sign up to the “new” service, or continue to use multiple IM clients wasting precious CPU time.

Then suddenly someone got an inspiration. Instead of forcing people to use more and more different clients and protocols, why shouldn’t they go the way email and the Web went a few years before? Separate the client from the protocol from the server. Develop a standard protocol (based, of course, on XML, which at the time was starting to become a serious candidate for a standard markup language), have an “universal” server, let people create their favourite clients with all the bells & whistles and “speak” the standard protocol. On the server-side, to connect to “legacy” services (ie. ICQ, Yahoo, MSN, AOL…), develop “gateways” that exchange information between the standard protocol, and the proprietary ones. As a user, you would continue to pick up your own client – but be able to connect to all messaging systems in the world. Just like the Web or the email system – these days, you don’t need a proprietary browser or email program to access a specific site or send an email to a different network.

The company that developed this magnificent idea is called Jabber and they have released all their work into the open source, back in 1999. It was wonderful for the non-Windows users at that time. They installed the free server, set up a few gateways to their favourite old systems, and could finally chat and even exchange files with their friends on the Windows platform. They could even have a single account but connect to multiple services, both Jabber-based as well as legacy ones. This concept of “multiple-account clients” was later brought up by things like Trillian (for Windows), Adium/Fire (for the Mac), and GAIM (for Linux).

Jabber didn’t catch on. For the users, it was too cumbersome – you had to run your own server, and install and configure it properly (not easy). All this just to be able to chat with your MSN friends? It was way easier to go the other route – develop a set of libraries (GAIM) that integrate into all proprietary protocols into a single client. This has been proved to be quite successful as an alternative. Jabber stayed dormant in the background and was sort of forgotten except by a very few adepts, or for special situations – like for a company’s internal, private chatting system.

XMPP – Jabber’s protocols become an industry standard

But all of a sudden, 6 years later, Jabber is “in” again. Google has announced Google Talk, and, not surprising for Google, ready to adopt industry standards, it is based on Jabber. So, while you can get the client application for Google Talk, Google even goes the nice route of explaining how to configure your Jabber-compatible client to use their messaging system. Better than that. Jabber allows servers to interconnect – so, similar to email, you can connect a “grid” of servers with their own accounts, and interlink them in the “Jabber network”. You just need one client, one account – and a whole network of interconnected Jabber servers is at your service. Google is encouraging this approach.

The legacy IM systems continue to have their own problems. Nobody is surprised. The guys at Jabber just smile. After all, business has been good for them. Beyond Google – certainly the biggest eye-catcher! – they have been working with others as well.

And, of course, Apple, who had a relationship with AOL/ICQ to use their servers for the messaging system, has included Jabber into its iChat client application in Mac OS X Tiger. Again, we’re not surprised. Apple has its ups and downs, and certainly likes to reinvent the wheel, but they have been learning their lesson well. Being different does not mean to do everything differently. It just means doing it differently from Microsoft – and repackaging open source software with a nice graphical interface 🙂 So, bye bye costly AOL partnership. Welcome, free Jabber integration 🙂

The Google push has certainly put Jabber in the spotlights. In my own country, after a month or so, two competing ISPs who also struggle in the content market, have announced that their respective IM systems were actually based on Jabber. This was not a surprise to the technically-savvy, but the companies now admitted it publicly. They felt that if the giant Google is not “afraid” of Jabber, they don’t have to be ashamed any more. Jabber is cool. Jabber is the new buzzword. Jabber will be the “Instant Messaging World-Wide Web”. And, as said, you can still get gateways to the legacy systems. Better than that: these gateways work with the legacy systems even if they don’t want that (the best they can do is shut down IP addresses…).

Personally, I think that the reason why Google pushed Jabber was not because Jabber is better or worse than other systems. They pushed it because it’s an Internet Standard. As the old saying goes, “the best thing about standards is that we have so many to choose from”. Many say that standards are not such an important thing – if something works, why do you need a standard? But standards are the computer scientists’ way of having a protocol open for inspection and suggestion, making sure that lots of people review the protocol and correct its shortcomings. That has always been the way with standards in the past. Look at an excellent example: there is almost no text editor in the world that can open a RTF (Rich Text Format) file correctly without fuss. Yes, it is a Microsoft standard! But Microsoft released the protocol publicly (like Jabber did for XMPP, the IM protocol’s “official” name) ages ago, and that’s one of the reasons you can read and write RTF files from almost any application in any computer or device.

Since XMPP became officially an industry standard in late 2004 or so, companies all over the world started to look at it seriously. After all, you don’t get just the protocol – you get all the tools to run your server and develop your client. For free.

And what about Linden Lab?

Our nice folks at Linden Lab have a dual approach. Like Google or Yahoo, their grid servers all run open-source software – Linux, Apache, Squid, MySQL. The client is based on OpenGL. And Second Life supports some industry standards – RTSP for the streaming, XML-RPC (although crippled) to communicate with applications outside the grid. Most of us expect parts of the code to be released into the open source – eventually. But LL is also very keen to show that they are very stubborn in implementing their own “wheels” (“hey, I’ve got a great idea for a triangular wheel!”). They continuously update them (“wow, here you are, a square wheel – and on 1.8, we’ll even get you hexagonal wheels! They work so much better!”) but fail to achieve the necessary quality to current-date products. LL’s IM is certainly a “1995-look-and-feel-thingy”. It’s totally outdated. But instead of getting rid of it, once and for all, LL only announces that they’ll “fix it” and give us “lots of improvements”.

Well, I’m sure they mean well. But let us be pragmatic. LL simply doesn’t have the required amount of developers to compete with AOL, ICQ, MSN, or Yahoo. This means that our IMs will always lack functionality. Other MMORPGs integrate MSN or Yahoo in their systems, and let people use those messaging systems integrated into their platforms. Of course, they are able to negotiate with Microsoft or Yahoo due to their sheer size and power. LL can’t. So, they have two options: either go with triangular or square wheels (the current approach), or use a freely available open-source solution, and completely forget about wasting precious man-hours on a part of their system.

If Google and Apple – who do have more developers than Linden Lab!! – went the Jabber route a few months ago, why is Linden Lab ashamed of doing the same?

If you have read other entries of my blog, you know that I believe that one of the reasons for Second Life’s success will be how well it integrated into the “legacy” Internet and surpasses it (I would use the word “assimilate”). The first step is being able to transfer grid computation into “external servers” – ie. SL becoming just the “3D browser” to the “object & texture grid”, but the applications can sit anywhere else. Right now, we can use email for that – reminiscent of the 1980s, where you used email to “remotely command” applications (remember, no graphical browsers back then! … and this trend never died. Even today, you subscribe and unsubscribe to mailing lists using this approach). But it was a start. XML-RPC, although crippled, is the second level. I sincerely believe that HTML-on-floating windows will be the next one. But Jabber-based IM is the next thing to do.

Because the answer is simple – if LL’s not going that way, someone is. If you can get a “refreshable” browser inside SL (without the 20-second-refresh-limitation that we seem to have right now on the preview), you can build a much better IM system based on your own Jabber server. It is so much simpler to implement incredible things that it makes you weep while thinking why LL never went that way. And with the ability for objects to communicate through the llInstantMessage() function call, meaning that your objects would be able to send IMs to the wide world of Jabber-connected networks (and gateways reached through that network) – well, the sky is the limit (although I would expect some “delays” to be built into llInstantMessage() to prevent abuse).

But all this is silly – really. It’s so much easier to support Jabber natively inside SL.

And remember the very important side-effect – you would (finally!) be able to IM your friends directly when off-world. Don’t think this is not so important. Most of us have exchanged other IM systems so that we can “keep in touch”. Many of us have multiple-account clients – Trillian, Adium X, GAIM – and we have a uniform way to contact to them all. Except for our friends at Second Life. The best we can hope for is that they have the “Send IM to email” feature on, and understand when they’re getting a reply by email from off-world. But why make it so cumbersome? Why can’t Second Life work like other MMORPGs – an unified messaging system that works even if you aren’t online?

A very interesting side-note for the Mac community is that they would even be able to use their iChat client application (which supports Jabber, as said) with SL. That way, you would be able to have voice and video chat. Inside SL. And now 🙂 That would be a nice touch!

Integration is the key – it has to start somewhere, if Second Life plans to “take over the world”. So, let’s vote on better integration!