If you have legitimate grievances with the protocol and feel you can see flaws in it, make an issue on the tracker now while its still a 0.x release, doesn't have the broad adoption you describe, and while the team (knowingly) can make breaking changes simultaneously released to matrix.org and riot.im and cover 95% of the users still.

There are no stable servers.[1] The reference server is being completely rewritten.

Matrix bridges work about as well as XMPP bridges in my experience.

[1] https://matrix.org/docs/projects/try-matrix-now

[2] https://matrix.org/docs/projects/clients-matrix

[3] https://github.com/mujx/nheko

The Matrix developers are familiar with XMPP, and have it covered in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-be...

Finally someone gets it! A chat service should value each message and it should never lose messages due to connectivity problems.

Thank you for sharing that link, I learned something new today.

- Person-to-person chat system. This requires offline messages: "when you get to work, please take a look at ABC-1234". Some people have cell phone as well, so this needs multi-delivery to all the clients (so you can read the message on the phone, then read it again from work PC)

- Support system: one person posts "I cannot run TOOL_Z", people who know reply. This requires offline history -- if I maintain TOOL_Z and I come in late, I was to see the question asked, answers, and maybe I want to contribute an answer as well. By the way, slack threads are super helpful for this.

- Knowledge archive: next person to have TOOL_Z problem would search the channel history, and find previous answers.

- Announcement with discussion: someone posts "New version of TOOL_Z is released! New features: ...". People might respond by discussing the new features.

All of those basically require "global database" -- those messages are not volatile things; it is not OK if the announcement is lost, or if you did not see the help request because there was something wrong with the system.

And I know that XMPP does not work for that because back when my workplace used to use XMPP (a few years ago), I went to https://xmpp.org/software/clients.html , installed "gaijim", and found out it has no offline message history, no message searching, and half-broken multi-delivery.

So we ended up building scaffolding - set up our own search engine, archive system, use different methods for communication. This was a lot of pain and very little gain. So when we had to re-do infrastructure from scratch, we went with Slack.

(Note that you can't just say: "I don't need those features". As long as there is a single person in the company who does not have history, the whole company cannot use pure XMPP for support system or knowledge archive anymore -- or that person would be excluded.)

As you said in other messages, things are better now -- there are compliance suites. So "XMPP Advanced Client 2018" does do what you want. Unfortunately, I cannot find a list of clients which support "XMPP Advanced Client 2018".

Also, there are people who confuse matters by saying that "XMPP does everything Slack can, and has tons of clients". No. "XMPP Advanced Client 2018" does everything Slack can but has very few clients. Regular XMPP has tons of clients but does not support everything that Slack can. It is very important to distinguish between the two.

The FAQ skirts around the fact that it doesn't matter if they're slightly different: you shouldn't make up your own new thing to force adoption of your commercial product. Use and improve the existing technologies that are "good enough" and stop splitting effort and making yet another standard that everyone has to try and support or run bridges for. This is unacceptably bad engineering. Saying "this is subjective" is true, but just an excuse for "we have not-invented-here syndrome".

Pure-XMPP simply would not have worked.

(I have my issues with the matrix protocol, mind, but they had good reasons to create a protocol even so)

Edit: I also wouldn't be surprised if this is why facebook messenger switched from XMPP to a custom MQTT-based system.

I run an ejabberd server and for example the Client State Indicator (XEP-0352), which is one of the extensions that improve battery life for mobile clients, was experimental for a long time but at the same time also available for major servers (e.g. community edition of ejabberd) and mobile clients like Conversations (open source too).

So in my experience, the battery consumption of a modern XMPP client is quite good. When people are complaining about the bad mobile experience they are mostly referring to the time before the mobile extensions were built.

So apparently not everybody shares your definition of 'solved' - I appreciate the alternative opinion, but simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics.

simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics

It's hard to provide specific counter-arguments to anecdotal evidence repeated since back when gtalk was a thing.

[0] https://gultsch.de/xmpp_2016.html

[1] https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_....