Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Matrix 2.0 is a major step towards getting friends & family on Matrix.

Firstly, it's not introducing new features - it's just making the current featureset work super-efficiently (while retaining compatibility with today's Matrix). So there should be no fragmentation between Element/Fluffychat/Thunderbird, with the possible exception of the new scalable encrypted VoIP conferencing (but then very few Matrix clients implemented the old VoIP conferencing, plus you can always just embed an Element Call instance to get at it now - as Element X does today).

Secondly, we're explicitly working to protect Matrix from the commercial interests from Element (the company set up by the team who created Matrix, of which I'm ceo/cto as well as Matrix project lead). We already have The Matrix.org Foundation (https://matrix.org/foundation) as an independent non-profit to hold the Matrix IP and maintain its neutrality - but we also just hired Josh Simmons (former President of the OSI) as its independent Managing Director (https://matrix.org/blog/2023/09/introducing-josh-simmons-man...).

So: going forwards, the Foundation increasingly does not have to depend on Element not being evil, but instead has its own independent management to ensure the protocol exists to support everyone in the ecosystem, without fragmentation, as per the guiding principles at https://matrix.org/foundation - under its own autonomy.

I'd say this is is good news for libre software privacy & security type people, but then again I'm biased. Practically, the only thing getting in the way of getting friends & family on Matrix is that Element X requires fancy OIDC-native homeservers for registration, so newbies won't be able to use Element X to join Matrix yet. But the app itself should be an excellent way to get folks on board in the very near future.



element still has serious usability issues that need to be fixed before i can get friends or family on board.

the way threads are displayed in the browser versions makes them hard to follow. in our hackerspace, where many are tech minded people, i see regular complaints about that.

scrollback to unread messages often fails. i have never had another chat application where that was a problem. this should just work.

the handling of encryption keys is very confusing. there are to many moving parts, it's not clear what i must save so that i can restore the keys in a new client.

private rooms are also confusing. i want to have a private room be the name of my chat partner, and they want it to carry my name. being able to do that would be very helpful.

i am also missing the ability to use a different nickname in every room. different groups know me under different nicknames. discord and wechat can do it. it would be great if matrix/element could do that too.


Sounds like you’re talking about Element Web or Desktop here. On Mobile, we just rewrote the app as Element X and it addresses almost all your concerns (other than per-room nicks, although ironically Element Web does have that today - try the /roomname command).

Having got Element X out the door, my attention at least is going to swing back to Element Web. In terms of encryption disasters, we are about to switch Element Web’s crypto to the same rust implementation as Element X, hopefully next week - you can track the progress at https://github.com/vector-im/element-web/issues/21972#issuec.... Hopefully this will make a much-needed massive improvement on encryption, while also speeding it up 5x or so. On Element X, encryption failures are almost unheard of (other than when talking to Element Web).


Element X is great except for the lack of history, once that's added it'll change to my daily driver. I very often search my chat history and reference things going back months


Encryption in Matrix is a nightmare. I set up Synapse and pulled half a dozen or so people onto it. We have a few chat rooms. Randomly different users clients are unable to decrypt the messages of other users clients. You click some button about syncing encryption keys, and nothing happens. Then randomly a week later you can start reading each others messages again. shrug This has been going on for years now.

This alone makes Matrix the worse chat platform out there from a users perspective IMO. I invested too much effort in getting things up and running and using it now though, so I'm just hoping that this gets fixed one day, or something better comes along that I can migrate to.


Sorry. As per the sibling comment to yours, we made a decision on Element Web/Desktop to rip out the old encryption implementation and replace it with matrix-rust-sdk’s crypto implementation about a year ago, and while it’s due to land next week, it means that some folks have had a miserable time in the interim.


I'm curious and extremely skeptical as to how the UX is going to be made better regarding the terrible UX surrounding encryption. I used Matrix with a non-technical family member for about six months before giving up and going back to SMS because she frequently got messages about encryption that she was in no way equipped to deal with, and did not even begin to understand (yes, the "user-friendly" key fingerprint screen is one of those pain points) and I had to handhold her through the process, every time she got a new device or similar.

One time I had to manually export and import my own keys to be able to read old messages, which was a task that would have been too technical for most of the people I'd like to chat with, and was supremely annoying for me.

It's just a non-starter. I have a community I've been considering moving to Matrix for literal _years_ now and there are just so many sharp edges.

I've been confused about Matrix's priorities for a long, long time. I am not getting any less confused, to be honest.


Well, just as folks might be skeptical about Matrix clients ever being as performant as WhatsApp/iMessage/Telegram, and yet we eventually got there with Element X... I'm expecting a similar outcome with E2EE UX.

The high level plan is:

* Fix all the bugs which cause random undecryptable messages, which was the main thing causing frustration. This is (hopefully) done now by converging on the new Rust implementation.

* Generate a recovery key, rather than confuse the user by asking them to pick two passwords (one for their account, one for their encryption). Impress on the user that if they ever want to recover their history, they'll need it. Expect that most users will lose it.

* When logging in on a new device, scan a QR code on an existing device to transfer over the keys (and thus history). Users are used to this now thanks to WhatsApp and Discord, and empirically they can do it fine. The recovery key is used only as a worst-case scenario if the user has no other devices. The act of logging in (either via scanning another device, or via recovery key) signs that device as owned by you.

* Only accept messages from devices that a given user has signed (i.e. trust on first use for users). If you want to verify that user out of band, they get an green tick too, purely to help you keep track of which users you're sure are legit and which users you've assumed are legit.

* At any given point, encryption is either enabled on your device (i.e. you've signed that device; it can access your encrypted message history; it can store keys for your encrypted message history) or it's not (and you can't do any E2EE). There are no halfway states.

This may sound simple and obvious when written out like this, but each point is a major change from the supremely confusing system we have today. The thing stopping us from having implemented it sooner is the huge amount of effort which went into reimplementing the engine in Rust. But having now (almost) finished that project, next thing up is fixing the UX, at last. The rough timeline is hopefully end-of-year, but, again, timings are contingent on funding pressure.


that sounds promising. looking forward to it.


so one hand says they are making things better for friends and family, and the other is ripping out things to make peoples lives miserable? and then letting them float in that misery for some period of time?


A lot of the problems were caused by the legacy crypto implementations. The misery is not caused by ripping them out and replacing them with matrix-rust-sdk crypto, but by it (unavoidably) taking a while.


Thank you for the comments. I'll keep my fingers crossed that this plays out well.

> plus you can always just embed an Element Call instance

That sounds like potentially a commercial embrace&extend&extinguish situation, which we need to avoid.


Yup, good call point, which is why we deliberately implemented two different independent group VoIP implementations - the one in Element Call (based on matrix-js-sdk) and the one in Hydrogen (based on hydrogen-web-sdk).

Admittedly the new livekit-based implementation takes us back down to a single implementation for now, but in its defense it’s only a few weeks old (with e2ee). Hopefully others will spin up independent implementations rapidly - although right now it does introduce a potential commercial EEE situation… but from on LiveKit rather than Element.

Eitherway, it’s something we’re painfully aware of… while also trying to ensure we find enough $ to pay for dev on Matrix (and Element) otherwise the whole thing collapses.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: