Hmmm... As the author of XEP-0286, I think I ought to chip in a bit.
1) Compression does help keep the transmissions under the FACH threshold on most networks. This more than outweighs the CPU cost.
2) The bulk of the data to be compressed isn't XML, but text.
3) The chattiness of the protocol - ie, transmissions that are not needed at that point in time - will indeed change radio states, but not only did Google tackle this problem privately, but the XSF has also looked at it in detail.
4) Really, the CPU is a non-issue here. It's all about the radio power states. This is likely to be entirely different at the server end, however efficient XML parsers can and do exist to mitigate this, and make it more distributable.
Not sure I'd agree with over-engineered, but anyway.
End-to-end privacy with multi-device support has been specified in XMPP for years; the problem is that it's vastly complicated and therefore nobody ever implemented it.
In part this is because when XMPP was started, people wanted different things from multi-device - they wanted to be able to leave their desktop logged in, move to their laptop, and not have the conversation pop up there - there being no message-read state in XMPP. So instead, the idea was that you'd pull the archive from the server if you wanted it.
Later, Carbons were introduced, which basically says that if the message wouldn't normally come to "this" client, tell me about it anyway.
As for end-to-end... Well, the original RFCs include a method based on X.509 and CMS (RFC 3923). Never implemented. There's been various different concepts since (OTR-esque and XMLSEC based). None has yet got traction, but you'd be welcome to draw a line in the sand and implement one of them.
they wanted to be able to leave their desktop logged in, move to their laptop, and not have the conversation pop up there
Did someone outside the XMPP-bubble really request that?
Why would you possibly want to not see the entire conversation when switching between multiple devices?
the problem is that it's vastly complicated and therefore nobody ever implemented it.
That's what I mean by over-engineered. As a matter of fact no single jabber client or server (that I know of) supports multi-device sync, not even without crypto. I.e. 13 years after its inception jabber (the "platform") still lacks fundamental functionality. Despite tens of thousands of lines of specification and lots of energy spent on absurdities like "transports".
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.
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.
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.
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.
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
1) Compression does help keep the transmissions under the FACH threshold on most networks. This more than outweighs the CPU cost.
2) The bulk of the data to be compressed isn't XML, but text.
3) The chattiness of the protocol - ie, transmissions that are not needed at that point in time - will indeed change radio states, but not only did Google tackle this problem privately, but the XSF has also looked at it in detail.
4) Really, the CPU is a non-issue here. It's all about the radio power states. This is likely to be entirely different at the server end, however efficient XML parsers can and do exist to mitigate this, and make it more distributable.