5 ms·

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.

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 10y 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 10y 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 10y 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?
    - Arathorn 10y ago
      Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Totally agreed that HTTP is inefficient and increases the potential bug surface a bit. However, the ubiquity and convenience empirically seems to outweigh the inefficiency and risk. Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes; it shoves a stream of JSON over a websocket. We even wrote an implementation of it: https://github.com/matrix-org/matrix-websockets-proxy https://github.com/matrix-org/matrix-websockets-proxy. And NOBODY in over a year has felt the urge to actually implement a client against it - instead there have probably been 40-50 new clients, all who were quite happy to use the ugly HTTP API instead. This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever".
      - zAy0LfpBZLC8mAC 10y ago
        > Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this kind of construct doesn't even provide any sensible layering abstractions. > Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes Except that the client and the server still need to understand HTTP in order to then implement a bad version of TCP on top of it, more or less, which makes this whole mess even more bloated and error-prone. > This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever". What exactly would people facepalming and walking off feel like, that this doesn't feel like it? In case you hadn't guessed it yet, that was exactly my reaction when I looked at the spec a while ago, and it just so happened that I stumbled upon this thread here, or you most likely wouldn't ever have heard about it, and I can only guess that I am not the only one. (And no, that reaction was not just based on the use of HTTP, but more generally on the impression from the spec that it's all a huge dysfunctional mess that's essentially impossible to implement securely, and that probably will result in even greater interoperability problems than email with all its historical baggage in a much shorter time frame. All of which in turn makes me suspect that the people who are busily writing software for it just are lacking knowledge and experience to see the flaws, and examples like that "C" client do not exactly help to convince me of the opposite.)
ryukafalz 10y ago
The startup times are most notable for me. As an example, here are a few lines from the node example app in the matrix-js-sdk repo: Jonathans-MBP:node jon$ node app.js | ts Apr 11 18:27:22 Got push rules <snip> Apr 11 18:28:03 Room List: Apr 11 18:28:03 [0] Invite from @sms:matrix… (0 members) --- This seems like a pretty barebones Matrix client, and it's taken 41 seconds to get to the point where it can display the rooms I'm in on a 2012 MacBook Pro with an i7 processor. (Also notably, Activity Monitor reports that this node process is using 318 MB of memory.) Granted, I'm a fairly heavy Matrix user, and the fact that I'm in nearly 100 rooms probably has something to do with it. :)
- Arathorn 10y ago
  So, this was a design flaw in how matrix-js-sdk was originally implemented - it simply didn't cache any state whatsoever locally, so every new launch meant re-syncing the whole world to the client. This can obviously be improved by lazyloading, but for now we've fixed it by caching full offline state in indexeddb - https://github.com/matrix-org/matrix-js-sdk/pull/363 https://github.com/matrix-org/matrix-js-sdk/pull/363 & friends. This speeds up launch time to a few seconds, if that - and as we go through doing more lazyloading it'll be even better. We also need to make the app progressively loaded in general rather than a big ball of webpack. Coincidentally, the new version of Riot which uses the new indexeddb backend should be going live tomorrow (live today on riot.im/staging).
  - kuschku 10y ago
    So, how can I launch a matrix client that has never been used before and chat, with only a dialup connection, in less than 4 seconds? I can do that with IRC. I can do that with all IRC bouncers. And it’s a daily use case for me, and many other users (mobile networks provide free 64kbps network in many places) 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.
killin_dan 10y ago
At no point did I imply it's garbage because it's FOSS. I'm always down for more FOSS, and don't ever paint me otherwise. It's bad because the protocol is heavy and complex. Plenty of technical complications detailed in other comments.
- Arathorn 10y ago
  At no point did I suggest you thought it was garbage because it's FOSS - I was just pointing out that because it's FOSS we're dependent on the wider community to contribute constructive feedback (and ideally code) to improve it. So far the other feedback seems to be "HTTP is overly complex" (which is very subjective), "Matrix is too tied to HTTP" (despite evidence to the contrary), matrix-js-sdk is slow (which we've fixed), and "Riot is extremely resource heavy" (which is relatively true - it's already better than Slack, but we're working on it). I'd genuinely like to know what your specific bad experience was so we can fix it, as it seems to have really pissed you off to be seen as "garbage" and "not remotely suitable" and "not suitable for business" :)
  - lightedman 10y ago
    Go re-design your program on a Pentium-II with 128MB of RAM and you'll understand every single complaint anyone could've had - including the sheer bloat of your project.
    - Karunamon 10y ago
      I get where you're coming from here, but in the days where you can get a Linux computer for $US35 that has a 1.2Ghz quad core and a gig of RAM, it doesn't make much sense to go through the contortions necessary to develop for a toaster. The cost/benefit just isn't there.

