To this day, XMPP is a bandwidth-hungry, unreliable mess of a protocol. Despite the enthusiasts having an XEP they can flash for every objection, the sad fact is servers and clients support varied subsets of XMPP, and it's a rare day when everyone involved supports all the features everyone wants to use.

The author seems to think that XMPP is qualified to compete with WhatsApp. While WhatsApp recently abandoned several platforms, for many many years they had even S40 (dumbphone) support. I tried to find XMPP/Jabber clients for S40 phones for YEARS, and every single one I found would immediately crash with OOM errors.

It's easy to blow off complaints like mine, because everyone on hackernews has a Samsung Universe S2000 or an iPhone 128 Plus, but these are real concerns that real people have in the real world. Wholly aside from network effects, even nontechnical users said "why do I need a smartphone to send text messages?" and "because XML" is not going to convince them.

XMPP is just a bad protocol, a holdover from an era where gleefully wrapping everything in XML was the new hotness. I hope we're moving past Global XML Obsession, and I hope I don't have to hear XMPP evangelism once we get past.

I use the Android client with a personal XMPP server based on Prosody and I frequently use it to communicate with a friend who is also running his own XMPP server and the experience is very good. We never lost a message, we can share pictures just like in WhatsApp, we can send any type of file and the battery usage is unnoticeable.

It seems to me that the people who bash XMPP are people who never actually used it and they are just echoing myths from the last decade.

That's my take as well. At this point "XMPP sucks on mobile" seems to be just an outdated meme that keeps replicating itself, but has little actual relevance.

In the interest of productive discourse, I'm not going to react to the suggestion that I'm an ignoramus who just parrots ancient usenet posts. I'll merely mention it, because I want you to understand that this sort of response does not provide for a discussion of the technical merits of a communications protocol.

Yes, XMPP advocates are continually providing anecdata about how wonderful things have been lately. My problem is that I've been running XMPP/Jabber servers for over a decade, at several different institutions with wildly varying deployment needs... and not once has it ever been a good experience. The failure modes vary, it's true. Sometimes it has been a matter of sheer bandwidth consumption, such as communications over satellite uplink. Sometimes the problem has been interoperability across a federated network. Sometimes the problem has been with specific clients, both commercial and FOSS. But there have always been problems. There are other protocols and solutions that have been far less painful to run, but this is not a discussion about $protocol, it's a discussion about XMPP.

Honestly, I'd rather see XMPP win. The best-case deployment scenario for it is miles above the best-case for most other protocols. But every time someone brings up limitations, the drumbeat starts: "we're working on an XEP for that, implementation coming soon" "you're just rehashing complaints from five years ago" "this wouldn't be a problem if you'd stop using $server_one and switch to $server_two" "that client doesn't work with $server_two, change the client" ad infinitum.

Yes, people have been bashing XMPP forever. http://stpeter.im/journal/1384.html

The XMPP protocol is quite qualified to compete with WhatsApp, considering they are using XMPP (with some custom non-standard compression).

XMPP is a fine protocol. Just because a bunch of people has been chanting "XMPP is a just a bad protocol" over and over does not make it true.

I also don't really get the fucking obsession with 'xml sucks'. Like most things, it has its uses, and abuses. The fucking hoops people jump through to make something like JSON work even halfway as well in particular scenarios are a joke in and of themselves.

- There was no real alternative to the web. - More importantly, ie6 worked for the end-user. It only sucked for the developers.

