1. 32

I’ve been using Matrix/Riot heavily for the last two weeks.

Short Version

Much like I run FreeBSD on my desktop, I am a happy user of Matrix/Riot on mobile (Android) and the web app, despite its flaws, because I support the idea more than the implementation. All-in-all, I don’t find the service has any deal breakers in it for me and I find it to be a worthy competitor to Slack. But it is still too rough for mass migration and I don’t think people who don’t share the ideology or have someone else acting as a forcing function will willingly move there. I’ve moved most of my communication to it and am off slack entirely.

The Good
  • Open standard!
  • End-to-end encryption.
  • Mobile and web clients that work mostly fine (see The Bad).
  • Experience is pretty similar to Slack and IRC, so people will feel comfortable moving over there.
  • Federated, so I can play around in my local sandbox or build competing software and still interact with the main system.
  • While it’s a web API, it feels like a spiritual successor to IRC. I know IRCv3 exists but I think it probably has too much baggage for adoption like Matrix does.
The Bad
  • The UI is pretty rough. There are nitpicks like lots of wasted space on the web app, to the padlock shows on every message for encrypted chat, I’d really just like to see when messages are unencrypted.
  • E2E Encryption works flawlessly on mobile but the web app still has some bugs in it where it, sometimes, cannot decrypt what someone says. What works for me is if my mobile app has verified the keys it will decrypt them for my web app and I can see them in the web but they show up as unverified.
  • You have to verify keys for each new device you have encrypted chat with. I know this is technically correct but 99% of the time I simply cannot do anything with this information and will hit Verify. It would be nice if the default was less intrusive but still let power users do what they want.
  • The web app has a bug where if I’m using it heavily it will lock the tab up and I have to kill the tab and start again. It’s just annoying.
  • Like any open source project, don’t expect your pet bug to be fixed anytime soon unless you do it yourself.
  • The matrix.org server is slow. Nothing has every failed for me but latency is noticable. The upside is being federated offers room for people to compete on server implementations if they so desire.
  1.  

  2. 4

    I have been using Matrix/Riot for a few months now and had about the same experience (I never used E2E though). I know that Riot still has some pain points that are quite annoying, but I love the idea behind the project and would really like to see it become more popular in the future.

    FYI, they are currently working on device key cross-signing so that you don’t have to verify every single device.

    1. 2

      I have been using Matrix for over a year now. A quick summery I’d make is it technically has just about anything you want but it often doesn’t feel polished and works pretty slow (I’m told it’s fast if you host your own server and don’t join mega groups)

      It’s coming there and I really think matrix is the future of open communication protocols. It’s totally usable now but it’s not as nice as the locked down alternatives.

      1. 2

        I don’t know how far I’ll get but I’m interested in making a competing server in my spare time. Hopefully I can find a way to load test it to see how well it does. I have a feeling the existing implementation is what it probably should be: a prototype that’s been jammed into production (I haven’t looked at the code or ran it, but it’s clearly not keeping up).

        1. 1

          I really hope the French initiative using these will help the solution flourish. It seems the be a really promising solution that needs a bit more time to evolve and prove that it can be viable.

          1. 1

            I have a feeling the existing implementation is what it probably should be: a prototype that’s been jammed into production

            Pretty much. They have been rewriting the whole thing for a little while but it’s not done yet.

        2. 1

          My impressions are as follows.

          The interface is bad, the email notifications are useless and don’t distinguish between ‘hey, someone sent you a direct message/mentioned you on a channel’ and ‘here is a dump of messages from last week’.

          Handling e2e encryption keys and device verification is terrible, including tying the device key to the browser user agent - I had to re-authenticate my browser after Chrome UA changed on OpenBSD.

          There are some messages that nothing except my phone can decrypt, and ‘requesting’ keys doesn’t help with it at all.

          The interface and service feels sluggish.

          e2e encryption is not enabled by default.

          I love the idea of matrix & the riot client - it lacks a lot of polish at this point in time. It’s annoying enough that I do not use it daily, I take a look at the openbsd riot channel every few weeks - that’s all.

          1. 1

            e2e encryption is not enabled by default.

            I agree with a lot of what you said (although I disagree with the degree which it is a problem). For this one, I’m not sure is a negative. E2E encryption still is in beta, so turning that on by default would probably produce the opposite complaint from a lot of people, possibly even you given your earlier statements on its quality. It also cannot be undone, so making public channels would be annoying. I also don’t really think public channels probably need e2e given anyone can join them. Maybe direct chats should be e2e by default once it’s ready, I’m not sure. But I do believe there is a valid argument for e2e encryption being off by default.

            1. 1

              For group channels - sure. I do believe however that direct messages e2e should be on by default. Especially if they consider e2e encryption still a beta - this needs huge usage exposure before people start relying on it in the real world for serious stuff.

              1. 1

                I find your statement kind of confusing. You are suggesting we opt people into e2e encryption by default but at the same time it’s not ready for serious stuff. IMO, letting people opt themselves in and slowly work out bugs and eventually transition people into it by default sounds like a more pleasant user experience than dropping everyone into a buggy solution. I can see merits to your suggestion, but my values prefers a slower solution.

                1. 2

                  IMO, letting people opt themselves in and slowly work out bugs and eventually transition people into it by default sounds like a more pleasant user experience than dropping everyone into a buggy solution.

                  I think it will lead to it remaining non-default forever and people sending messages without turning on e2e encryption on. Defaults matter.

                  I also believe it’s better to expose as many users as possible to the e2e feature now - people using matrix today are most likely technical already. It’s harder to change defaults when things go mainstream.

                  1. 1

                    I think it will lead to it remaining non-default forever and people sending messages without turning on e2e encryption on

                    Maybe! It’s hard to tell the future. At least anyone who is sufficiently motivated can write a client which does default to e2e encryption or can make a PR to Riot that defaults to it, etc etc (it’s a client decision not a server decision). I feel like you’re being overly pessimistic, but we’ll find out!

                  2. 2

                    IMO, letting people opt themselves in and slowly work out bugs and eventually transition people

                    They need to just fix the bugs so we don’t have to slowly opt people in. Most of the private or FOSS alternatives to proprietary software fail due to user experience. Those developing them should’ve learned by now. I’d hold off on new features where possible to just fix everything people have reported. Then, do iterations as follows: build some stuff with good diagnostics or logging built-in; fix the bugs people report; build some more stuff; fix some more stuff; maybe trim anything that turned out unnecessary. Just rinse repeat maintaining good user experience with core functionality that works well. If there’s bugs, they should be in rarely-used features.

                    1. 4

                      They need to just fix the bugs so we don’t have to slowly opt people in.

                      This statement is ridiculous. It’s an open source project with limited resources. Yes, it would be nice if they could just fix the bugs. Wouldn’t life be great in every project if that could just happen.

                      Those developing them should’ve learned by now.

                      It’s new people developing every project, it’s not Ocean’s 11 where the same crew gets together on every project. Those who can program are growing at an insane rate, most of them are green.

                      Then, do iterations as follows: …

                      Feel free to run an open source project like this. But this isn’t a company with top-down management, it’s a bunch of actors in the world doing whatever they are doing and things happen. There is no-one in control.

                      1. 2

                        This statement is ridiculous. It’s an open source project with limited resources. Yes, it would be nice if they could just fix the bugs. Wouldn’t life be great in every project if that could just happen.

                        There’s open source projects that fix their bugs. There’s others that ignore the bugs to work on other parts of the project like new features. So, it’s not ridiculous: it’s a course of action proven by other projects that focus on quality and polishing what they have. Many projects and products do ignore that approach, though, for endless addition of features.

                        Now, it might be acceptable to ignore bugs if users love the core functionality enough to work around them. Maybe the new features would be justified. Happens with a lot of software. However, bugs in basic use of a chat client that is not in wide demand which its competitors don’t have are going to be a deal-breaker for a wide audience. It’s already a hard, uphill sell to get people to use private, encrypted clients like Signal that work. People mostly cite network effects of existing ecosystems but also things like visuals and breakage of some features. Really petty given the benefits and developers available but gotta play to the market’s perception. Leaving the alternatives broken in whatever ways you were noticing just makes that hard sell worse both for that project and any others that get mentally associated with that experience down the line. As in, people stop wanting to try encrypted, chat programs when the last two or three were buggy as hell or had poor UI. It can even hurt credibility of people recommending them.

                        “Feel free to run an open source project like this.”

                        There’s groups that do. They have less contributors but higher quality. Another alternative is one person who does care spending extra time on fixing bugs or QA-checking contributions. I’m usually that guy at my job doing a mix of the stuff people overlook and the normal stuff. There’s people doing it in FOSS projects. This one clearly needs at least one person doing that. Maybe one more person if a person or some people are already doing it but overloaded.

                        When it comes down to it, though, I said the group wanting a lot of people to switch to their chat client should fix the problems in it. Your counter implies they shouldn’t fix the problems in it. I’m assuming you meant they should keep doing more features or whatever they’re doing while ignoring the problems. I think for chat clients that fixing problems that would reduce or block adoption should one of highest priorities. Even a layperson would tell you they want their new tech to work about as well on main functions as their old ones its replacing. The old ones work really well. So, the new one needs to. That simple to them.

                        1. 1

                          There’s open source projects that fix their bugs.

                          Your counter implies they shouldn’t fix the problems in it.

                          Ok I think we are talking about different things then because that is not what I meant at all. I’m not saying they don’t fix their bugs, I’m saying they are slowly working a new feature out. Maybe it’s a language barrier but that is what I meant here:

                          and slowly work out bugs and eventually transition

                          I think it’s better to give people a new feature they can opt into than force them into something broken.

                          1. 2

                            Maybe a misunderstanding. Your original writeup suggested they had bugs in quite a few things, invluding E2E messaging. E2E should be on by default due to its importance. So, Im just saying that fixing esp E2E messaging bugs should be high priority since it’s important and should stay on by default. Plus anything else causing problems in daily use.

                            1. 1

                              But that depends on what problem you think Matrix is solving. Currently it’s replacing Slack and IRC, both of which mostly focus on public rooms that anyone can join. E2E encryption doesn’t do much for you in those places. For direct messages, yeah it probably should be on by default. For the private rooms I’m in, we turned it on.

                              So if one thinks Matrix is the next step in IRC or replacing Slack, then E2E encryption isn’t a high priority for you.

                              So, Im just saying that fixing esp E2E messaging bugs should be high priority since it’s important and should stay on by default. Plus anything else causing problems in daily use.

                              It’s easy to dictate project priorities from an arm chair.

                              1. 1

                                Currently it’s replacing Slack and IRC, both of which mostly focus on public rooms that anyone can join. E2E encryption doesn’t do much for you in those places.

                                That makes more sense. I assumed it had a privacy focus since someone mentions it in every thread on stuff like Signal and given homepage line. If just a Slack replacement, E2E wouldn’t make sense by default.

                                “It’s easy to dictate project priorities from an arm chair.”

                                It really isn’t. There’s always lots of debate that follows that consumes time and energy. ;)

                      2. 3

                        Totally agree! Leaving bugs in the code is just stupid. You’d think they should’ve learnt that by now.