Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Matrix v1.15

matrix.org

Post reply on HN
Print view View original

111–120 of 131 posts

Re: Matrix v1.15

#111

Post by lrvick »

Teever wrote: post #98
lrvick wrote: post #65

Earlier quoted context omitted.

Have you considered that multiple of your complaints could be addressed by protocol improvements?

I can't tell if this comment was written in jest or not. It's always protocol improvements and 'it's coming in the next version's or 'msc #xxxx just got approved' with Matrix. It's always someone saying 'oh this next version fixed all that' and then someone says 'well what about mobile' or 'what about desktop's and then someone says 'actually it doesn't fix it there.' I'd love matrix to be the solution to my communic…

It is a solution for plenty of people and I am one of them. Your standards must simply prioritize UX over federation and E2EE.

Re: Matrix v1.15

#112

Post by mindslight »

BrenBarn wrote: post #54
Arathorn wrote: post #29

Earlier quoted context omitted.

One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X: https://element.io/blog/we-have-lift-off-element-x-call-and-... etc. Element X kicks ass, in my (very biased) opinion: it's a super-speedy Rust core with fancy SwiftUI and Compose native UI layered on top. It radically outperforms any other encrypted messenger i've used in terms of UI perf…

> One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X: https://element.io/blog/we-have-lift-off-element-x-call-and- ... etc. Okay, but they do that because they used those apps, and they did that because you released those apps and said the same thing you're saying now ("use our app, it's really cool"). Surely you can understand why someone w…

I think an early major mistake was that Matrix spent all this time and energy designing a general synchronization protocol, but not doing it in terms of native encryption and cryptographic identities. This was post-Snowden, and it was glaring at the time.

Bolting on encryption after the fact then sucked so much energy out of the ecosystem for clients. This one doesn't implement encryption, that one does but it has bugs/warts/etc, this other one does if you pull this year-old experimental branch and build it yourself. The web (-technologies) client became the de facto one because it "worked", despite being bloated and laggy - reliable tools don't even have the code to show these spinning delay circles that have become synonymous with the web ecosystem.

I don't want to be entirely negative because I do see it as the least-worst messaging option available. I use it for communicating with a bunch of friends and things do seem to be getting better, and I look forward to when I can actually switch to its window to type a message and not wait around for redraw / garbage collection / reloading messages from server /etc. That might be on me for not having surveyed native clients recently or tried Element X on my desktop, but that's exactly the negative momentum I'm lamenting above.

Re: Matrix v1.15

#113

Post by db579 »

Arathorn wrote: post #95
db579 wrote: post #69

Earlier quoted context omitted.

It's a little frustrating that Element X is constantly pitched as the answer when it isn't yet supported by Element's own EMS One hosted service.

Element One should support MAS + EX in the next 2-3 weeks. Mozilla's EMS hosting got migrated over yesterday (at last) 60% of the rest of EMS-hosted servers are also migrated already. Sorry it didn't happen earlier, but all our focus has been on getting on-premise deployments for people like NATO & the UN working excellently, and the SaaS deployments have been lagging.

Appreciate the response, that's great to hear.

Re: Matrix v1.15

#114

Post by justaj »

Arathorn wrote: post #78
justaj wrote: post #60

Earlier quoted context omitted.

> Matrix isn’t perfect but it has only improved in the 5 years I’ve been using it. I'd very much like to disagree. From the top of my head, in the past few years of using Element Web: - Notification center is now gone. - Room search is now only limited to official Matrix rooms. - At peak it consumes ~2.2 GB of RAM. - UI feels more sluggish by the day. - Loading it now takes ~10 minutes. - Using it as an IRC bouncer (…

> - Notification center is now gone. It's still there; it just got moved into Labs given it never worked in encrypted rooms, and having a flakey feature for new users was (correctly) considered worse than not having a feature at all. Go look for "Enable the notifications panel in the room header (Unreliable in encrypted rooms)" in Labs on develop.element.io or Element Nightly. > - Room search is now only limited to o…

Thank you for your extensive reply.

> a flakey feature for new users was (correctly) considered worse than not having a feature at all.

Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place.

> On one server (matrix.org) the room directory is currently locked down to stop it filling up with spam

Yes, that's what I was initially talking about since I'm (mostly) on the matrix.org homeserver. I'm glad this is a temporary situation.

> However, good news is that we've finally moved to Element X Web (codenamed as Aurora: https://github.com/element-hq/aurora),

