5 ms·

People will complain all day about Slack, but somehow still use it. If we are so concerned, why aren't we all moving to Matrix?

ch4s3 9y ago
The only reason we don't leave slack is because there's 3 years of indexed useful chat history. And the sales guys like it. The rest of us think it's slow and bloated.
kuschku 9y ago
Because most Matrix clients are equally ridiculous, and the Matrix protocol is even worse.
- Arathorn 9y ago
  sigh - if you are going to badmouth Matrix, please at least disclose that you are doing so from the perspective of working on an alternative standard (IRCv3). That said, agreed that Riot/Desktop suffers similar problems to Slack thanks to being an Electron app. Pure Qt clients like nheko and quaternion have a lot more promise on the desktop. In terms of the protocol: yup, the baseline Matrix protocol is plain and simple HTTPS+JSON. Patches welcome from anyone who finds this enough of a problem to provide alternative efficient transports :) [disclosure; i work on matrix, although grew up on IRC, and respect the IRCv3 project, despite behaviour like this.]
  - kuschku 9y ago
    I'm not an official member of the IRCv3 project, and can't speak for them - I only engage in discussions in the IRCv3 WG which affect the client I am working on. That said, Matrix is a great concept, but, as mentioned, the currently implemented clients and protocol (with HTTP polling with JSON) are very inefficient. With Quarternion as client, and a raw socket or websocket based protocol using Protobuf or Flatbuffers for serialization Matrix could actually become the fastest and most efficient open chat system. You have to realize that I'm seeing this as someone who uses clients on 7 year old devices on throttled 2G in daily use, to ensure that they work well enough under any conditions. (And while some IRC clients do work there, any Matrix client is completely unusable under those conditions).
- ValentineC 9y ago
  > the Matrix protocol is even worse Could you please elaborate on this?
  - Arathorn 9y ago
    I can't speak for kuschku, but the normal complaint is that every message you send in Matrix is a new HTTP hit, and every batch if messages you receive is a new HTTP hit - and this (combined with the message format being JSON) is less bandwidth and roundtrip efficient than a dedicated TCP line protocol like IRC. And this is true, in the default baseline protocol. It makes it absolutely trivial to send and receice messages; you can just fire up curl to do an http PUT to speak or GET to receive. However, Matrix does let folks define more efficient optional transports, but in practice (other than a websockets+JSON proposal), nobody has bothered. It seems that for most purposes HTTP+JSON is fine; after all the whole web revolves around it, plus you don't need to worry about timeouts on a single tcp socket etc. And with HTTP/2 most of the concerns go away anyway, as the overhead of new requests is fairly minimal (same socket; header compression; etc). On mobile devices a better transport would be desirable for reduced battery and bandwidth consumption, and I'm sure we'll eventually see one. But for now HTTP is perfectly serviceable, if not the most efficient solution.

ch4s3 9y ago

The only reason we don't leave slack is because there's 3 years of indexed useful chat history. And the sales guys like it. The rest of us think it's slow and bloated.

kuschku 9y ago

Because most Matrix clients are equally ridiculous, and the Matrix protocol is even worse.

Arathorn 9y ago
sigh - if you are going to badmouth Matrix, please at least disclose that you are doing so from the perspective of working on an alternative standard (IRCv3). That said, agreed that Riot/Desktop suffers similar problems to Slack thanks to being an Electron app. Pure Qt clients like nheko and quaternion have a lot more promise on the desktop. In terms of the protocol: yup, the baseline Matrix protocol is plain and simple HTTPS+JSON. Patches welcome from anyone who finds this enough of a problem to provide alternative efficient transports :) [disclosure; i work on matrix, although grew up on IRC, and respect the IRCv3 project, despite behaviour like this.]
- kuschku 9y ago
  I'm not an official member of the IRCv3 project, and can't speak for them - I only engage in discussions in the IRCv3 WG which affect the client I am working on. That said, Matrix is a great concept, but, as mentioned, the currently implemented clients and protocol (with HTTP polling with JSON) are very inefficient. With Quarternion as client, and a raw socket or websocket based protocol using Protobuf or Flatbuffers for serialization Matrix could actually become the fastest and most efficient open chat system. You have to realize that I'm seeing this as someone who uses clients on 7 year old devices on throttled 2G in daily use, to ensure that they work well enough under any conditions. (And while some IRC clients do work there, any Matrix client is completely unusable under those conditions).
ValentineC 9y ago
> the Matrix protocol is even worse Could you please elaborate on this?
- Arathorn 9y ago
  I can't speak for kuschku, but the normal complaint is that every message you send in Matrix is a new HTTP hit, and every batch if messages you receive is a new HTTP hit - and this (combined with the message format being JSON) is less bandwidth and roundtrip efficient than a dedicated TCP line protocol like IRC. And this is true, in the default baseline protocol. It makes it absolutely trivial to send and receice messages; you can just fire up curl to do an http PUT to speak or GET to receive. However, Matrix does let folks define more efficient optional transports, but in practice (other than a websockets+JSON proposal), nobody has bothered. It seems that for most purposes HTTP+JSON is fine; after all the whole web revolves around it, plus you don't need to worry about timeouts on a single tcp socket etc. And with HTTP/2 most of the concerns go away anyway, as the overhead of new requests is fairly minimal (same socket; header compression; etc). On mobile devices a better transport would be desirable for reduced battery and bandwidth consumption, and I'm sure we'll eventually see one. But for now HTTP is perfectly serviceable, if not the most efficient solution.