davecridland

XMPP is routinely used on HF radio and SATCOM networks field-deployed by militaries. It's deployed with channel compression (so the links themselves are compressed), but it routinely operates down to way way below mobile. In general, the really bad links are used for federation (s2s) rather than client connections which demand lower latency for user interaction. I've personally watched it operate on HF radio modems down to single-figure bits per second - those are simplex links with a 30 second turnaround. It's slow of course, but it does work - and this is on the base standard. Any server can do this, there's three I know of in use.

WhatsApp decided, at some point in the past, that XML was too verbose and compressed it using a technique borrowed from WAP - essentially a fixed-dictionary compression. Newer WhatsApp systems don't ever bother decompressing to XML, and it's likely it can't be anymore, but it's fundamentally the same traffic patterns even now. Your WhatsApp account still has a jid (with a very short, fake domain) and so do your groupchats (also a very short fake domain). The WAP compression choice was unfortunate, as it only really had an effect back in GPRS/EDGE days, only on certain networks, and only on certain traffic patterns, because it's the number of packets that matter in most cases, not the number of bytes. There'd still be some rare benefit on 3G, but by 4G the benefit had all gone.

Meanwhile, clients like Siskin and Conversations work just fine on modern mobiles. Conversations (an Android client) does work better when given permissions to keep the sessions live rather than rely on push notifications, but testing has consistently shown that battery life in unaffected. There's a number of extensions that are widely deployed that help efficiency, for sure, and I'd not want to run without for preference - though it is possible, and not as bad as you'd think.

So I'd say that XMPP has no performance problems at all on "long thin" networks way beyond mobile.

To get the same performance out of anything based on HTTP, you need to recode to use the parallel protocols of CoAP and friends. Matrix have done this, but it means specialist clients and servers are needed, and as far as I'm aware there's only a single implementation.

There's an awful lot of "why not?" here. Remember, this is an Experimental XEP. The XMPP Council saw no reason to actively block it, but that doesn't mean we're all mad keen that everyone should rush out and do it.

There was an intense debate on whether it ought to be published as Standards Track or Humorous...

Nice write-up of it, though I disagree that you can (or should) "recover" from a database breach in that way. If you detect a database breach, it's likely considerably after the event, and you should enforce password changes (and TOTP resyncs).

Also, there's no mention of Channel Binding, which adds considerable protection to MITM attacks aimed at obtaining the ClientProof off the wire.

I'd really appreciate more detail, here.

And XMPP has always tried to be the email of IM. Similar model, address format, and so on. A sea of independent, autonomous domains openly connecting to each other.

Agreed, which is why XMPP does this.

I don't buy this. XMPP uses no more than any other IM system, and much less than most. The military use it over HF links in theatre, for heaven's sake - this is not what you'd choose to be doing if the bandwidth was so high. (HF is STANAG 5066, and runs down to a handful of bits a second - this stuff is not fast).

1) XML really isn't that bad. Honestly. It can be (and is) parsed fast, without any schemas at all. The only thing you need to define about your namespace is the URI you're using. XMPP is not SOAP.

2) Wrong. RFC 6122 explicitly permits this. XMPP was designed for multiple devices, actually, but expectations changed over the past decade. Carbons (XEP-0280) does what people want now, and is widely deployed, in real clients and servers. Getting extensions to the "Experimental" state is easy, BTW - it's trickier moving them on from there because it's trickier to change them once they're widely deployed.

3) Bizarrely, you're mostly describing the client behaviour I have on every client I use. As for federation, that's what XMPP does. It doesn't do distribution, because doing that and getting autonomy for your security domain is hard (if not impossible).

4) Saying something is "objectively terrible" when it's clearly your opinion, and then rubbishing everyone who might hold a contrary one, is pathetic. The validity of your position is not helped by the XSF working on live documents for most of the time (the "Experimental" phase). Where it differs from the WhatWG is that specs move out of that phase once they're proven, and the documents become harder to change once they're Draft or Final, reflecting how hard changing all the implementations would be. The XMPP world sees people add extensions, try them out, and then move them to standards all the time. We see that from HipChat, Conversations, and plenty of others - it's a great way to work. Other folks like to get something to Experimental first, and that way get early feedback from the community. We think the way we work is a pretty good balance between stability and dynamism.

5) Absolutely not. That "X" stands for "Extensible" (I know, it was fashionable back in the '90's), and the XML namespaces you despise (and appear not to understand) mean that you can cheerfully slap whatever data you like in and alongside the standardized stuff. Trust me, the (many) IM services based on XMPP - and if it were as bad as you claim, that'd seem a poor choice - aren't refusing to federate because the OSS fans might not like it. Quite the opposite, actually.

Matrix will hit exactly the same problem in a few years. The solution is certainly not to restart with a clean slate every few years and fucks to you if you wanted compatibility. That's Google's approach, where every few years they trash an old service and - maybe - replace it with a new one that works in a different way.

There's no simple answers to this. I can tell you it's absolutely not a protocol issue - the protocol issues are ensuring graceful degradation remains possible during advances, which XMPP does well - but a political one. Profile specifications, which indicate groups of XEPs which the community expects to be supported, are part of this. Certification might also need to happen. Maybe monetary awards, even.

One of the biggest things currently driving server implementors to get the XEP support, and server maintainers to deploy it, though, is folk like inputmice driving the market with Conversations.

Oh, okay - in that case I slouch corrected.

A device-global push protocol isn't entirely useless, since the device OS can wake all the clients at once if it needs to, synchronizing network activity. But I agree it's a significant overhead if you're able to just hold open the TCP session, as well as concentrating yet more information into a single entity you don't get to choose.

So either XMPP is bad because it hasn't changed for years and is therefore old, or else XMPP is bad because there's new replacements for stuff that didn't work so well.

Honestly, there's some days I wonder if there's any way to win.

What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.