MSIE worked for most people. The devs suffered how bad it was, but the people didn't see that because most of the web was designed for it. That's the kind of power you get when you are lead in marketshare. We see that nowadays with websites that only work in chrome (though it's less of a problem, chrome is a lot more open to standards, and the engine is open source).

Concerning branding, I still see a lot of people that think the internet is that "e" icon on their desktop. Other people think chrome is the only gateway to the internet. It's the same situation as when IE6 was the lead. People don't know about alternatives, or don't care. Either way, if their "internet app" sucks, it's generally that internet sucks.

[0] Using https://www.w3counter.com/trends as a source, don't know how accurate it is but it does match my memory of how it all happened.

That was largely related to large install bases in corporate/government/educational institutions where legacy requirements (e.g. we built/bought this IE-optimised internal mission-critical web app, and it shits its pants in other browsers).

> It's only when chrome started doing very aggressive advertising that people started to switch.

In 2010 Statcounter and W3 counter both give MSIE ~50% and Firefox ~30%. There was huge shift away from MSIE long before Chrome existed, and longer still before they started using shitty tactics to 'encourage' people to change from other perfectly functioning modern browsers.

> It's easy to blow off complaints like mine, because everyone on hackernews has a Samsung Universe S2000 or an iPhone 128 Plus, but these are real concerns that real people have in the real world.

I am using Conversations with my family and friends on a prosody server I put on a kimsufi server. It works like a charm, and we don't have all super awesome android phones (but I have to agree, nobody has an S40. Do they even exist anymore?).

I think your experience is outdated and not correct anymore.

Maybe not S40 exactly but there are still plenty of "dumb" phones.

It was only 3 years ago that smartphones started to outsell dumb phones [0]. In America, there are still ~24 million "dumb" phone shipped each year [1].

They are still around, people do still use them.

[0]: http://techcrunch.com/2014/02/13/smartphones-outsell-dumb-ph...

[1]: http://www.techtimes.com/articles/157114/20160510/u-s-flip-p...

Not to be confused with the Honda Galaxy S III

2) Managed services are easier to use, and can deliver a better user experience than having to learn how to do everything yourself. I don't think anyone disagrees with that.

I don't think it follows that picking a subset of xmpp and building on that makes for a poor chat experience. Apart from "actual" xmpp/jabber services working just fine, Google talk and Facebook chat both worked fine with open xmpp clients.

The secondary reason is that I never said anything about easier to use or even better experience -- I talked about the fact that WhatsApp worked at all on j2me devices. And for the record, I only even mentioned WhatsApp because the original article in question brought it up in the very first paragraph.

As for gchat and facebook chat, I'm not sure 'arbitrarily yanked out from under users' is "worked fine." See my other comment for the classes of problems I found with "actual" xmpp/jabber...

The CRIME attack demonstrated that compress-then-encrypt fails to provide confidentiality if it mixes confidential data with attacker-controlled data.

In https, it is possible to enumerate certain headers, or other predictable data - session cookies in particular. How would you leverage the use of compression to attack xmpp?

[and rate-limiting logins, obviously, as well as 2fa etc]

The problem with OOM was actually pretty common for J2ME apps in general, because of how widely the phones differed in their specs, and how little heap they often exposed to J2ME.

It is open and federated. Compared to XMPP it is overweight a bit, but at least it has sane mobile and browser clients and keeps all history in sync out of the box.

So.. no?

https://news.ycombinator.com/item?id=11826855

And Vector is pretty great too. I had the pleasant experience this weekend of making a new chat room to persistently share photos with relatives this weekend using it. And the Android client is really solid as well.

And Conversations is pretty great too. etc...

If you like XMPP's philosophy of passing stanzas around, XML and XEPs, then use XMPP. If you like Matrix's philosophy of eventual-consistent synchronising conversation history, JSON and a monolithic spec, then use Matrix. Different tools for different jobs.

It's like SMTP and NNTP. You can use both of them to have conversations. They look kinda similar. You can build bridges between them. But they are totally different architectures and philosophies however and there's room in the world for both :)

