6 ms·

Matrix.org's problem was that they reinvented the wheel (again) WRT the protocol. Now you have a protocol that if the main company goes under, probably can't be

Matrix.org's problem was that they reinvented the wheel (again) WRT the protocol. Now you have a protocol that if the main company goes under, probably can't be developed further and doesn't already have wide adoption and lots of clients written for it (as is the case of IRC/XMPP). HipChat had a better model here where they used XMPP (admittedly, in the worst way possible and completely misunderstood and broke the protocol in lots of places) but build their own service on top of it. You could still use third party clients, the experience just wouldn't be quite as good. If they had enabled federation it would have solved the Slack problem to a certain degree. Matrix could have done the same thing, but they chose to waste time and money reinventing the wheel (and doing a bad job of it) instead of focusing on the service and the clients.

SSLy 8y ago
What are your pain points with the matrix proto?
cyphar 8y ago
Can you give precise examples of the problems? As someone who tried to use XMPP in the past, I found it to be far worse than IRC in terms of connectivity and how things worked. Matrix.org couldn't really have used IRC as a protocol because IRC isn't a very extensible protocol. I've been using Matrix.org for several years now, and it's much better than my experiences with IRC and XMPP (though IRC is still quite usable, and I do still use it regularly).
- SamWhited 8y ago
  Since multiple people asked this, I started a write up. I'll try to post it soon.
zanny 8y ago
I could count the number of good, modern, high featured XMPP and IRC clients on one hand. At least compared to their proprietary counterparts. Matrix has at least as many either mature (Fractal, Riot) or up and coming clients as I'd consider usable with anything else, and it has bridges into all that legacy, something I have never seen IRC or XMPP manage well. 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.
- pseudalopex 8y ago
  Riot is the only client Matrix.org calls stable.[1] I would not call the desktop version good. The only third-party clients that are close to complete are Nheko (which has been abandoned) and FluffyChat (which is for Ubuntu Touch).[2][3] 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 https://matrix.org/docs/projects/try-matrix-now [2] https://matrix.org/docs/projects/clients-matrix https://matrix.org/docs/projects/clients-matrix [3] https://github.com/mujx/nheko https://github.com/mujx/nheko
