14 ms·

I've been on Matrix for 6 years or so. Some of that time was painful (especially when the largest public server was overloaded by a surge of new users in 2020).

by foresto 10mo ago

I've been on Matrix for 6 years or so. Some of that time was painful (especially when the largest public server was overloaded by a surge of new users in 2020). It's better now. I can't remember the last time I saw a decryption failure. I still have gripes about it. Improvements to the spec and software have been slow lately, due to funding issues. But they are still arriving. The official desktop client remains buggy, bloated, and cluttered. But there are lighter alternatives that do what I need 99% of the time. Much of the meta-data is not yet end-to-end encrypted. But that's still planned, and since it's not as important in my day-to-day chats as it might be if I were whistleblowing, I'm willing to wait. I continue to use Matrix because there is nothing else offering the combination of features that I most value in it. Notably: - decentralized - 1:1 and group chats - offline message delivery - multi-device support - end-to-end message encryption with well-understood ciphers and protocols - easy enough that I have brought in non-tech-savvy contacts with very little assistance - cross-platform, on every major desktop and mobile OS - not tied to google services or libraries - open-source - free (in both senses) - self-hostable - reasonably anonymous; no need for a real name, phone number, or (depending on homeserver) even an email address - (in development) scalable audio/video chat that looks very promising Harder to quantify, but also worth acknowledging: The project lead seems very level-headed, demonstrating good judgment and tremendous patience, and consistently makes himself and the inner workings of this difficult project accessible to the public. This gives me the sense that Matrix continues to develop with sound guidance. Thanks, Arathorn!

Arathorn 10mo ago
thanks for sticking with it and the vote of confidence. totally agreed that Element Web has issues (i'm currently having to run a custom fork to stop it OOMing thanks to https://github.com/element-hq/element-web/issues/27983#issuecomment-3606125651 https://github.com/element-hq/element-web/issues/27983#issue...); hopefully switching to matrix-rust-sdk will be a huge improvement; https://github.com/element-hq/aurora https://github.com/element-hq/aurora is already looking promising.
pmlnr 10mo ago
XMPP can do everything you listed at a fraction of the resources. It'll also need stub/turn, like everything else for video and voice, but it works.
- foresto 10mo ago
  Free, reliable, enduring servers supporting all the XEPs needed to approach Matrix functionality were scarce when I last surveyed the XMPP landscape. This alone made it not viable for global, general-purpose use. Also, only a tiny handful of clients supporting those XEPs by default were easy to find and set up, and I don't think those few covered all platforms, making the problem worse. (And I don't recall XMPP ever being great at mixing offline delivery with multi-device support, since messages cached on a server weren't guaranteed to be held until all devices retrieved them, but I suppose it's possible that might have been solved by now.) I do miss the Jabber glory days, and I might still consider it for smallish communities where I could reasonably provide the server and tech support, but I don't see it challenging Matrix as a practical choice for the world's general messaging needs.
  - foresto 10mo ago
    Also, STUN/TURN is not sufficient to handle scalable voice and video conferencing. It would take care of NAT traversal, but can't do anything about the bandwidth problem: Each participant would have to maintain a bidirectional A/V channel to each other participant. Many residential internet connections would struggle quickly, and mobile phone bandwidth even more quickly. Adding a selective forwarding unit could solve the outbound bandwidth problem (each participant would then only need one outgoing A/V channel) but can't help with the incoming bandwidth problem (each participant would still need to receive the A/V stream of each other participant). It can't compete with the Matrix design as I understand it. A sufficiently powerful multipoint control unit could solve the bandwidth problem in both directions. But as far as I know, MCUs capable of handling big conferences are not cheap. In other words, I think pmlnr's XMPP endorsement underestimates what it takes to do scalable audio/video chat.

by foresto 10mo ago

Arathorn 10mo ago

thanks for sticking with it and the vote of confidence. totally agreed that Element Web has issues (i'm currently having to run a custom fork to stop it OOMing thanks to https://github.com/element-hq/element-web/issues/27983#issuecomment-3606125651 https://github.com/element-hq/element-web/issues/27983#issue...); hopefully switching to matrix-rust-sdk will be a huge improvement; https://github.com/element-hq/aurora https://github.com/element-hq/aurora is already looking promising.

pmlnr 10mo ago

XMPP can do everything you listed at a fraction of the resources. It'll also need stub/turn, like everything else for video and voice, but it works.

foresto 10mo ago
Free, reliable, enduring servers supporting all the XEPs needed to approach Matrix functionality were scarce when I last surveyed the XMPP landscape. This alone made it not viable for global, general-purpose use. Also, only a tiny handful of clients supporting those XEPs by default were easy to find and set up, and I don't think those few covered all platforms, making the problem worse. (And I don't recall XMPP ever being great at mixing offline delivery with multi-device support, since messages cached on a server weren't guaranteed to be held until all devices retrieved them, but I suppose it's possible that might have been solved by now.) I do miss the Jabber glory days, and I might still consider it for smallish communities where I could reasonably provide the server and tech support, but I don't see it challenging Matrix as a practical choice for the world's general messaging needs.
- foresto 10mo ago
  Also, STUN/TURN is not sufficient to handle scalable voice and video conferencing. It would take care of NAT traversal, but can't do anything about the bandwidth problem: Each participant would have to maintain a bidirectional A/V channel to each other participant. Many residential internet connections would struggle quickly, and mobile phone bandwidth even more quickly. Adding a selective forwarding unit could solve the outbound bandwidth problem (each participant would then only need one outgoing A/V channel) but can't help with the incoming bandwidth problem (each participant would still need to receive the A/V stream of each other participant). It can't compete with the Matrix design as I understand it. A sufficiently powerful multipoint control unit could solve the bandwidth problem in both directions. But as far as I know, MCUs capable of handling big conferences are not cheap. In other words, I think pmlnr's XMPP endorsement underestimates what it takes to do scalable audio/video chat.