5 ms·

There's some confusion here. * Dendrite ("the rewrite") uses about 5-10x less RAM than Synapse; it's in relatively late beta and you can see for yourself today

There's some confusion here. * Dendrite ("the rewrite") uses about 5-10x less RAM than Synapse; it's in relatively late beta and you can see for yourself today. For instance, dendrite.matrix.org is currently sitting at 480MB of RAM, despite being in ~5000 rooms spanning ~150K users. * Matrix is coherent no matter what clients you use, given there is only one version of the spec (and as it happens, we haven't broken backwards compatibility yet). Sure, some implementations might not have implemented all the features, but the features they do implement (assuming they're not buggy) will work reliably with any other client or server out there. It's fine to dislike Matrix and pine for XMPP, but please don't spread FUD.

pseudalopex 6y ago
The third party Matrix ecosystem is exactly as coherent as the XMPP ecosystem. Sure, some implementations might not have implemented all the XEPs, but the XEPs they do implement (assuming they're not buggy) will work reliably with any other client or server out there. I'll like Matrix when it can replace XMPP. Dendrite sounds like a step in that direction when it's mature. Please stop spreading FUD about XMPP.
- Arathorn 6y ago
  The difference is that there are multiple different XEPs performing similar operations, and even with the compliance suite XEPs, it can be confusing to synchronise on whether different bug-free clients are speaking the same dialect. Whereas Matrix ensures that there is only ever one way of doing a given operation at any point, and those operations are backwards compatible, because there's only one spec. Obviously the client and server you're talking to needs to have actually correctly implemented the bits of the spec that you're trying to use - but there's no openpgp v. OMEMO or rival file transfer mechanisms etc. It's only a difference in governance, but it's an important one. Obviously, a single monolithic spec controlled by a committee like the matrix spec core team has its own problems (most importantly, the committee can become a bottleneck); and we still provide mechanisms to let people experiment via the equivalent of vendor prefixing, which can go horribly wrong (c.f. aggregations in Matrix) if not managed with discipline. But, I'm not trying to spread FUD about XMPP - just try to explain that the approaches taken are different, and have different tradeoffs, and are not "exactly the same".
  - petre 6y ago
    > Whereas Matrix ensures that there is only ever one way of doing a given operation at any point Python used to claim the same thing when it was a fresh new language, as a reaction to Perl where the opposite was encouraged. Becoming mature and anchored in reality changed some of that.
  - arendtio 6y ago
    > Whereas Matrix ensures that there is only ever one way of doing a given operation at any point I trust you that you mean what you say, but I wonder what an implementation would look like (from a user-perspective), that supports something like OpenPGP -> OTR -> Ratchet. I mean, upgrading security over time is mandatory and when I remember how it evolved for XMPP I clearly do not want an implementation that still has all the draw-backs that OTR had. So I agree that XMPP is lacking some good governance, but I don't see the rivaling XEPs necessarily as the core problem, as many of them had quite some time between the drafts. The bigger issue is that many clients don't have enough developer momentum, so that XEPs that were drafted like 5 years ago are not implemented yet. Regarding implementation bugs: I know XMPP has the compliance suite, but I feel like it doesn't catch bugs and is more of a basic testing for feature compatibility. Does Matrix have some kind of test suite, that simulates physical disconnects, package loss and the likes for testing real client and server implementations? I know that would not be an easy feat, but I wonder what the best way would be to build something like that, to improve the quality of the existing implementations.
    - pseudalopex 6y ago
      OpenPGP could mean XEP-0374 which is newer than OTR. But XEP-0374 went from experimental to deferred 3 years ago. It isn't really competing with OMEMO.
      - arendtio 6y ago
        XEP-0374 is very fresh compared to other PGP-related extensions. Just to give an example, 'XEP-0027: Current Jabber OpenPGP Usage' became active in 2002. If it is competing with OMEMO or not might be a separate discussion, but both can be used to utilize E2E encryption of messages.
- selfhoster11 6y ago
  Some implementations not implementing all the XEPs is exactly my point. "A Matrix server" / "a Matrix client" conveys an expectation that certain functionality will be included. Low-feature implementations will exist, but I assume it will be clear they serve a niche.
  - pseudalopex 6y ago
    Synapse is the only fully featured server. Element Web/Desktop is the only fully featured client. Most of the other servers and clients are aiming for general use. They're just incomplete. Some of the niche implementations like weechat-matrix are in better shape actually.[1] [1] https://matrix.org/clients-matrix/ https://matrix.org/clients-matrix/
    - selfhoster11 6y ago
      Dendrite is meant to be good too.
remram 6y ago
It's late beta but no push notifications (!!), no presence, no search, no cross-signing of E2E keys, no clustered deployments.

pseudalopex 6y ago

The third party Matrix ecosystem is exactly as coherent as the XMPP ecosystem. Sure, some implementations might not have implemented all the XEPs, but the XEPs they do implement (assuming they're not buggy) will work reliably with any other client or server out there. I'll like Matrix when it can replace XMPP. Dendrite sounds like a step in that direction when it's mature. Please stop spreading FUD about XMPP.

Arathorn 6y ago
The difference is that there are multiple different XEPs performing similar operations, and even with the compliance suite XEPs, it can be confusing to synchronise on whether different bug-free clients are speaking the same dialect. Whereas Matrix ensures that there is only ever one way of doing a given operation at any point, and those operations are backwards compatible, because there's only one spec. Obviously the client and server you're talking to needs to have actually correctly implemented the bits of the spec that you're trying to use - but there's no openpgp v. OMEMO or rival file transfer mechanisms etc. It's only a difference in governance, but it's an important one. Obviously, a single monolithic spec controlled by a committee like the matrix spec core team has its own problems (most importantly, the committee can become a bottleneck); and we still provide mechanisms to let people experiment via the equivalent of vendor prefixing, which can go horribly wrong (c.f. aggregations in Matrix) if not managed with discipline. But, I'm not trying to spread FUD about XMPP - just try to explain that the approaches taken are different, and have different tradeoffs, and are not "exactly the same".
- petre 6y ago
  > Whereas Matrix ensures that there is only ever one way of doing a given operation at any point Python used to claim the same thing when it was a fresh new language, as a reaction to Perl where the opposite was encouraged. Becoming mature and anchored in reality changed some of that.
- arendtio 6y ago
  > Whereas Matrix ensures that there is only ever one way of doing a given operation at any point I trust you that you mean what you say, but I wonder what an implementation would look like (from a user-perspective), that supports something like OpenPGP -> OTR -> Ratchet. I mean, upgrading security over time is mandatory and when I remember how it evolved for XMPP I clearly do not want an implementation that still has all the draw-backs that OTR had. So I agree that XMPP is lacking some good governance, but I don't see the rivaling XEPs necessarily as the core problem, as many of them had quite some time between the drafts. The bigger issue is that many clients don't have enough developer momentum, so that XEPs that were drafted like 5 years ago are not implemented yet. Regarding implementation bugs: I know XMPP has the compliance suite, but I feel like it doesn't catch bugs and is more of a basic testing for feature compatibility. Does Matrix have some kind of test suite, that simulates physical disconnects, package loss and the likes for testing real client and server implementations? I know that would not be an easy feat, but I wonder what the best way would be to build something like that, to improve the quality of the existing implementations.
  - pseudalopex 6y ago
    OpenPGP could mean XEP-0374 which is newer than OTR. But XEP-0374 went from experimental to deferred 3 years ago. It isn't really competing with OMEMO.
    - arendtio 6y ago
      XEP-0374 is very fresh compared to other PGP-related extensions. Just to give an example, 'XEP-0027: Current Jabber OpenPGP Usage' became active in 2002. If it is competing with OMEMO or not might be a separate discussion, but both can be used to utilize E2E encryption of messages.
selfhoster11 6y ago
Some implementations not implementing all the XEPs is exactly my point. "A Matrix server" / "a Matrix client" conveys an expectation that certain functionality will be included. Low-feature implementations will exist, but I assume it will be clear they serve a niche.
- pseudalopex 6y ago
  Synapse is the only fully featured server. Element Web/Desktop is the only fully featured client. Most of the other servers and clients are aiming for general use. They're just incomplete. Some of the niche implementations like weechat-matrix are in better shape actually.[1] [1] https://matrix.org/clients-matrix/ https://matrix.org/clients-matrix/
  - selfhoster11 6y ago
    Dendrite is meant to be good too.

remram 6y ago

It's late beta but no push notifications (!!), no presence, no search, no cross-signing of E2E keys, no clustered deployments.