13 ms·

Matrix is an extremely heavy protocol, not suitable for business use imo. Riot is really obnoxious to use and get set up, and is also extremely resource hungry

Matrix is an extremely heavy protocol, not suitable for business use imo. Riot is really obnoxious to use and get set up, and is also extremely resource hungry. I don't think you're very familiar with chat protocols if you think it's even remotely suitable as a replacement for IRC.

ktta 9y ago
Well. I'm interested to see what you think is a suitable protocol for business. I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today. I'm not very familiar with all of the chat protocols, but I'm familiar with the possibilities of communication today. It's riddled with proprietary protocols and chromium based applications. And that's why I see Matrix as the next step.
- milesrout 9y ago
  >I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. Let's take those each at a time, shall we? >Emojis This has nothing to do with the protocol. If you can send arbitrary UTF-8 messages (which you should be able to do, obviously, and can with modern IRC clients) then you can send emojis to your heart's content. >Search I've never personally found search particularly useful, but there's nothing about IRC that makes it any harder or easier to search messages. The way all chat search works and will always work is that you log chat messages somewhere and provide a way to search them. That has nothing to do with the protocol and everything to do with the server logging messages. You can then extend your chat protocol with a command that you send to the server that asks it to search the current channel (or all channels, or all channels I'm in, or all channels I've been in, or all messages sent in all channels that I was in at the time, that's up to the server though - corporate probably want the former, public you'd want the last one) for a particular string/regexp/whatever. There's nothing particularly complex here from the perspective of the chat protocol and in fact it would be simple to extend the IRC protocol with a command for doing this at the protocol level. It's just much easier to write bots to log messages and web interfaces to search those logs with. >Session persistence No, nobody wants this. What people want are to see messages sent while they weren't there and to be able to receive messages while away. The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again. >Web client There are lots of IRC web clients, and all you need for this is a simple protocol. >So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today. IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.
  - ktta 9y ago
    >>Emojis Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2]. >>Search You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features. >>Session persistence >No, nobody wants this. Really? Are you sure? > The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again. Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features. >>> Web Client IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about. >IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer. Honestly, I might sound ignorant, but I've never ever heard of DCC file transfer. And matrix has implemented E2E encryption in some of their clients(all the major ones), and implementing them in the rest is a priority. I don't ever thing IRC will have this. I'd be glad if I was wrong. Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about. One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to? Or do you want to ignore them so that they continue using a closed messenger and wonder why they're dominating the mindshare today? Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing. [1]:https://github.com/matrix-org/matrix-react-sdk/pull/296 https://github.com/matrix-org/matrix-react-sdk/pull/296 [2]:https://github.com/vector-im/riot-web/issues?utf8=%E2%9C%93&q=is%3Aissue%20emoji https://github.com/vector-im/riot-web/issues?utf8=%E2%9C%93&...
- kuschku 9y ago
  > The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. Then use the Quassel IRC bouncer, with clients. Web client? https://github.com/magne4000/quassel-webserver https://github.com/magne4000/quassel-webserver Session persistence? That’s the entire purpose of it. Search? https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 Emojis? Check. > So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today. That’s why IRCv3 is a thing, slowly replacing the hacks with proper specs. No more NickServ, but instead SASL and account-notify. No more guessing where some batch of messages ends, but a batch message type. > It's riddled with […] chromium based applications. So is Matrix. I’m not saying Matrix is bad, Matrix has some awesome properties (especially regarding encryption). And maybe someday it can become awesome, once it gains a proper binary transport system, which is more efficient and keeps a single socket open. And maybe then, we can finally replace IRC, XMPP, etc. But until then, I’ll keep working on improving IRC.
