3 ms·

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.

by pmlnr 10mo ago

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.

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.

by 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.