5 ms·

> And the Matrix reference server needs pretty powerful hardware. That is not a bug, its a feature (or so the Matrix people say). In fact, part of the Matrix

> And the Matrix reference server needs pretty powerful hardware. That is not a bug, its a feature (or so the Matrix people say). In fact, part of the Matrix design is a fat server which has a lot more responsibilities by default than an XMPP server. However, I guess a full-featured XMPP server (with MAM, Push, etc.) probably has similar requirements.

pseudalopex 6y ago
The Matrix people don't say it's a feature. They say the rewrite will fix it. XMPP with MAM and push doesn't have similar requirements.
- Arathorn 6y ago
  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.
  - remram 6y ago
    It's late beta but no push notifications (!!), no presence, no search, no cross-signing of E2E keys, no clustered deployments.
derefr 6y ago
I've been wondering for a while how hard it would be to adapt Ejabberd into being a Matrix server implementation. Only a small part of Ejabberd is actually all that XMPP-specific.

pseudalopex 6y ago

The Matrix people don't say it's a feature. They say the rewrite will fix it. XMPP with MAM and push doesn't have similar requirements.

Arathorn 6y ago
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.
- remram 6y ago
  It's late beta but no push notifications (!!), no presence, no search, no cross-signing of E2E keys, no clustered deployments.

derefr 6y ago

I've been wondering for a while how hard it would be to adapt Ejabberd into being a Matrix server implementation. Only a small part of Ejabberd is actually all that XMPP-specific.