Live pains on sight...

There have been scarce mentions of the rollout by LiveJournal of an XMPP based instant messaging service. Beyond the expected voice, I have found very few references to the announcement outside the community, and when they were, they had very specific topics of interest.

…the absence of smart integration between applications and XMPP servers is a major bottleneck to a wide adoption of XMPP…

This is somewhat of a concern, as the expected viral endorsement of XMPP is still far from taking off. Obviously, any smart and business savvy community wanting to offer instant communication to its members is better of choosing XMPP as a protocol, rather than developing its own. Google did it, and I have previously exposed some of the business drivers behind this choice. The same applies for LiveJournal. But beyond the marketing numbers claiming an additional 10 millions XMPP users, what is the reality.

LiveJournal has taken a clever approach to managing its IM users’ rosters, which is very similar to what is found in corporation. They have come up with a very controlled process leveraging the existing user base, taking an integration perspective. This is in my opinion the reason why they created their own XMPP server, rather than adapt an Open Source one. I believe the absence of smart integration between applications and XMPP servers is the weakest point of the current wave of Open Source servers. And it is a major bottleneck to a wide adoption of XMPP as an application messaging transport, much more than reliability. Application integration is not about allowing low level access to a database or a directory, which is the bare minimum a server must provide. Application integration means enabling server to servers’ communication at the application level. In the current Internet context it translates into making XMPP servers natively understand HTTP, and Web server have integrated XMPP transport.

LiveJournal is rolling out its own vision of XMPP. I understand perfectly the need for different communities to leverage their own specificity, but I also believe it must always be done without lock-in. Give an end user all liberty to leave at any time, taking with her all her belongings, and you will keep her for as long as you whish. Base your service on wrong assumptions, or tweak the standards, and you create an uneasy feeling. Creating an uneasy feeling is exactly what this statement is doing:

We have SSL support, but we're not enabling it, at least not right away, but the auth is challenge/response w/ anti-replay stuff in it, so people can sniff your conversations, but not your login info. So SSL isn't required. With iChat, you have to explicitly turn it off. Justification: lot of CPU overhead for little gain, especially as clients often use OTR for end-to-end encryption.

Support of TLS is one of the soundest requirements of XMPP. The argument for not using TLS are very light.

• Mentioning CPU overhead is irrelevant with today’s workstations. On mobile clients it could have an impact though. With the concurrent connection figures announced for djaberd, I have the feeling the issue is more about server side scalability. Without TLS, connecting to the LiveJournal service from an OpenSource client will create another of these “unnecessary pains” Justin has been rightly moaning about recently.
• The second issue resides in naming OTR as the justification for not using TLS. In the current state of XMPP, this is simply an error, and will remain so until we have enough clients supporting JEP-116 in the loose. And even then, end-to-end encryption will by no mean be a reason not to use TLS.

Creating islands in the communication space is a sensible and realistic approach. But reducing the inter-islands permeability to the lowest common denominator is still legacy thinking.

Technorati Tags: XMPP, Jabber, Interoperability, LiveJournal, Antecipate