7 ms·

I'm not really a fan of IRC (a federated network where some OSS projects were on their own servers or different ones would have limited the blast radius of a ho

I'm not really a fan of IRC (a federated network where some OSS projects were on their own servers or different ones would have limited the blast radius of a hostile takeover of one server like this), but Matrix is bloated and slow and the protocol makes no sense for chat (though it may have other applications); it's not a great fit for a large network with lots of people who may or may not have modern hardware. Not to mention that the servers would take a lot more resources to run on Matrix (assuming it eventually gets roughly the same size as Freenode was).

est31 5y ago
The implementations might be bloated (js heavy, etc), and the non bloated implementations written in C++ or Rust or so don't have the full feature set yet, but is it really the protocol to blame? In which way does the protocol make no sense for chat? IRC is extremely complicated as well and a giant pile of hacks.
- SamWhited 5y ago
  For clients maybe not, but for servers the protocol itself is to blame, yes. A giant distributed graph database where everything has to be synced constantly means you use a ton of memory. IRC is definitely complicated, and arguably a pile of hacks, but an event based system (more or less) makes a lot more sense for chat where you want realtime communication (more or less), not to wait while you sync nodes in the graph to every place that wants them.
  - joepie91_ 5y ago
    This makes no sense. Propagating a bunch of messages doesn't suddenly use a ton of memory just because you're organizing them as a graph rather than a linear pubsub-style stream.
    - SamWhited 5y ago
      Sorry, it was a bad explanation. The point is that you have to keep a lot of past state in memory for future messages to make sense and sync properly, unlike an event based system where you (more or less) only need to perform some action when you get an event then forget about it. This is an IRC thread though, sorry I got sucked in but let's not let the Matrix CEO derail it and try to score users. The whole point is is that it didn't make sense for them to switch to matrix because it uses more resources than most IRC servers and because they are trying to be a drop in replacement, not make users sign up for new things.
      - joepie91_ 5y ago
        You don't have to keep that much state in memory at all, actually. I'm not sure why you think that you do. Most of the state resolution (eg. the auth chain) involves calculations of which you can cache the result without needing to care about the inputs beyond that - at least, unless you need to recalculate them once later if delayed events come in. Ultimately, the performance problems that Synapse has are problems with Synapse's implementation choices (especially around the database schema), not with the protocol nor with the state resolution algorithm.
        TheCycoONE 5y ago
        Presence may be a protocol level issue. My server struggled pretty badly until I disabled it and I see that's generally the advice: https://github.com/matrix-org/synapse/issues/3971 https://github.com/matrix-org/synapse/issues/3971 That doesn't seem like a fundamental issue though.
        Arathorn 5y ago
        It’s a synapse implementation problem, not a protocol issue. And it’s being fixed currently.
