1. 38
    1. 11

      These days, I am unsure what Matrix is heading for. This post explains that they want to have VoIP video conferencing and decentralised virtual reality. Then I open the lobste.rs comments and the first thing I see is a comparison to IRC.

      It seems as if Matrix’ mission statement today is going far beyond the goal to open up walled text message gardens. From this post it looks as if they want to make Matrix a decentralised platform for everything. The post talks explicitely about the success of the open web and how Matrix strives to copy it, and that makes me think: don’t we already have the open web? It’s built on a protocol called HTTP. Does this mean Matrix wants to replace HTTP?

      If Matrix is indeed inferior even to IRC (I cannot judge as I do not use Matrix) in the domain IRC occupies (text messaging), such a wide approach seems doomed.

      1. 10

        We’ve always tried to be clear that Matrix is a general purpose comms protocol for realtime data - not just chat. For instance, right from the original launch in Sept 2014 we had VoIP signalling in there too, and did a very basic demo of 3D over Matrix on day 1 too: https://techcrunch.com/video/animatrix-presents-disrupt-sf-2014-hackathon/

        The post talks explicitely about the success of the open web and how Matrix strives to copy it, and that makes me think: don’t we already have the open web? It’s built on a protocol called HTTP. Does this mean Matrix wants to replace HTTP?

        Obviously we’re not trying to replace HTTP. Matrix is an API layered on top of HTTP (or other transports) to provide a communication layer for realtime data. If anything it competes with ActivityStreams as a way to link streams of activity over the open web - except with a completely different architecture. The reason for invoking the open web is that we simply want to be the comms layer for the open web: a global realtime virtual space where folks can chat, talk, interact, and publish/subscribe to realtime data of any kind.

        W3C simply doesn’t provide an API for that, yet - and if they did, hopefully it might be Matrix.

      2. 4

        The open web is not a federated eventually consistent database. That’s what matrix provides. https://matrix.org/ for more info. An update for people following the blog doesn’t cover the introduction.

        Text chat is the first application, but matrix can be used for much more.

    2. 9

      I’ve really enjoyed using Matrix, hopefully when sync is faster I can lure more of my friends to use it.

      1. 3

        meh…Startup (initial connection delay) is considerably slower that IRC. It’s a bit of a downgrade in terms of overall polish of clients too (but again, IRC is soo much bare-bones so it’s simpler by design)

        1. 5

          IRC is nice but I prefer Matrix over it due to the ease of use: I got my fiancee to use Matrix with me on my homeserver, but I doubt i would’ve ever got her use IRC. :)

          1. 2

            I got my parents to use IRC in early 2000s. It wasn’t that difficult, just installed an irc client that automatically connects to a server and channel.

            Matrix would be a hard sell now that Telegram and Whatsapp exist.

            1. 8

              the point of the OP is that Matrix clients have to be better than TG or WhatsApp to win, and that’snwhat we’re aiming for.

              1. 4

                In my experience using Matrix for the last several years, most Matrix clients seem to be struggling to keep up in terms of features/functionality. Which is unfortunate, because the official clients that are web/browser based are slow and frustrating to use on older devices. That said, the Android Element.io app is not too bad :)

                I think supporting multiple (unofficial…) clients is very important, since it prevents “vendor lock in”, which can totally happen even when the protocol is federated if everyone ends up depending on the official client and (hypothetically, but not totally impossible…) it is sold/acquired by some nefarious company in the future… I don’t know if the current situation is from Matrix being some quickly moving target, or if implementing the features is just… hard. In any case, it’s not great having such limited options for clients.

                1. 5

                  I wouldn’t say that “most” matrix clients are struggling to keep up in features/functionality - it’s more that we’re still figuring out some features (as per the OP) and everyone (including Element) is playing catchup to a fast moving target.

                  Totally agreed that vendor lockin is a total antigoal. Element is not the “official” Matrix client - it’s just a client, like Netscape was just a browser in the early days of the web. It happens to be written by the team who created Matrix, but the two are separate these days: matrix.org/foundation v element.io/careers.

                  In terms of native Desktop apps, we’re hoping matrix-rust-sdk will power a new generation of excellent native apps - ElementX iOS supports macOS too, for instance, and Fractal-next is already a GTK app based on rust-sdk.

                  1. 2

                    and Fractal-next is already a GTK app based on rust-sdk.

                    Yeah… but that doesn’t even support E2EE[1]. I consider that to be a major feature of Matrix, without it Matrix is just a slower way to exchange unencrypted text online. Last time I looked, a few Matrix clients were struggling to implement E2EE.

                    1. https://gitlab.gnome.org/GNOME/fractal/-/issues/717
                    1. 2

                      If you look at the checkboxes on that bug, all the hard bits are already done (thanks to leaning on matrix-rust-sdk). You can literally use Fractal-next for E2EE today. They just need to hook up UI for the remaining edge cases (eg key backups). In terms if why that hasn’t happened yet… it’s a FOSS project; PRs welcome.

                      1. [Comment removed by author]

                  2. 1

                    Just want to give shoutout to Nheko! I use it daily on my desktop.

    3. 5

      They fell for the metaverse meme… As always, their priorities just don’t align with what users want.

      1. 7

        That’s a bit dismissive when most of the article is not about their new VR/3d space feature and rather about improving the existing situation. And as all of these are released at once, they seem to have the capacity to do it both (and it also doesn’t mean anything gets faster if your stop developing the other part).

      2. 2

        Like “metaverse” or not, having an open alternative for it is a positive thing.

    4. 5

      I’m a little worried about the constant focus on features when the basic experience of just text chats and such can be really rough, in terms of inconsistency and client/server performance. It needs more polish, but what attention is there to give when you’re on the next big thing?

      1. 7

        literally the whole point of the original post is to spell out the emphasis we’re putting on perf and usability atm. Only the second half of the post talks about new features (which happens in entirely different teams)

    5. 4


      However, given that users are now used to WYSIWYG in Teams and Slack, we’ve now decided to have another go at it

      You link to a blog post that shows issues with Slack WYSIWYG, but creating richly formatted messages in MS Teams is also an incredible daily source of frustrations, with no way to opt-out and just use Markdown without that awful dynamic interpolation. I hope just writing Markdown to format messages will still be an option in Element when/if this WYSIWYG editor is introduced.

      1. 4

        don’t worry - markdown will not be going away. this is just adding wysiwyg as an option for those who want it (and for parity with Teams)

    6. 4

      While the way to go forward is interesting, and Matrix is an excellent piece of engineering, it lacks in several areas still, which I would have expected to work flawlessly by now. This is from my own experimenting with the protocol and surrounding server/clients:

      • 1:1 calling is lacking, TURN appears to rarely work. Calling from mobile (Android) to Desktop and reverse works <50% of the time
      • If you’re logged into both mobile (Android) and desktop, an incoming call picked up by Desktop will continue ringing on the mobile, until it drains the battery. The call pickup even is aparently not properly handled when mobile lockscreen is active.
      • Recently, my mobile notifications and message history on mobile is completely off. It appears to be “receiving” messages minutes after they appear on my desktop. Comparing mobile and desktop message history reveals completely out-of-order messages, or simply not-received-on-mobile ones

      It feels to me that every time the core features are stable, at least on mobile, something happens in the matrix world that triggers new features that replace the stable features with something new (often incomplete) leaving core functionality flawed. It happened with Riot -> RiotX, and it seems to happen again with Element -> Element X. This is one of the reasons I’ve stopped reporting issues with mobile clients, as there’s no point, a “new” mobile client will most likely soon appear and the cycle will start again.

      1. 6

        Agreed that RiotX on Android still has some major bugs (which is frustrating, given how long it’s been around). ElementX on Android will likely not be a rewrite however: it is “just” replacing the Kotlin SDK with the Rust SDK, and replacing the calling implementation with Element Call (so we get native conferencing as well as 1:1) - which should address both issues you’ve mentioned here.

        1. 1

          Will the voice/video call functionality be part of the Rust SDK? How are you implementing WebRTC on the mobile platforms, where presumably running a browser engine’s WebRTC stack inside a web view wouldn’t be a good solution? Are you using the Google WebRTC C++ library directly, do you have some kind of wrapper over it, or are you using a different WebRTC implementation?

          1. 4

            currently the plan is to run webrtc inside a webview, as per the matryoshka section of the OP. the current mobile apps use libwebrtc directly, with limited success (as you can see from the original comment here), so given we’re switching to multiway native Matrix VoIP the idea is to switch to embedding the Element Call webapp, and then replace that with native impls only if performance actually requires it. So far, webrtc in a webview is actually working fine, and avoids us having to build a new native impl of the relatively complex multiway calling on each platform.

            Alternatively, others are very welcome to go wild with libwebrtc or webrtc-rs on top of matrix-rust-sdk or others. After all, it’s all open…

      2. 4

        The slow receiving messages on mobile will probably be fixed by the new sync. Mobile clients don’t currently keep syncing all the time in order to save battery. When a push notification arrives, the mobile client needs to sync in order to receive all the relevant data. That takes a long time and lots of data on sync v2. Exactly what sync v3 is supposed to fix.

    7. 3

      I hope the new native clients are better. My friends tend to complain a lot about the iOS client, apparently it stacks up really unfavorably to WhatsApp and Signal.

      1. 4

        The iOS client is probably the oldest one. At least the android client was rewritten at one point and currently there’s an iOS rewrite ongoing.