> That's not entirely true though. Press voice call in a client and you may end up with an embedded jitsi, some WebRTC thing, or nothing at all. That's exactly how xmpp clients started to diversify.
This really isn't an example of protocol fragmentation - it's behaving precisely as expected.
There is precisely one way to do a 1:1 VoIP/Video call in Matrix: https://matrix.org/docs/spec/client_server/r0.6.1#voice-over.... It hasn't actually changed since 2015 when we first added it to the spec, until recently when there's a proposal to improve it called MSC2746: https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... Now, this is a proposal to patch the spec - it's a Matrix Spec Change. It retains backwards compatibility with the current behaviour, and once the MSC is approved it'll be merged into the spec and the MSC will be discarded.
There is precisely one way currently to do VoIP/Video conferences in Matrix: you instantiate a 'widget', to embed whatever web conferencing service you like into your chat room (e.g. Jitsi). You use the widget API to control it. Widgets aren't actually merged into the spec yet, but are specified at MSC1236 (https://github.com/matrix-org/matrix-doc/issues/1236), which should get reviewed and merged in real soon now. So, as long as your client implements widgets, you can do conferences. In future, we have plans for native Matrix conferences (MSC2359), but this is vapourware.
Finally, if your client doesn't implement 1:1 and doesn't implement widgets (or if your don't have permission to perform them in that room) then obviously hitting the call button won't work. But that's hardly fragmentation; it's just incomplete implementations.
Now, if there were multiple competing ways of doing 1:1 calls, or of doing conferences flying around, I'd totally agree we were seeing XMPP-style fragmentation. But we're not, and if we did, we'd see that as a massive bug and jump on it to resolve the fork in the Matrix Spec Core Team, and ensure that matrix.org/docs/spec resolved the collision asap.
> Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Perhaps, but that's not me or the Matrix core team doing that (well, other than back in the very early days when I was still feeling a bit salty about XMPP). We can't control what randoms on the internet say though :|
> There is precisely one way to do a 1:1 VoIP/Video call in Matrix
Yeah, that's awfully close to what the xmpp people used to say. There are rtc calls and there are conferences, and otp is something else than omemo entirely.
For the end user however, when they click that telephone icon in their client, they may or may not get an embedded widget of some type or other, or an rtc stream, or something else. Should the remote client support the same thingamajig, they get a voice call. Look at the dozen or so most popular Matrix clients and for a non-technical user, it's still a gamble.
It's pretty much comparable to email in the 90s. Send a file, and it may end up as a uuencoded Mail Attachment, or perhaps a base64 encoded MIME. In the latter case it may be a multipart MIME or a non-multipart. Non-technical users sometimes couldn't open the file and then you had to send it some other way. Over time some clients got important enough for a de facto standard to emerge. It's still not perfect in 2021, one well known software company insists on their own .eml attachment that doesn't always work.
Matrix is quite similar to xmpp in this regard. Take the dozen most popular clients for each protocol, and check off how many popular features (voice calls, e2e, profiles, conferences, screen sharing etc.) interoperate fully. There's certainly room for improvement.
Don't take this the wrong way however! This is the price we pay for open protocols. If the alternative is low protocol innovation, then bring on the interop testing and annoyed users! It's worth it.
> aren't actually merged into the spec yet, but are specified at MSC1236
You even have standards proposals! They have numbers. Great! Let me guess, you bunch them up, spread some holy standardization water on them, recite an incantation and then they are part of an Offical Standard. Guess how many other protocols developers do that?
> that's not me or the Matrix core team doing that
Again, the tone could certainly be improved. One needs to look no further than this thread, to see other software developers being told in exactly how many ways their standard suck.
Take pride instead in what you did, and if someone asks you again why you didn't use the existing standard to build your chat product, just tell them you had more fun that way. Don't say inefficiency, don't say battery management, don't say interop when all of those metrics aren't looking any better in Matrix. Tell them about the nice team web chat you did, which is plenty reason to use it.
Most of the fragmentation in the XMPP ecosystem is just incomplete implementations.
> We can't control what randoms on the internet say though :|
You could acknowledge Matrix's shortcomings instead of denying or minimizing almost every criticism. And not say things like "It's fine to dislike Matrix and pine for XMPP, but please don't spread FUD."
> 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.
...which is by far the biggest shortcoming of Matrix I'm aware of. I reserve the right to refute the inaccurate criticisms though (and to call them FUD, if that's what they are :)
This really isn't an example of protocol fragmentation - it's behaving precisely as expected.
There is precisely one way to do a 1:1 VoIP/Video call in Matrix: https://matrix.org/docs/spec/client_server/r0.6.1#voice-over.... It hasn't actually changed since 2015 when we first added it to the spec, until recently when there's a proposal to improve it called MSC2746: https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... Now, this is a proposal to patch the spec - it's a Matrix Spec Change. It retains backwards compatibility with the current behaviour, and once the MSC is approved it'll be merged into the spec and the MSC will be discarded.
There is precisely one way currently to do VoIP/Video conferences in Matrix: you instantiate a 'widget', to embed whatever web conferencing service you like into your chat room (e.g. Jitsi). You use the widget API to control it. Widgets aren't actually merged into the spec yet, but are specified at MSC1236 (https://github.com/matrix-org/matrix-doc/issues/1236), which should get reviewed and merged in real soon now. So, as long as your client implements widgets, you can do conferences. In future, we have plans for native Matrix conferences (MSC2359), but this is vapourware.
Finally, if your client doesn't implement 1:1 and doesn't implement widgets (or if your don't have permission to perform them in that room) then obviously hitting the call button won't work. But that's hardly fragmentation; it's just incomplete implementations.
Now, if there were multiple competing ways of doing 1:1 calls, or of doing conferences flying around, I'd totally agree we were seeing XMPP-style fragmentation. But we're not, and if we did, we'd see that as a massive bug and jump on it to resolve the fork in the Matrix Spec Core Team, and ensure that matrix.org/docs/spec resolved the collision asap.
> Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Perhaps, but that's not me or the Matrix core team doing that (well, other than back in the very early days when I was still feeling a bit salty about XMPP). We can't control what randoms on the internet say though :|