When Jan and I evaluated XMPP in 2009, we found that it was not very mobile friendly. To provide a couple of examples -- (1) The login path required an inordinate number of round trips (I think it was 4+). This slowed down login quite considerably. (2) XMPP is byte verbose and expensive on mobile networks.

We came to the conclusion that XMPP was built for desktop computers connected to strong internet via LAN connections not for mobile networks. We went on to invent our own protocol which was byte efficient and minimized roundtrips.

Now take all of this with a grain of salt. It is now 2018 and things have changed considerably.

> that XMPP was built for desktop computers connected to strong internet via LAN connections not for mobile networks

Oh it definitely was. However, extending it to work well on mobile devices without throwing the whole protocol away turned out to be feasible.

Yeah, I remember 10 years ago (or more), they were looking into ways to make it more mobile friendly, including Roster Versioning (so you wouldn't need the whole series of transactions to get your roster on initial connection), session keepalive (the basic protocol expects one long TCP session, which is of course impractical on mobile), and stream compression.

Sadly, those weren't really enough at the time, and the new protocol Babel happened.

> We went on to invent our own protocol which was byte efficient and minimized roundtrips.

Completely understandable. And well, looking back it was the right decision. You definitely have solid proof.

Yeah as much as XMPP looks good on paper I don't think it will ever take over the messaging world. Even if the devices and the network capacity could handle the larger messages I feel developers don't really want to deal with XML standards. There were a lot of cool things in the 90's but XML wasn't one of them.

XMPP has a terrible user experience, which is why it's never caught on.

XMPP is a protocol; it doesn't have a user experience. Sure, it may have been difficult to adapt for mobile, but that doesn't mean it inherently has a poor experience.

This is silly hair-splitting. If it's "hard to adapt" to mobile then it's the protocol implying poor UX.

Fortunately, in XMPP country, we're always just a XEP away! </s>

It's actually pretty easy to adapt to mobile, it may have been hard in 1998 when it was released, but these days with stream management (session resumption and TLS like packet counting) and message archive management (history and catchup) it's pretty great on mobile. The round trips to log in have also been significantly reduced (you'll incur a few more if you use SCRAM based auth, but there's always a trade off for security), though there are still a few of them for the most basic login. If you ignore TLS (which can come first so you don't have to do STARTTLS anymore) and do PLAIN auth (over TLS so it's fine) I think you have 3 round trips to login. That can be improved in the future with pipelining which has some experimental specs out.

See also: https://xmpp.org/extensions/xep-0286.html

I think it's a valid distinction. You could make the case that a bad protocol makes implementing a solid UX harder, but you wouldn't say the protocol has "poor UX".