Hacker News Reader

Comment by dwdbah | Hacker News Reader

Sure. Much of the Google Talk video stuff was all designed for XMPP; they actively took part in the standardization at times.

WhatsApp is XMPP, fundamentally, in any case.

View on HN

Except there is no way to interface with it on the desktop level.

Yes there is. The maemo/meego community reverse engineered it and created a proof-of-concept java app, and a totally working meego app for the N9. Check their forum for protocol info, etc, but there's clearly enough to create a desktop app (you'll still need a phone to create the account though).

Why is it not utilized more widely then? foregoing for a minute that everyone is cultivating their own gardens - what are the weaknesses of XMPP that would make it so easily avoidable for most of these apps?

It's definitely not the lack of features, since XMPP is extendable. I've heard that the protocol is quite chatty and would cause power drain on phones. That could probably be solved with a binary serialization alternative to XML, though.

Is XMPP asynchronous?

Yes, it is. The very start of a session is usually synchronous (authentication, etc), but after that it is async. Request/response commands have an id value to link the request to the response so it doesn't matter if other data arrives first.

Yeah, there's http://xmpp.org/extensions/xep-0286.html which discusses some ways to mitigate the power issue, but, from what I understand, we never got much feedback from mobile developers about it. In particular there are several extensions which remove the need for a lot of network traffic (capability hashes, roster versioning, stream management to immediately resume a session that got disconnected, etc). The fun part is that 1) a lot of mobile client developers haven't implemented those and 2) most require server support, and Google never added support for them.

As for a binary serialization, XMPP traffic does compress very well already (TLS/zlib/lzw), but we have started the process on standardizing the use of EXI (https://en.wikipedia.org/wiki/Efficient_XML_Interchange).

While the use of XML in the protocol might be considered verbose, stream-level compression from TLS quite makes up for that. With many contacts, the number of presence stanzas might indeed drain the battery because the antenna will be 'up' quite a bit.

However, the XMPP community has been active in quantifying such issues and providing solutions. The beginning of a document with background information is available as http://xmpp.org/extensions/xep-0286.html. There are also various opinions on the topic to be found online, like http://www.deepdarc.com/2008/02/14/mobile-xmpp/, that, as you can see, dates back half a decade already.

The only thing Google actually did fro mobile XMPP was google:queue, which bunches together presence updates such that the antenna efficiency is improved dramatically.

Facebook also have a private extension, as I understand things.

I should actually submit that extension - I wrote it up as a XEP ages back, but various things have held it up.

There are no weaknesses in XMPP. The issue are the protocols on the side, the ones that do video and voice. XMPP allows to chat and create a voice/video session, but:

1) the free protocols to do voice and video are not as good as the proprietary ones

2) it seems that every client use a different set of protocols for video and chat

Reply on news.ycombinator.com