Arathorn 5y ago
Wow, that's a lot of negativity. You forgot to disclose your XMPP/XSF affiliation, btw. Matrix as a protocol is neither bloated or slow, and ~32.1M folks have managed to use it successfully, directly or indirectly, as a global chat network. Presumably that counts as a 'large network'; it's certainly bigger than Freenode. Synapse as an implementation has historically been bloated, but it's been steadily improving (and in fact last week's Matrix Live has a fascinating analysis of how the remaining memory usage is being fixed: https://youtu.be/694VuhmVmfo https://youtu.be/694VuhmVmfo). Meanwhile implementations like Dendrite & Conduit are positively skinny.
- jrwr 5y ago
  Overall, I would pick XMPP over Matrix at this point. it is rather bloated and the clients are a little bit obtuse for newbies. I do wonder what the DAU for Matrix is at this point. as I suspect that 32 Million number might be a little overstated.
  - Arathorn 5y ago
    frankly, as long as folks are communicating via open standards rather than being locked into some vendor silo then they should use whatever protocol works best for them - XMPP & Matrix bridge together fairly well these days. Based on the phone-home stats in Synapse there's around 300K DAU currently on the network, but this is a major underestimate given other stats which suggest only about 30% of public servers enable phone-home.
    - zaik 5y ago
      > XMPP & Matrix bridge together fairly well these days Does Matrix support OMEMO for e2e encryption?
      - Arathorn 5y ago
        Yup, OMEMO and Olm are bit compatible. In fact XEP-0384 went through a phase of recommending Olm as the implementation to use (grep https://xmpp.org/extensions/xep-0384.html https://xmpp.org/extensions/xep-0384.html for Olm). (Although the bifrost bridge doesn't currently implement E2EE - and it would have to reencrypt anyway to turn the Matrix event payloads into XMPP stanzas and vice versa)

est31 5y ago

The implementations might be bloated (js heavy, etc), and the non bloated implementations written in C++ or Rust or so don't have the full feature set yet, but is it really the protocol to blame? In which way does the protocol make no sense for chat? IRC is extremely complicated as well and a giant pile of hacks.

SamWhited 5y ago
For clients maybe not, but for servers the protocol itself is to blame, yes. A giant distributed graph database where everything has to be synced constantly means you use a ton of memory. IRC is definitely complicated, and arguably a pile of hacks, but an event based system (more or less) makes a lot more sense for chat where you want realtime communication (more or less), not to wait while you sync nodes in the graph to every place that wants them.
- joepie91_ 5y ago
  This makes no sense. Propagating a bunch of messages doesn't suddenly use a ton of memory just because you're organizing them as a graph rather than a linear pubsub-style stream.
  - SamWhited 5y ago
    Sorry, it was a bad explanation. The point is that you have to keep a lot of past state in memory for future messages to make sense and sync properly, unlike an event based system where you (more or less) only need to perform some action when you get an event then forget about it. This is an IRC thread though, sorry I got sucked in but let's not let the Matrix CEO derail it and try to score users. The whole point is is that it didn't make sense for them to switch to matrix because it uses more resources than most IRC servers and because they are trying to be a drop in replacement, not make users sign up for new things.
    - joepie91_ 5y ago
      You don't have to keep that much state in memory at all, actually. I'm not sure why you think that you do. Most of the state resolution (eg. the auth chain) involves calculations of which you can cache the result without needing to care about the inputs beyond that - at least, unless you need to recalculate them once later if delayed events come in. Ultimately, the performance problems that Synapse has are problems with Synapse's implementation choices (especially around the database schema), not with the protocol nor with the state resolution algorithm.
      - TheCycoONE 5y ago
        Presence may be a protocol level issue. My server struggled pretty badly until I disabled it and I see that's generally the advice: https://github.com/matrix-org/synapse/issues/3971 https://github.com/matrix-org/synapse/issues/3971 That doesn't seem like a fundamental issue though.
        Arathorn 5y ago
        It’s a synapse implementation problem, not a protocol issue. And it’s being fixed currently.

Arathorn 5y ago

Wow, that's a lot of negativity. You forgot to disclose your XMPP/XSF affiliation, btw. Matrix as a protocol is neither bloated or slow, and ~32.1M folks have managed to use it successfully, directly or indirectly, as a global chat network. Presumably that counts as a 'large network'; it's certainly bigger than Freenode. Synapse as an implementation has historically been bloated, but it's been steadily improving (and in fact last week's Matrix Live has a fascinating analysis of how the remaining memory usage is being fixed: https://youtu.be/694VuhmVmfo https://youtu.be/694VuhmVmfo). Meanwhile implementations like Dendrite & Conduit are positively skinny.

jrwr 5y ago
Overall, I would pick XMPP over Matrix at this point. it is rather bloated and the clients are a little bit obtuse for newbies. I do wonder what the DAU for Matrix is at this point. as I suspect that 32 Million number might be a little overstated.
- Arathorn 5y ago
  frankly, as long as folks are communicating via open standards rather than being locked into some vendor silo then they should use whatever protocol works best for them - XMPP & Matrix bridge together fairly well these days. Based on the phone-home stats in Synapse there's around 300K DAU currently on the network, but this is a major underestimate given other stats which suggest only about 30% of public servers enable phone-home.
  - zaik 5y ago
    > XMPP & Matrix bridge together fairly well these days Does Matrix support OMEMO for e2e encryption?
    - Arathorn 5y ago
      Yup, OMEMO and Olm are bit compatible. In fact XEP-0384 went through a phase of recommending Olm as the implementation to use (grep https://xmpp.org/extensions/xep-0384.html https://xmpp.org/extensions/xep-0384.html for Olm). (Although the bifrost bridge doesn't currently implement E2EE - and it would have to reencrypt anyway to turn the Matrix event payloads into XMPP stanzas and vice versa)