5 ms·

> It's 2022 and there is still nothing better for federated messaging. That is untrue. Matrix is undoubtedly much better.

Andrew_nenakhov 5y ago
Lol no. It is a monolithic monster that will never see any other independent server vendor. Matrix is a product with a public API, not a protocol.
- andrewshadura 5y ago
  This is, again, untrue.
  - Andrew_nenakhov 5y ago
    As jhugo said in a sister subthread, it doesn't become true if you repeat it again and again.
jhugo 5y ago
No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers). Just because they made a foundation and threw around the word "standard" a lot doesn't mean it deserves to be the standard for chat protocols.
- wusspuss 5y ago
  >No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Maybe judge not by reading protocol description but by trying and using said protocol, like, chatting with people a lot? With the latter approach you'll notice a very handy feature of Matrix - not losing messages.
  - jhugo 5y ago
    I've experienced lost messages multiple times with Matrix, but I suspect this was due to the shitty clients rather than the protocol. Not losing messages is also a feature of XMPP. In the distant past, especially before stream management, various kinds of network issue could certainly cause lost messages. These days, almost all implementations support the necessary features to make lost messages virtually impossible (of course, being federated, it's always possible that e.g. the remote server is permanently shut down just after successfully accepting your message, but that risk exists in all protocols including Matrix.)
    - Andrew_nenakhov 5y ago
      Btw in Xabber we've decisively solved the message loss problem by introducing an extension that forces a client-set message id on a message and expects a server-set and a timestamp in a confirmation receipt.
      - jhugo 5y ago
        Is this extension on the XMPP standards track? From my perspective, the message loss problem has been solved for some time using only standard extensions.
        Andrew_nenakhov 5y ago
        It will be, eventually. Though i think that XSF needs a revolt to stop them doing their thing the way they do. From what I get from their council meetings, they feel everything is fine. It is not. Regarding the standard extensions, the most common way to prevent message loss is by using stream management, however there are edge cases in SM when the messages can still be lost in milti-device scenario. It is not surprising, SM was not meant to prevent message loss per se, just to resume a stream. The main problem of XMPP on modern mobile devices is this: XMPP is designed to be always connected, while modern OS shut down apps when they are in background. So to make XMPP fit in the modern world we needed to make a transition from a resumption of stream to a synchronisation of state.
- joepie91_ 5y ago
  > Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers). Hi, I've worked on client and server implementations of both XMPP and Matrix. This is a wildly inaccurate - but unfortunately common - view of things. It's correct that Matrix is complex to implement server-side, more complex than XMPP, and it's also correct that it does a lot of things very differently from older protocols like XMPP. But here's the thing - that's a deliberate choice and it is for good reasons, not just a case of ignorance or "bloat" like you seem to be implying. (Sidenote: if there's one thing I've learned over the years, it's that somebody talking about "bloat" is a huge red flag that they don't have a very deep understanding of something. If you have a genuine complaint about unnecessary complexity, you should be able to point it out specifically, instead of a handwavy term like that.) Anyway, to get back to the point... much of the complexity in Matrix comes from a single design objective that differs from XMPP: it implements decentralized rooms instead of centralized ones. That is, rooms are not dependent on a single server for their continued existence, they will remain available regardless of server availability. This might seem irrelevant, but it solves a huge problem that XMPP has been struggling with for years, and that IMO is a major reason why its MUCs never became widespread: the problem of putting trust in a server operator for the continued existence of your community. Every single time you create a MUC in XMPP, you are essentially betting on the continued existence of whatever server you are creating that MUC on. If it ever goes away, so does your community - and unlike with a list of private contacts, it's hard to rebuild a community. That's a tremendous cognitive overhead for starting a community! And one that most non-techies - understandably - do not want to have to deal with. Trust is hard. Matrix doesn't have this problem because of its decentralized rooms; it doesn't matter how many servers go away, as long as the homeserver of at least one room participant still exists, the room continues functioning as it always has. That means that you create a room "on Matrix", not "on a specific homeserver". That's much easier for users to deal with. The tradeoff is that unlike with XMPP, where you have a single authorative server for handling things like access control and moderation and membership, this needs to function entirely decentrally in Matrix - so now, the network is suddenly a distributed system that needs to handle state synchronization and everything that that entails. And that is where the server-side complexity in Matrix comes from. It is necessary, unavoidable complexity if you want to solve the problem of "where do I put my community" in a way that actually works for regular users. It sucks, but there simply is no simpler way to solve this problem. The reason XMPP doesn't have this complexity is because it doesn't even try to solve this problem. If the rumoured decentralized MUCs ever become a thing, they will involve similar complexity. Edit: Also, it would be nice if y'all recognized that the priority should be to get the general public over to open comms systems, instead of constantly trying to start wars against Matrix folks. The constant loud misinformation and attacks are getting very exhausting.