We renamed the Axolotl Protocol and the Axolotl Ratchet because of the confusion between the two (https://whispersystems.org/blog/signal-inside-and-out/), particularly when people just used the word "Axolotl."

Often when people intentionally continue to use the word "Axolotl" now, it's because they're trying to benefit from that confusion. Olm, however, has been clear about being a different protocol.

In terms of study & scrutiny: Olm and Megolm is still alpha, we're even not using it in earnest in Matrix yet. Things are moving forward fast though, and we're getting a security audit booked in which should hopefully significantly improve our study & scrutiny quotient!

(moxie: did you see my mail? any interest in grabbing a beer next week?)

I tried asking in the group chat as well but nobody seemed to know.

[0]: https://matrix.org/docs/guides/faq.html#how-secure-is-this

Conversations is ok, but Vector is already better because they can focus on usability instead of implementing an inane amount of protocol specs.

Also the bridges to IRC and slack are very helpful.

Oh and running your own matrix server is much easier as it only needs to expose the https port.

I use both. Conversations works well out-of-the-box on Android. I use Vector on my desktop, Matrix Console Android, and Vector Android, but none of them work very smoothly. I'm hopeful they will improve as time goes on as I tend to use XMPP more since I have more personal contacts that I can communicate with via that protocol, but I also like and use Matrix.

You don't seem to be aware, but there was an XMPP<->IRC bridge long before Matrix existed. It was about as satisfying as the Matrix version, though that's still improving.

I'm running my own matrix server (synapse), and my own XMPP server (ejabberd), and honestly ejabberd was easier to get off the ground. Again, I'm hopeful that synapse will improve with time, but I really think there's room for both to exist since they do have slightly different use cases.

ejabberd obviously is much more mature than synapse, but i'd be interested to know where synapse had problems getting off the ground - it's been a few years since I've run ejabberd, but it wasn't particularly fun at the time, and I'd hope that synapse can do better! :)

The present state of messaging affairs is that 99.9% of the market is proprietary spy apps that lock users in to one platform to try to force their acquaintances onto said platform for monetization purposes.

That is an undesirable state to be in for anyone advocating for open and private communications.

So you are either splitting efforts between the two, or saying damn one for the others benefit. I would gladly accept an XMPP implementation that could outpace Matrix / Vector's current performance and accept it wholeheartedly - there just isn't one, and as long as Matrix is at the forefront of usable federated open secure extensible private messaging thats who I'm putting my eggs behind, to the degree where I would say "damn XMPP" only insofar as free software developer hours are precious and wasting them are two different implementations of the same thing (much like Tox vs Ring for secret messaging) wastes a ton of effort that could be better spent making one of the two excellent rather than having two working solutions nobody uses.

You say this as if the truth of this statement was obvious to everyone.

> free software developer hours are precious and wasting them are two different implementations of the same thing (much like Tox vs Ring for secret messaging) wastes a ton of effort that could be better spent making one of the two excellent rather than having two working solutions nobody uses.

That's precisely the reason I work on ejabberd/XMPP rather than just throwing everything away and starting from scratch.

The differences are huge: * SIP is geared up for initiating sessions (hence the name), whilst Matrix is for synchronising data. SIP is heavily modelled after the requirements of the old PSTN phone network. * It's quite an old and fragmented protocol and interop can be a pain, especially between IETF and 3GPP style variants * It has many competing messaging systems layered on it (SIMPLE, MSRP, etc). You have to try very hard to extract a modern chat experience out of them - eg synchronised history, let alone end to end crypto. * Matrix is HTTP; SIP is its own dedicated UDP-or-TCP transport.

Looking at https://tools.ietf.org/html/rfc3261#section-4 this seems to be accurate.

> SIP is based on an HTTP-like request/response transaction model.

The protocol wire format is basically identical to HTTP with verbs, headers, status codes etc. Different set of verb etc however.

You can just about reuse the request/response header & mime parsing stuff (most of which is as much SMTP as HTTP), but the actual stack is completely different - supporting transports on unreliable transports like UDP via three-way handshakes (INVITE -> 200 OK -> ACK), both client->server and server->transactions, different kinds of transactions, registration methods, multiple responses, and all manner of voodoo when it gets to handling all the various types of routing headers. There are two entirely separate abstractions of the stack (ignoring the parsing layer) - the transaction layer (handling those INVITE->200->ACK things that look a bit like HTTP requests but aren't), and then the dialog engine on top that actually the lifecycle of a session (e.g. a phone call).

Random anecdote: a few years a large European telco launched a chat/comms service based on RCS (a GSMA set of standards built on SIP, IMS, MSRP etc). We sniffed the wire to see what happened if you sent the three letters "Hi!" from one client to another. Suffice it to say that it involved 85 round trips and and 54 kilobytes of data (all of which was plaintext, comically) - and this ignored the initial SIP registration. In order to send that message it set up about 3 different sessions (one to send the message as SIP MESSAGE, another to do it again by MSRP (including all the MSRP handshakes) in order to include a typing notification, another to receive the read receipt, etc).

This is why the world needs standards like XMPP and Matrix as a more internetty and less telcoy alternative ;)

1: https://xmpp.org/extensions/xep-0375.html 2: https://wiki.debian.org/UnattendedUpgrades

If you want alternatives there is jabber.at, which has also proven to be very well maintained in the past.

And there is jabber.de (but they don't have MAM (yet))

When it goes down, it goes down for multiple days, even a week. Prolonged outages have happened twice or thrice in the last two years, with no helpful messages from the staff. Heck, they didn't even bother announcing the outage before I posted on their community forums.

Their server stopped pushing offline messages to clients a long time ago. People complained, it still doesn't work on my end.

They said they would look into creating a status page, but we still can't tell during an outage if they know about it or not.

The bottom line is that maintaining their XMPP server is simply not a priority for them.

You should look into other providers that use better servers, and are also interested in maintaining their node.

EDIT: I'm basically asking you people to recommend a better XMPP node, somewhere you've personally had a good experience over a long period of time.

While nowadays most of my contacts are on private XMPP servers, I remember few having some reasonably solid experiences with https://jabber.at/ (can be also found at https://xmpp.zone/ for a better sounding domain name, which I guess matters to people who hate the now obsolete "Jabber" term). Can't from my personal experience vouch for a "good for a long period of time", but if someone is looking for at least a well established server, this should be as good start as any. Also, the news page shows they're quite serious about server updates and transparent, which is a big thumb up in my eyes.

Edit: typos

"Any discussion on end-to-end encryption in XMPP should begin with a reminder that in a federated system end-to-end encryption is not always necessary. When you trust your provider encrypting the transport layer is sufficient."

Like if you use mail internally in a domain, eg Gmail, outlook.com etc - there's no obvious mitm attack surface. Users logs into Gmail over https or imaps, emails user2@gmail either via https or smtps - and user2 logs in the same way (similar for self-hatred [lol, there were a few autocorrect errors, leaving this one in - appropriate for "self-hosted"] email).

As far as I know xmpp federation is "point2point", and the current standard demands ssl. So user1@jabber1.tld talking to user2@jabber2.tld will have the communication protected by the CA system and TLS from client1 via server1 to server2 down to client2.

It is a system of many devices, each of which might be compromised, but traditional mitm isn't the biggest danger in this case.

On the other hand, if absolute confidentiality is a concern, end-to-end encryption is required. XMPP does not rule out either approach.

End-to-end encryption matters of course, but it is a lot more relevant when one single mega-corporation is in control of every server messages pass through (e.g., WhatsApp). But if, say, you and I decide to run our own XMPP-servers and communicate thus, it may be sufficient to ascertain that a secure channel exists between our servers and between our clients and their servers.

That's the only reason I don't use it. If there's a good client I happily use it.

I hope irc can support inline images especially for web clients.

IRC can't really do multimedia in a sane/safe way over http or otherwise. But you can of course link (insert a http link) and the client can try do be as smart as it wants about it. I would think allowing the embedding of data:urls and just displaying them in-line in a Web client would be asking for security issues. I'm sure there are some IRC Web clients that supports that ;)

most xmpp client still show inline-image via http-url, I failed to find any xmpp client that can natively insert an inline image just like what other popular IM messengers do these days.

[1] https://communicationfreedom.wordpress.com/jabberxmpp/

If you happen to remember specific things you were missing on https://docs.ejabberd.im/ we'd be happy to hear about them:

https://github.com/processone/docs.ejabberd.im/issues/new

  <message from="juliet@example.com" to="romeo@example.net" xml:lang="en">
    <body>Art thou not Romeo, and a Montague?</body>
  </message>

There is already a concept of session, why send the full ID? not just a short ID.

each byte costs energy, in this case most of the energy is spend on boilerplate, stuff that can be inferred much more cheaply.

Fortunately its not wrapped in HTTP, as that'd add even more boilerplate each transaction.

because the message can be sent to different devices (resources) the user is connected with. This is not accidental complexity like you make it out to be. It is needed and wanted.

Or are you advocating a binary protocol? Personally I really like the messages exchanged with xmpp: they are easy to understand and easy to craft. I think the success of http too, lies a little bit in the fact that it is human readable.

Yes I am advocating a binary protocol. If you want to have decent battery life, then you need to be efficient. This is the tradeoff you need to make. for something like text, I really don't understand peoples fear of binary protocols.

As an aside clients have memory nowadays, there is no reason to send the full ID for the sender in each message (unless of course you are doing encyption, but even then, once you've exchanged keys its moot) a client needs to keep track of buddies that are online, so this data can be cached, and a local ID used instead.

The xml:lang element is rarely if every used.