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.
My mistake - it is a permitted option. Still, the standard (or at least RFC 3921) encourages servers not to - delivering to all clients is mentioned as the last MAY option, and only permitted at all if they all have the same priority (which given that clients like to do things like lower priority when you haven't been typing for a while, is very hard to achieve).
> XMPP was designed for multiple devices, actually
Be that as it may, it was a lot less usable in practice than any of the alternatives when used from multiple devices.
> Carbons (XEP-0280) does what people want now
Yeah, that's the extension I was talking about. Dated 2010 but I could swear I remember it being discussed in 2008 or earlier? Looks like it may, perhaps, have finally been standardized in 2015? Of course it's still an extension so you can't rely on any given implementation supporting it, though if you're saying it's widely deployed then that's a huge improvement over what I saw a couple of years ago.
> 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).
Be that as it may, it leads to very poor UX. I can have one-to-one conversations with any of my contacts as though it were a peer-to-peer messenger, but as soon as I want to have a three-way conversation we have to pick a server and a room name and .... Heaven help you if you want to add a third participant to a conversation after you've started.
RFC 3921 was superceded by RFC 6121 in 2011. You might want to update your facts before you criticize the protocol.
The message routing rules leave many things to the server implementation, adding a bit of fuzzyness, but all of this has been addressed in Carbons, and really, in the last years there was significant progress in how mobile XMPP works and feels.
as soon as I want to have a three-way conversation we have to pick a server and a room name and...
The modern mobile XMPP apps like Conversations already have a seamless 1:1 to group-chat upgrade mechanism, and people are working on writing down according specifications.
Only if you agree upfront on some kind of "safe subset" of XML.
For example, disabling entity references helps a lot in terms of reducing complexity and protecting from protentially RAM exploding XML documents.
But parsing full featured XML is hard and opens a whole can of worms.
XMPP was objectively terrible (or at least, all the XMPP clients were objectively terrible).
Do you see the contradiction?
Prosody and ejabberd exist. They don't take much hacking to make them very usable - certainly quicker than writing a protocol from scratch.
It's not that it can't be done.
Yes and no. I mean you can argue it's a matter of taste but I don't think anyone genuinely likes (for example) having to right click and go through two levels of menu, type a name, press a button, wait for results, and double-click on the correct one, just to rejoin the groupchat they were already in, every time they lose and regain connection. The line between legitimate differences in preferences and genuinely bad design is always fuzzy, but I do think there's such a thing as objectively bad UX, and every XMPP client I ever saw had it.
> Prosody and ejabberd exist. They don't take much hacking to make them very usable - certainly quicker than writing a protocol from scratch.
I can't speak to the servers. Just to the clients.
Also, people who connect Pidgin to their Gmail and think that is the pinnacle of XMPP experience, but in fact both are severely outdated.
The vanilla XMPP standard doesn't permit a server to deliver the same message to more than one client for the same user. This is utterly wrongheaded and falls apart as soon as you start logging in from multiple devices (e.g. phone + computer, or even just two different computers). This was obviously terrible and has been obviously terrible for decades, but it seems impossible to change it. There is an extension to work around the problem, but extensions take forever to get approved and twice forever to get actually adopted in real clients.
The groupchat UX was always awful, partly because groupchats were never properly federated (they have to live on a single server) and there was no way to do groupchat history for people who didn't keep all their devices turned on all the time (other than, you guessed it, an extension that got stuck in limbo for a decade or so) but mostly just because all the clients sucked. It really isn't hard to do groupchats right: all you have to do is alert when the user is mentioned but not alert on ordinary messages to the group. But somehow everyone managed to screw it up.
XMPP was objectively terrible (or at least, all the XMPP clients were objectively terrible). Worse than AIM. But there were people who were (understandably) blind to its faults because it was open-source, and this anti-synergized with the traditional-unix luddite tradition that rejects anything other than plain text in messages, and the good old standards-first approach that brought us XHTML2.0 and CSS2.1 and a decade with no HTML standard (i.e. trying to standardize everything before any implementation, which never works - what works is allowing clients to add extensions and then standardizing what's been shown to work and become popular, a la WhatWG).
The real issue is that if you try to build an XMPP client that defines something "non-standard" you'll get torn to pieces by the OSS fans. Many of the niche instant messengers are probably running XMPP under the hood, but they don't want to expose it or support federation lest they get accused of trying to "embrace, extend, extinguish".