- eternityforest 5y ago
  Matrix might have bad core tech, but they are one of the only groups working on the biggest issue with federation. Tying identity to a server is insane in a decentralized environment. Decentralization is all about keeping Google sized companies from controlling things. But small companies come and go all the time, and nobody trusts them to be around in 10 years. They aren't solving the SSL problem though. Mumble has a good solution their with their trust on first use connections. Self hosted really should ideally not need a domain name if you want individuals to host it. It should be something you can literally buy a $20 preconfigured hosting node, plug it in, and go. Tox seems to be most promising of current ones, it just needs to fix it's mobile data use issues.
  - jhugo 5y ago
    A $20 preconfigured hosting node could easily include a domain name. Tying identity to a domain name uses the existing, actually decentralised, widely adopted since ~40 years, infrastructure of the DNS. Instead of throwing existing technology out and trying to build everything from scratch (which we should see clearly for what it really is: an attempt to retain more control), Internet standards like XMPP build upon what came before.
    - sam_lowry_ 5y ago
      There are many cloud instances below 5$/ month and domain names in that price range/year.
    - IYasha 4y ago
      Domain name isn't your property and can be taken away on a whim. It is BAD for ID. It's NOT in your possession, you only rent it. If your domain gets taken away, unpaid, hacked, banned - you're done. Eventually I even stopped using DNS and feeding domain registrators. At least because I hate paying for things that should be mine.
  - Andrew_nenakhov 5y ago
    > but they are one of the only groups working on the biggest issue with federation. This issue you are talking about is reliably solved ny owning your own domain. You can self-host it or use the commercial provider for it, either way you can change provider and retain your address. And regarding these matrix guys, they are so overtaken by a NIH syndrome [1] that they couldn't even follow a common URI syntax. Are you really sure they are best fit to develop standard protocols of any kind? [1]: https://en.m.wikipedia.org/wiki/Not_invented_here https://en.m.wikipedia.org/wiki/Not_invented_here
- andrewshadura 5y ago
  > A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. You're right, Matrix immediately stands out as what XMPP should have been from the beginning.

Andrew_nenakhov 5y ago

Lol no. It is a monolithic monster that will never see any other independent server vendor. Matrix is a product with a public API, not a protocol.

andrewshadura 5y ago
This is, again, untrue.
- Andrew_nenakhov 5y ago
  As jhugo said in a sister subthread, it doesn't become true if you repeat it again and again.

jhugo 5y ago

No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers). Just because they made a foundation and threw around the word "standard" a lot doesn't mean it deserves to be the standard for chat protocols.

wusspuss 5y ago
>No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Maybe judge not by reading protocol description but by trying and using said protocol, like, chatting with people a lot? With the latter approach you'll notice a very handy feature of Matrix - not losing messages.
- jhugo 5y ago
  I've experienced lost messages multiple times with Matrix, but I suspect this was due to the shitty clients rather than the protocol. Not losing messages is also a feature of XMPP. In the distant past, especially before stream management, various kinds of network issue could certainly cause lost messages. These days, almost all implementations support the necessary features to make lost messages virtually impossible (of course, being federated, it's always possible that e.g. the remote server is permanently shut down just after successfully accepting your message, but that risk exists in all protocols including Matrix.)
  - Andrew_nenakhov 5y ago
    Btw in Xabber we've decisively solved the message loss problem by introducing an extension that forces a client-set message id on a message and expects a server-set and a timestamp in a confirmation receipt.
    - jhugo 5y ago
      Is this extension on the XMPP standards track? From my perspective, the message loss problem has been solved for some time using only standard extensions.
      - Andrew_nenakhov 5y ago
        It will be, eventually. Though i think that XSF needs a revolt to stop them doing their thing the way they do. From what I get from their council meetings, they feel everything is fine. It is not. Regarding the standard extensions, the most common way to prevent message loss is by using stream management, however there are edge cases in SM when the messages can still be lost in milti-device scenario. It is not surprising, SM was not meant to prevent message loss per se, just to resume a stream. The main problem of XMPP on modern mobile devices is this: XMPP is designed to be always connected, while modern OS shut down apps when they are in background. So to make XMPP fit in the modern world we needed to make a transition from a resumption of stream to a synchronisation of state.