Oh I wasn't aware of this. This is excellent news! I hope it gets lots of attention in the (near) future. I'm guessing that the enshittification of Discord is about 2 to 3 years away at this point, so I believe having a proper alternative would do wonders for the open ecosystem.

> To improve the UX with clients, we had to improve the protocol.

While I believe this to be the best way forward, was it also the fastest way to acquire a userbase? If we look at Bluesky for instance, they pretty much did the reverse of what Matrix.org did, and (I think) thus was in a position to garner hefty growth as a result.

Re: Matrix v1.15

#115

Post by BrenBarn »

mindslight wrote: post #112
BrenBarn wrote: post #54

Earlier quoted context omitted.

> One of the big problems is that folks judge Matrix based on the legacy Element apps, which have now been succeeded by Element X: https://element.io/blog/we-have-lift-off-element-x-call-and- ... etc. Okay, but they do that because they used those apps, and they did that because you released those apps and said the same thing you're saying now ("use our app, it's really cool"). Surely you can understand why someone w…

I think an early major mistake was that Matrix spent all this time and energy designing a general synchronization protocol, but not doing it in terms of native encryption and cryptographic identities. This was post-Snowden, and it was glaring at the time. Bolting on encryption after the fact then sucked so much energy out of the ecosystem for clients. This one doesn't implement encryption, that one does but it has bu…

That's true, but in another sense I think it's just that trying to "do it all" encryption-wise is significantly harder than some people realize. Having encryption that's really "safe" raises barriers to casual use that most casual users aren't really willing to accept.

Like suppose I use Matrix only on my phone, so I just have the one device. Then I lose my phone and have to get a new one. How do I regain access to my account, including all of my old messages? Or suppose I (still using Matrix only on my phone) decide I need to log out because I want to let someone else (a friend, my kid) use my phone for a while and don't want them snooping in my messages. How do I retain access to all the messages I receive while logged out?

I'm not saying these are problems with Matrix; they would be problems with any service that attempts to cover the same bases (in particular, e2ee with forward secrecy and multiple independent devices). The average user's conception of a messaging service is "I can log in with my password and then have total access to all of my messages, past, present and future." There are too many ways to break that assumption if you try to have perfect forward secrecy and all these other desiderata that encryption wonks care about but normal people don't. I think this is one reason there's still a big gap between comments on HN saying "matrix still works fine for me" and the tales of "I tried to get my grandma to use this and it was a disaster". I don't think it makes sense to try to roll Matrix out for general use, or say it's "the best messaging app" until it can smoothly handle all of those use cases.

Re: Matrix v1.15

#116

Post by tabbott »

lrvick wrote: post #66
v3ss0n wrote: post #50

Earlier quoted context omitted.

When compare to Zulip , Matrix usability is nothing close to that.

Zulip lacks end to end encryption and decentralization so they are not remotely comparable.

If you're doing consumer chat with friends and family, I'd recommend Signal over Matrix or Zulip.

For a community: A lot of communities want anyone in the public to be able to join their spaces and read their channels. For that use case, E2EE makes the chat system slower and less usable, with limited security benefits over using web standard encryption.

What E2EE may protect you from is a malicious server operator reading the organization's messages. If the server operator is a leader in the organization already, that person may already be directly a recipient of all the interesting messages anyway. The practical benefit I see for E2EE in Zulip is mainly for Zulip Cloud or other settings where a third party is hosting the Zulip server for you.

As for decentralization, a self-hosted Zulip server only talks to external infrastructure for sending notifications (Emails, mobile push) and to implement user-controlled features (E.g., outgoing webhooks). The Zulip API is fully documented, easy to understand and implement, and has community-developed clients.

Maybe you're thinking of federation? Matrix has fancier mirroring functionality, which can be important if your use case requires sharing dozens of channels with dozens of other servers. But Zulip is supported by Matterbridge and has various nicer mirroring integrations for sharing a channel with another server on various protocols.

But I don't know of many use cases where the usability of the core chat system isn't far more important than the usability of federation features.

Re: Matrix v1.15

#117

Post by Arathorn »

justaj wrote: post #114
Arathorn wrote: post #78

Earlier quoted context omitted.

> - Notification center is now gone. It's still there; it just got moved into Labs given it never worked in encrypted rooms, and having a flakey feature for new users was (correctly) considered worse than not having a feature at all. Go look for "Enable the notifications panel in the room header (Unreliable in encrypted rooms)" in Labs on develop.element.io or Element Nightly. > - Room search is now only limited to o…