zAy0LfpBZLC8mAC 10y 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 10y 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 10y 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?
  - Arathorn 10y ago
    Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Totally agreed that HTTP is inefficient and increases the potential bug surface a bit. However, the ubiquity and convenience empirically seems to outweigh the inefficiency and risk. Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes; it shoves a stream of JSON over a websocket. We even wrote an implementation of it: https://github.com/matrix-org/matrix-websockets-proxy https://github.com/matrix-org/matrix-websockets-proxy. And NOBODY in over a year has felt the urge to actually implement a client against it - instead there have probably been 40-50 new clients, all who were quite happy to use the ugly HTTP API instead. This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever".
    - zAy0LfpBZLC8mAC 10y ago
      > Your justification of why "it's essentially impossible to reasonably port it to a sensible transport protocol" appears to be an explanation of how one could reasonably port it to a sensible transport protocol (JSON over some flavour of socket) ;) Except for the fact that it's necessarily redefining quite a bit of the protocol, also necessarily further complicating any possible universal implementations because this kind of construct doesn't even provide any sensible layering abstractions. > Just to reiterate: the websockets transport does (in part) what you propose: it doesn't use URIs, it doesn't use HTTP status codes Except that the client and the server still need to understand HTTP in order to then implement a bad version of TCP on top of it, more or less, which makes this whole mess even more bloated and error-prone. > This doesn't feel like people facepalming and walking off, but just saying "huh, let's see if the HTTP thing is that bad in practice. oh, it's fine, i'll concentrate on writing my bot/bridge/client/whatever". What exactly would people facepalming and walking off feel like, that this doesn't feel like it? In case you hadn't guessed it yet, that was exactly my reaction when I looked at the spec a while ago, and it just so happened that I stumbled upon this thread here, or you most likely wouldn't ever have heard about it, and I can only guess that I am not the only one. (And no, that reaction was not just based on the use of HTTP, but more generally on the impression from the spec that it's all a huge dysfunctional mess that's essentially impossible to implement securely, and that probably will result in even greater interoperability problems than email with all its historical baggage in a much shorter time frame. All of which in turn makes me suspect that the people who are busily writing software for it just are lacking knowledge and experience to see the flaws, and examples like that "C" client do not exactly help to convince me of the opposite.)

ryukafalz 10y ago

The startup times are most notable for me. As an example, here are a few lines from the node example app in the matrix-js-sdk repo: Jonathans-MBP:node jon$ node app.js | ts Apr 11 18:27:22 Got push rules <snip> Apr 11 18:28:03 Room List: Apr 11 18:28:03 [0] Invite from @sms:matrix… (0 members) --- This seems like a pretty barebones Matrix client, and it's taken 41 seconds to get to the point where it can display the rooms I'm in on a 2012 MacBook Pro with an i7 processor. (Also notably, Activity Monitor reports that this node process is using 318 MB of memory.) Granted, I'm a fairly heavy Matrix user, and the fact that I'm in nearly 100 rooms probably has something to do with it. :)

Arathorn 10y ago
So, this was a design flaw in how matrix-js-sdk was originally implemented - it simply didn't cache any state whatsoever locally, so every new launch meant re-syncing the whole world to the client. This can obviously be improved by lazyloading, but for now we've fixed it by caching full offline state in indexeddb - https://github.com/matrix-org/matrix-js-sdk/pull/363 https://github.com/matrix-org/matrix-js-sdk/pull/363 & friends. This speeds up launch time to a few seconds, if that - and as we go through doing more lazyloading it'll be even better. We also need to make the app progressively loaded in general rather than a big ball of webpack. Coincidentally, the new version of Riot which uses the new indexeddb backend should be going live tomorrow (live today on riot.im/staging).
- kuschku 10y ago
  So, how can I launch a matrix client that has never been used before and chat, with only a dialup connection, in less than 4 seconds? I can do that with IRC. I can do that with all IRC bouncers. And it’s a daily use case for me, and many other users (mobile networks provide free 64kbps network in many places) 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.

killin_dan 10y ago

At no point did I imply it's garbage because it's FOSS. I'm always down for more FOSS, and don't ever paint me otherwise. It's bad because the protocol is heavy and complex. Plenty of technical complications detailed in other comments.

Arathorn 10y ago
At no point did I suggest you thought it was garbage because it's FOSS - I was just pointing out that because it's FOSS we're dependent on the wider community to contribute constructive feedback (and ideally code) to improve it. So far the other feedback seems to be "HTTP is overly complex" (which is very subjective), "Matrix is too tied to HTTP" (despite evidence to the contrary), matrix-js-sdk is slow (which we've fixed), and "Riot is extremely resource heavy" (which is relatively true - it's already better than Slack, but we're working on it). I'd genuinely like to know what your specific bad experience was so we can fix it, as it seems to have really pissed you off to be seen as "garbage" and "not remotely suitable" and "not suitable for business" :)
- lightedman 10y ago
  Go re-design your program on a Pentium-II with 128MB of RAM and you'll understand every single complaint anyone could've had - including the sheer bloat of your project.
  - Karunamon 10y ago
    I get where you're coming from here, but in the days where you can get a Linux computer for $US35 that has a 1.2Ghz quad core and a gig of RAM, it doesn't make much sense to go through the contortions necessary to develop for a toaster. The cost/benefit just isn't there.