joepie91_ 5y ago
> Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers). Hi, I've worked on client and server implementations of both XMPP and Matrix. This is a wildly inaccurate - but unfortunately common - view of things. It's correct that Matrix is complex to implement server-side, more complex than XMPP, and it's also correct that it does a lot of things very differently from older protocols like XMPP. But here's the thing - that's a deliberate choice and it is for good reasons, not just a case of ignorance or "bloat" like you seem to be implying. (Sidenote: if there's one thing I've learned over the years, it's that somebody talking about "bloat" is a huge red flag that they don't have a very deep understanding of something. If you have a genuine complaint about unnecessary complexity, you should be able to point it out specifically, instead of a handwavy term like that.) Anyway, to get back to the point... much of the complexity in Matrix comes from a single design objective that differs from XMPP: it implements decentralized rooms instead of centralized ones. That is, rooms are not dependent on a single server for their continued existence, they will remain available regardless of server availability. This might seem irrelevant, but it solves a huge problem that XMPP has been struggling with for years, and that IMO is a major reason why its MUCs never became widespread: the problem of putting trust in a server operator for the continued existence of your community. Every single time you create a MUC in XMPP, you are essentially betting on the continued existence of whatever server you are creating that MUC on. If it ever goes away, so does your community - and unlike with a list of private contacts, it's hard to rebuild a community. That's a tremendous cognitive overhead for starting a community! And one that most non-techies - understandably - do not want to have to deal with. Trust is hard. Matrix doesn't have this problem because of its decentralized rooms; it doesn't matter how many servers go away, as long as the homeserver of at least one room participant still exists, the room continues functioning as it always has. That means that you create a room "on Matrix", not "on a specific homeserver". That's much easier for users to deal with. The tradeoff is that unlike with XMPP, where you have a single authorative server for handling things like access control and moderation and membership, this needs to function entirely decentrally in Matrix - so now, the network is suddenly a distributed system that needs to handle state synchronization and everything that that entails. And that is where the server-side complexity in Matrix comes from. It is necessary, unavoidable complexity if you want to solve the problem of "where do I put my community" in a way that actually works for regular users. It sucks, but there simply is no simpler way to solve this problem. The reason XMPP doesn't have this complexity is because it doesn't even try to solve this problem. If the rumoured decentralized MUCs ever become a thing, they will involve similar complexity. Edit: Also, it would be nice if y'all recognized that the priority should be to get the general public over to open comms systems, instead of constantly trying to start wars against Matrix folks. The constant loud misinformation and attacks are getting very exhausting.
eternityforest 5y ago
Matrix might have bad core tech, but they are one of the only groups working on the biggest issue with federation. Tying identity to a server is insane in a decentralized environment. Decentralization is all about keeping Google sized companies from controlling things. But small companies come and go all the time, and nobody trusts them to be around in 10 years. They aren't solving the SSL problem though. Mumble has a good solution their with their trust on first use connections. Self hosted really should ideally not need a domain name if you want individuals to host it. It should be something you can literally buy a $20 preconfigured hosting node, plug it in, and go. Tox seems to be most promising of current ones, it just needs to fix it's mobile data use issues.
- jhugo 5y ago
  A $20 preconfigured hosting node could easily include a domain name. Tying identity to a domain name uses the existing, actually decentralised, widely adopted since ~40 years, infrastructure of the DNS. Instead of throwing existing technology out and trying to build everything from scratch (which we should see clearly for what it really is: an attempt to retain more control), Internet standards like XMPP build upon what came before.
  - sam_lowry_ 5y ago
    There are many cloud instances below 5$/ month and domain names in that price range/year.
  - IYasha 4y ago
    Domain name isn't your property and can be taken away on a whim. It is BAD for ID. It's NOT in your possession, you only rent it. If your domain gets taken away, unpaid, hacked, banned - you're done. Eventually I even stopped using DNS and feeding domain registrators. At least because I hate paying for things that should be mine.
- Andrew_nenakhov 5y ago
  > but they are one of the only groups working on the biggest issue with federation. This issue you are talking about is reliably solved ny owning your own domain. You can self-host it or use the commercial provider for it, either way you can change provider and retain your address. And regarding these matrix guys, they are so overtaken by a NIH syndrome [1] that they couldn't even follow a common URI syntax. Are you really sure they are best fit to develop standard protocols of any kind? [1]: https://en.m.wikipedia.org/wiki/Not_invented_here https://en.m.wikipedia.org/wiki/Not_invented_here
andrewshadura 5y ago
> A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. You're right, Matrix immediately stands out as what XMPP should have been from the beginning.