Arathorn 9y ago
Given Matrix & Riot are entirely FOSS, please do spell out its obnoxiousnesses (rant here, or file on http://github.com/vector-im/riot-web/issues http://github.com/vector-im/riot-web/issues) so we and the wider community can go fix it. Agreed that Riot is too heavy; we're currently doing a performance blitz on it. In terms of Matrix itself being too heavy... we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works well enough that nobody has bothered. Empirically many people seem to use it fine for business and for IRC-style purposes though :)
- zAy0LfpBZLC8mAC 9y ago
  > we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works well enough that nobody has bothered. Well, except you managed to needlessly intertwine matrix and HTTP such that it's essentially impossible to reasonably port it to a sensible transport protocol.
  - Arathorn 9y ago
    What do you have in mind? There is nothing particularly specific to HTTP about Matrix at all - it just needs some kind of request/response mechanism, and a way to stream events back and forth. For instance https://github.com/matrix-org/matrix-doc/blob/master/drafts/websockets.rst https://github.com/matrix-org/matrix-doc/blob/master/drafts/... is the proposal for Matrix over websockets (which streams server->client events over a websocket in a manner which has nothing to do with HTTP). But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice. Similarly switching HTTP for COAP would be trivial, but nobody's bothered afaik.
    - zAy0LfpBZLC8mAC 9y ago
      > What do you have in mind? You are using URIs and HTTP status codes (if you want to call it that, as you are not actually speaking HTTP), which is completely unnecessary (you could transport that same information in JSON, reducing the number of languages that an implementation needs to be able to generate and parse to one instead of three, thus reducing the attack surface by at least 66 % (probably more, given the complexity of HTTP)). I mean, just look at the "lightweight C client" that you linked to above: Not only is it not in C, but it's already full of bugs that are essentially caused by the complexity of all those languages on has to interface with. > But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice. Or, more likely, those who do feel that way have read the spec, facepalmed, and forgot about it?
tomstockmail 9y ago
>Riot is really obnoxious to use and get set up, and is also extremely resource hungry. I set it up over the weekend and it took me less than an hour, and that was because of my HAProxy + Lets Encrypt setup requirements. It's not perfect, but it wasn't obnoxious to do. Additionally the Riot client on Android via F-Droid has been great on my battery life on my phone, significantly less than Hangouts (which I'm replacing with Matrix so that's why I compare the two).

ktta 9y ago

Well. I'm interested to see what you think is a suitable protocol for business. I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today. I'm not very familiar with all of the chat protocols, but I'm familiar with the possibilities of communication today. It's riddled with proprietary protocols and chromium based applications. And that's why I see Matrix as the next step.

milesrout 9y ago
>I said it's an alternative, not a replacement. The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. Let's take those each at a time, shall we? >Emojis This has nothing to do with the protocol. If you can send arbitrary UTF-8 messages (which you should be able to do, obviously, and can with modern IRC clients) then you can send emojis to your heart's content. >Search I've never personally found search particularly useful, but there's nothing about IRC that makes it any harder or easier to search messages. The way all chat search works and will always work is that you log chat messages somewhere and provide a way to search them. That has nothing to do with the protocol and everything to do with the server logging messages. You can then extend your chat protocol with a command that you send to the server that asks it to search the current channel (or all channels, or all channels I'm in, or all channels I've been in, or all messages sent in all channels that I was in at the time, that's up to the server though - corporate probably want the former, public you'd want the last one) for a particular string/regexp/whatever. There's nothing particularly complex here from the perspective of the chat protocol and in fact it would be simple to extend the IRC protocol with a command for doing this at the protocol level. It's just much easier to write bots to log messages and web interfaces to search those logs with. >Session persistence No, nobody wants this. What people want are to see messages sent while they weren't there and to be able to receive messages while away. The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again. >Web client There are lots of IRC web clients, and all you need for this is a simple protocol. >So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today. IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.
- ktta 9y ago
  >>Emojis Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2]. >>Search You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features. >>Session persistence >No, nobody wants this. Really? Are you sure? > The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again. Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features. >>> Web Client IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about. >IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer. Honestly, I might sound ignorant, but I've never ever heard of DCC file transfer. And matrix has implemented E2E encryption in some of their clients(all the major ones), and implementing them in the rest is a priority. I don't ever thing IRC will have this. I'd be glad if I was wrong. Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about. One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to? Or do you want to ignore them so that they continue using a closed messenger and wonder why they're dominating the mindshare today? Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing. [1]:https://github.com/matrix-org/matrix-react-sdk/pull/296 https://github.com/matrix-org/matrix-react-sdk/pull/296 [2]:https://github.com/vector-im/riot-web/issues?utf8=%E2%9C%93&q=is%3Aissue%20emoji https://github.com/vector-im/riot-web/issues?utf8=%E2%9C%93&...