- krageon 8y ago
  The phone experience for riot is really, really bad (extremely high battery usage, even when the app is not in use. I'm aware of the technical reasoning behind it and I frankly don't care as a consumer). This was (and is) the one barrier stopping me from using it and converting my friends to matrix (they're not platform loyal at all).
mst 8y ago
XMPP on mobile was always a disaster for data use and battery life - back when gtalk was still XMPP the mobile clients used a proprietary protocol to talk to a google server that unwrapped it into XMPP. 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.
- SamWhited 8y ago
  This is a myth (or one of those things that may have been true at one point but is now repeated as lore even though it was solved 15+ years ago); XMPP is actually pretty good on mobile. Between the persistent TLS connection which can let the radio go to sleep when no data is being sent (without the tail time of creating a new TCP connection constantly) and TLS style stream management it's very battery efficient when you're using a server that's optimized for mobile.
  - krageon 8y ago
    The last time I looked into this (maybe 6 months ago), this could only be achieved using non-standard/experimental server extensions with absolutely no guarantee of stability. This then led me to believe that it was one of those things that was theoretically possible, but not practically possible. Has that changed in the meantime?
    - arendtio 8y ago
      Well, experimental doesn't mean it isn't usable (we are talking about an experimental standard here, not about experimental software). 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.
ptman 8y ago
Matrix.org foundation is being founded. It has taken some time, but is quite close already: https://matrix.org/blog/2018/10/29/introducing-the-matrix-org-foundation-part-1-of-2/ https://matrix.org/blog/2018/10/29/introducing-the-matrix-or... The Matrix developers are familiar with XMPP, and have it covered in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/docs/guides/faq#what-is-the-difference-be...
- theamk 8y ago
  > Matrix can be thought of as an eventually consistent global JSON db with an HTTP API and pubsub semantics - whilst XMPP can be thought of as a message passing protocol. 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.
  - ummonk 8y ago
    Yeah, I’m normally not a fan of creating a new protocol and further contributing to fragmentation of open source effort, but in this case matrix.org fills a technical need that old protocols like irc and xmpp simply weren’t up to the task for.
    - SamWhited 8y ago
      What technical need is that?
  - SamWhited 8y ago
    How is this a good idea for a chat protocol though? And what makes you think XMPP doesn't do that (it's quite trivial to setup your server in such a way that messages won't be lost even if there is a network partition, client connectivity issue, etc.)
    - theamk 8y ago
      Let's look at how Slack is used in my workspace: - 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 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.

SSLy 8y ago

What are your pain points with the matrix proto?

cyphar 8y ago

Can you give precise examples of the problems? As someone who tried to use XMPP in the past, I found it to be far worse than IRC in terms of connectivity and how things worked. Matrix.org couldn't really have used IRC as a protocol because IRC isn't a very extensible protocol. I've been using Matrix.org for several years now, and it's much better than my experiences with IRC and XMPP (though IRC is still quite usable, and I do still use it regularly).

SamWhited 8y ago
Since multiple people asked this, I started a write up. I'll try to post it soon.

zanny 8y ago

I could count the number of good, modern, high featured XMPP and IRC clients on one hand. At least compared to their proprietary counterparts. Matrix has at least as many either mature (Fractal, Riot) or up and coming clients as I'd consider usable with anything else, and it has bridges into all that legacy, something I have never seen IRC or XMPP manage well. 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.

pseudalopex 8y ago
Riot is the only client Matrix.org calls stable.[1] I would not call the desktop version good. The only third-party clients that are close to complete are Nheko (which has been abandoned) and FluffyChat (which is for Ubuntu Touch).[2][3] 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 https://matrix.org/docs/projects/try-matrix-now [2] https://matrix.org/docs/projects/clients-matrix https://matrix.org/docs/projects/clients-matrix [3] https://github.com/mujx/nheko https://github.com/mujx/nheko
krageon 8y ago
The phone experience for riot is really, really bad (extremely high battery usage, even when the app is not in use. I'm aware of the technical reasoning behind it and I frankly don't care as a consumer). This was (and is) the one barrier stopping me from using it and converting my friends to matrix (they're not platform loyal at all).

mst 8y ago

XMPP on mobile was always a disaster for data use and battery life - back when gtalk was still XMPP the mobile clients used a proprietary protocol to talk to a google server that unwrapped it into XMPP. 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.

SamWhited 8y ago
This is a myth (or one of those things that may have been true at one point but is now repeated as lore even though it was solved 15+ years ago); XMPP is actually pretty good on mobile. Between the persistent TLS connection which can let the radio go to sleep when no data is being sent (without the tail time of creating a new TCP connection constantly) and TLS style stream management it's very battery efficient when you're using a server that's optimized for mobile.
- krageon 8y ago
  The last time I looked into this (maybe 6 months ago), this could only be achieved using non-standard/experimental server extensions with absolutely no guarantee of stability. This then led me to believe that it was one of those things that was theoretically possible, but not practically possible. Has that changed in the meantime?
  - arendtio 8y ago
    Well, experimental doesn't mean it isn't usable (we are talking about an experimental standard here, not about experimental software). 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.

ptman 8y ago

Matrix.org foundation is being founded. It has taken some time, but is quite close already: https://matrix.org/blog/2018/10/29/introducing-the-matrix-org-foundation-part-1-of-2/ https://matrix.org/blog/2018/10/29/introducing-the-matrix-or... The Matrix developers are familiar with XMPP, and have it covered in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/docs/guides/faq#what-is-the-difference-be...

theamk 8y ago
> Matrix can be thought of as an eventually consistent global JSON db with an HTTP API and pubsub semantics - whilst XMPP can be thought of as a message passing protocol. 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.
- ummonk 8y ago
  Yeah, I’m normally not a fan of creating a new protocol and further contributing to fragmentation of open source effort, but in this case matrix.org fills a technical need that old protocols like irc and xmpp simply weren’t up to the task for.
  - SamWhited 8y ago
    What technical need is that?
- SamWhited 8y ago
  How is this a good idea for a chat protocol though? And what makes you think XMPP doesn't do that (it's quite trivial to setup your server in such a way that messages won't be lost even if there is a network partition, client connectivity issue, etc.)
  - theamk 8y ago
    Let's look at how Slack is used in my workspace: - 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 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.