Thank you for your extensive reply. > a flakey feature for new users was (correctly) considered worse than not having a feature at all. Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place. > On o…

> Would you say that implementing a flakey feature in the first place was a bad idea? I'd think that once users get dependant on a certain feature (no matter how lacking in its usefulness), it's going to be tougher for them taking it away than not shipping it in the first place.

I actually wrote the notification panel in the first place: https://github.com/element-hq/element-web/pull/2113 and when we shipped it, it worked fine. However, this was 2016, before Matrix had E2EE (which eventually got turned on by default in 2020), and E2EE complicates notifications enormously, given the server can't read the messages in order to figure out whether they're a notification or not. So, instead, the client has to calculate notifications instead, which (worst case) means it has to spider every message in every E2EE room to figure out whether to notify based on keywords, mentions, event type, etc.

So, rather than hooking up all that logic in Element Web, we left NotifPanel as is, working fine for unencrypted rooms (and working best-effort for encrypted ones, iirc), instead focusing on fixing Matrix's famous decentralised E2EE stability (Unable To Decrypt errors), which literally took years. Then, rather than implementing proper notification logic in duplicate across both js-sdk (Element Web) and rust-sdk (Element X), we focused on nailing it in rust-sdk - and meanwhile hid the feature on Element Web until we can swing Element Web over to use rust-sdk (Aurora).

So to answer your question: we didn't ship a flakey feature in the first place. But hiding it once it got flakey rather than even further slowing down our progress on stabilising E2EE (given we don't have manpower to adequately to maintain two stacks) definitely feels defensible.

A more interesting question is whether we've done the right thing by rewriting all the platforms to use a shared Rust core. However, we're not alone in doing that sort of transition: https://github.com/signalapp/libsignal etc.

> > To improve the UX with clients, we had to improve the protocol. > > While I believe this to be the best way forward, was it also the fastest way to acquire a userbase? If we look at Bluesky for instance, they pretty much did the reverse of what Matrix.org did, and (I think) thus was in a position to garner hefty growth as a result.

We know the Bluesky team quite well, and I strongly suspect they learnt from Matrix's misadventures (just as we in turn learnt from XMPP's). My FOSDEM talk this year was literally about this: https://youtu.be/lkCKhP1jxdk?t=490. Empirically Matrix is good at ecosystem uptake (better than Bluesky) but worse at mainstream. It's never too late to change though.

Re: Matrix v1.15

#118

Post by em-bee »

em-bee wrote: post #18
Arathorn wrote: post #8

Earlier quoted context omitted.

What would you say the delta is between Element's current video-rooms and Discord-style voice-rooms (if you go and mute video for everyone), ooi? The only reason Element hasn't implemented precisely the same UI as Discord is because it's not (currently) trying to be a Discord competitor, but more a "run your own encrypted Teams alternative", given that's what Element customers are asking for right now, and we're havi…

the discord style permissions are simply easier to understand. it's classic role based. you define the roles, and assign the roles to users. matrix permissions forces a hierarchy that is awkward and more difficult to apply because i have to force permissions into a hierarchy. on discord i don't have to think about the hierarchy.

this comment was proofread by the department of redundancy department.

Re: Matrix v1.15

#119

Post by mindslight »

BrenBarn wrote: post #115
mindslight wrote: post #112

Earlier quoted context omitted.

I think an early major mistake was that Matrix spent all this time and energy designing a general synchronization protocol, but not doing it in terms of native encryption and cryptographic identities. This was post-Snowden, and it was glaring at the time. Bolting on encryption after the fact then sucked so much energy out of the ecosystem for clients. This one doesn't implement encryption, that one does but it has bu…

That's true, but in another sense I think it's just that trying to "do it all" encryption-wise is significantly harder than some people realize. Having encryption that's really "safe" raises barriers to casual use that most casual users aren't really willing to accept. Like suppose I use Matrix only on my phone, so I just have the one device. Then I lose my phone and have to get a new one. How do I regain access to m…

I'd say that all of those usability problems are made worse by bolting on encryption after the fact. It makes it so there are now two layers of authentication/identity, rather than a single one. Whereas with built in encryption, you can always punt on solving the problems you list and make implementations that are less secure. For example, just store the keys on the server, accessed by the password. That's obviously less secure, but not less secure than no encryption.
Post reply on HN