kuschku 9y ago
> The days of simplistic IRC protocols have gone. Now people want emojis, search, session persistence, web client, and more things. Then use the Quassel IRC bouncer, with clients. Web client? https://github.com/magne4000/quassel-webserver https://github.com/magne4000/quassel-webserver Session persistence? That’s the entire purpose of it. Search? https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 https://dl.kuschku.de/videos/2016-09-16_04-03-36.mp4 Emojis? Check. > So for that, there's obviously going to be more complexity compared to IRC. And IRC feels so hacked on when fit it with the modern features one wants today. That’s why IRCv3 is a thing, slowly replacing the hacks with proper specs. No more NickServ, but instead SASL and account-notify. No more guessing where some batch of messages ends, but a batch message type. > It's riddled with […] chromium based applications. So is Matrix. I’m not saying Matrix is bad, Matrix has some awesome properties (especially regarding encryption). And maybe someday it can become awesome, once it gains a proper binary transport system, which is more efficient and keeps a single socket open. And maybe then, we can finally replace IRC, XMPP, etc. But until then, I’ll keep working on improving IRC.

Arathorn 9y ago

Given Matrix & Riot are entirely FOSS, please do spell out its obnoxiousnesses (rant here, or file on http://github.com/vector-im/riot-web/issues http://github.com/vector-im/riot-web/issues) so we and the wider community can go fix it. Agreed that Riot is too heavy; we're currently doing a performance blitz on it. In terms of Matrix itself being too heavy... we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works well enough that nobody has bothered. Empirically many people seem to use it fine for business and for IRC-style purposes though :)

zAy0LfpBZLC8mAC 9y ago
> we're still waiting for anyone to contribute a more efficient transport, but turns out HTTP+JSON works well enough that nobody has bothered. Well, except you managed to needlessly intertwine matrix and HTTP such that it's essentially impossible to reasonably port it to a sensible transport protocol.
- Arathorn 9y ago
  What do you have in mind? There is nothing particularly specific to HTTP about Matrix at all - it just needs some kind of request/response mechanism, and a way to stream events back and forth. For instance https://github.com/matrix-org/matrix-doc/blob/master/drafts/websockets.rst https://github.com/matrix-org/matrix-doc/blob/master/drafts/... is the proposal for Matrix over websockets (which streams server->client events over a websocket in a manner which has nothing to do with HTTP). But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice. Similarly switching HTTP for COAP would be trivial, but nobody's bothered afaik.
  - zAy0LfpBZLC8mAC 9y ago
    > What do you have in mind? You are using URIs and HTTP status codes (if you want to call it that, as you are not actually speaking HTTP), which is completely unnecessary (you could transport that same information in JSON, reducing the number of languages that an implementation needs to be able to generate and parse to one instead of three, thus reducing the attack surface by at least 66 % (probably more, given the complexity of HTTP)). I mean, just look at the "lightweight C client" that you linked to above: Not only is it not in C, but it's already full of bugs that are essentially caused by the complexity of all those languages on has to interface with. > But nobody's bothered to implement it, because nobody seems to feel HTTP+JSON is particularly broken in practice. Or, more likely, those who do feel that way have read the spec, facepalmed, and forgot about it?

tomstockmail 9y ago

>Riot is really obnoxious to use and get set up, and is also extremely resource hungry. I set it up over the weekend and it took me less than an hour, and that was because of my HAProxy + Lets Encrypt setup requirements. It's not perfect, but it wasn't obnoxious to do. Additionally the Riot client on Android via F-Droid has been great on my battery life on my phone, significantly less than Hangouts (which I'm replacing with Matrix so that's why I compare the two).