Posted by LorenDB 2 hours ago
I dealt with ~monthly issues around my devices not being correctly verified, messages not correctly decrypting, and various other rough UX edges. There seemed to be a lot of velocity in the beginning but the last couple of years have addressed approximately nothing in terms of the UX and it's a crying shame as Matrix/Element (I no longer fully understand the difference/relationship between these entities) had a lot of potential.
This sucks to hear. I thought they had made massive improvements in the last year or so (I don't know because I feel too burnt by past experience).
When attempting to verify iOS, Desktop linux didn’t work. When attempting to verify Desktop Linux, Desktop Windows didn’t work. When verifying Android, iOS didn’t work. Every verified official client for every platform was verified, tried a different verification method than expected, and failed.
All of this to say, this isn’t the first time this has happened to myself and others. Forcing verification is otherwise known as unexpected “offboarding”. If some verification methods have problems, publish a blog about their deprecation instead.
I love element, but this can’t be done without prior work to address.
Meanwhile, an app like Signal can do none of that, and that's by design.
If you're looking for a privacy oriented messaging system, you'd best look elsewhere.
I'm new to Matrix and found this comment on reddit. How much of it is accurate and does it actually contribute to whether or not the future of the protocol is promising?
Matrix seems to have a lot of these structural flaws. Even the encryption praised in the Reddit post has had problems for years where messages don't decrypt. These issues are patched slowly over time, but you shouldn't need to show me a graph demonstrating how you have slowly decreased the decryption issues. There shouldn't be any to begin with! If there are, the protocol is fundamentally broken.
However, work is ongoing to improve the situation; more importantly, Matrix is a different threat model (in my opinion), and allows for different trade-offs.
When I use Signal, I have to trust Signal's servers and their admin team. With Matrix, we get to keep trust circles smaller (friends and family on smaller servers, where we already trust the people running them). We have no hard requirement to federate either - if I want something just for people I know, we leak less data than Signal does to the outside world. We also get to host Matrix servers in areas we're comfortable with, whether that's our living room, or any nation that isn't America.
Matrix isn't perfect, but I appreciate how quickly they're improving, and the areas they're focusing on.
> After Alice logs in on a new device, she uses her cryptographic identity to demonstrate to Bob that the new device genuinely belongs to her, rather than being added by someone else with access to her account. She can do this either by entering her recovery key (which gives the new device immediate access to her cryptographic identity ), or by carrying out an interactive verification from an existing verified device.
The numerical Signal PINs are basically just for when you bootstrap your Signal identity from a telephone number.
I have had all variations of clients ignoring requests, reporting requests only for the requesting client to ignore the response. Both ends quitting declaring that the other end cancelled, asking for the other end to input a code while the other end shows no interface for doing so.
It marked the end of me using Matrix as a platform. I'd go back to the old IRC channels if there were anyone still there.
It involves doing one of these things:
- Comparing a short sequence of emoji on each device and confirming that they match.
- Using one device to scan a QR code displayed by the other.
- Entering a recovery key (a line of text) that you were given when you first set up the account.
Pretty quick and easy in most cases, although some clients can be glitchy in this area and require trying again.
(Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
There has never been a better time to (re)embrace XMPP as your decentralized chat option. The clients are less buggy, handle missing features gracefully, & best part is, not being built on an eventual consistency model, you don’t have the constant syncing issue with delayed messages. If you wanted you could make an XMPP client in a day since the base spec is small/simple—& features like device verification would be seen as mandatory in the base specification.
The code examples I'm aware of for clients using the first-party library also leave verification and E2EE out, FWIW.
If this is that case what will happen is that people will start verifying everyone (because they might want to text to strangers that they can't bother verifying because the stakes are so low) and so verification will lose all meaning.
SSH is an example of TOFU.
A domain can layer on HSTS to that, which directs clients to additionally refuse to trust a new cert for a domain until the one you currently trust has expired.