4 ms·

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-founda

by 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.
SamWhited 8y ago
I've read that FAQ entry, but it's bogus in terms of chat. Maybe the protocol is more useful for some other thing, I don't know (although I doubt it since XMPP at least can also do very similar sorts of things with pubsub if you need them for some use case, eg. the IoT people do this sort of thing a lot). 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".

by ptman 8y ago

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.

SamWhited 8y ago

I've read that FAQ entry, but it's bogus in terms of chat. Maybe the protocol is more useful for some other thing, I don't know (although I doubt it since XMPP at least can also do very similar sorts of things with pubsub if you need them for some use case, eg. the IoT people do this sort of thing a lot). 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".