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

91–100 of 131 posts

Re: Matrix v1.15

#91

Post by lrvick »

msgodel wrote: post #88
lrvick wrote: post #87

Earlier quoted context omitted.

My minimum requirements for personal online communication outside of public web-accessible forums like this one, are open protocol, open source implementations, optional E2EE, independent hosting, client choice, and access to channels on other independently hosted servers. These are non negotiable for building my social graph of communication with family, friends, colleagues, etc. Communication is a sacred part of th…

If you give up on E2EE (which isn't useful on smartphones anyway since the users have so little control over the OS and app distribution) email works, nearly everyone has that. If you use eg jmp.chat you can use email, other people can talk to you over SMS, and you can just pretend all this retarded crap doesn't exist.

In the decade prior to me abandoning cell phones entirely I used E2EE email frequently on Android via OpenKeychain and K-9Mail with a Yubikey.

I did not want to be locked into Google or Apple ecosystems and the ship on a truly FOSS Android device has long sailed, so I ported my number to a VoIP provider and only use PCs now.

To your point -any- E2EE on proprietary platforms like iOS or Android cannot be trusted for high risk comms, so at my infosec job we exclusively use Matrix from QubesOS workstations.

But yes email is normally the go-to fallback except with Gen Z who almost universally refuse to use it having grown up exclusively using corpotech.

Re: Matrix v1.15

#92

Post by Arathorn »

exyi wrote: post #62
lousken wrote: post #11

custom emojis still didn't make the cut?

The protocol must support it somehow already, as some bridges can send custom emojis from other platforms

https://github.com/matrix-org/matrix-spec-proposals/pull/254... is the de-facto way that custom emoji are done today, but as you can see from the labyrinthine Matrix Spec Change, it still needs some work to get stabilised and formally merged into the spec. Meanwhile, folks are always welcome to use experimental MSCs in the wild.

Re: Matrix v1.15

#93

Post by lrvick »

zx8080 wrote: post #68
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 (…

> Loading it now takes ~10 minutes. What?! How is this possible? How come users tolerate it at all?

I am a power user and have never experienced this. Their system must be disk bound or ram bound or something.

Granted I have 0 systems I use with less than 64gb of memory. Ram is cheap.

Re: Matrix v1.15

#94

Post by Arathorn »

DavideNL wrote: post #74
foresto wrote: post #59

Earlier quoted context omitted.

I don't use that functionality, but I'm pretty sure it exists: https://spec.matrix.org/latest/identity-service-api/ https://github.com/matrix-org/sydent

Yea that's correct, it seems to exist; However apparently the default server, matrix.org , does not support it... (which everyone uses who follows the default App setup flow.)

We disabled it on matrix.org because it was being used for 2FA SMS fraud, costing us $$$K, and we didn't want to burn time building an anti-fraud system. Getting access to everyone's phonebooks is also a privacy risk (even if you do fancy stuff with SGX like Signal does).

Meanwhile, government deployments typically have LDAP or similar to discover users - and so it hasn't come up as a big requirement for the folks generating $. It's on the radar though as one of the main blockers for mainstream uptake... but right now we're trying to keep the lights on first before focusing on accelerating mainstream uptake.

Re: Matrix v1.15

#95

Post by Arathorn »

db579 wrote: post #69
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…

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.

Re: Matrix v1.15

#96

Post by btdmaster »

Arathorn wrote: post #86
btdmaster wrote: post #70

Does anyone know if homeservers still control room membership + user key lists or if it's somehow properly signed now? I couldn't find anything on https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en...

Room membership is still determined by the server rather than the client - but we now warn the user and freeze the room if devices which are not signed by their owner are present in the room. Constraining the user membership to be controlled by the client is Hard in a fully decentralised world, but we're working on it: one option is MSC4256 (which pushes the whole problem to MLS); another option is to run Matrix's st…

Thanks a lot for chiming in! That's nice to hear it's better and improving.

View from 1000 feet: maybe a way to lock a room's users would be interesting? So that new users in, say, a DM room do not get decryption keys for messages from the client. Something like a weaker form of "only send messages to verified users", where you could have a DM room with (at most) 2 people.

Or, instead, maybe an option to disable forwarding session keys older than the user's room join event, to keep forward secrecy so that a new user does not get to read old messages (or does this already happen every 100 messages?).

Re: Matrix v1.15

#97

Post by DavideNL »

Arathorn wrote: post #94
DavideNL wrote: post #74

Earlier quoted context omitted.

Yea that's correct, it seems to exist; However apparently the default server, matrix.org , does not support it... (which everyone uses who follows the default App setup flow.)

We disabled it on matrix.org because it was being used for 2FA SMS fraud, costing us $$$K, and we didn't want to burn time building an anti-fraud system. Getting access to everyone's phonebooks is also a privacy risk (even if you do fancy stuff with SGX like Signal does). Meanwhile, government deployments typically have LDAP or similar to discover users - and so it hasn't come up as a big requirement for the folks ge…

Good to hear the insight, thank you.

That makes sense, hopefully it’s something that can be resolved sometime soon. Would be great if mainstream people have another, privacy conscious, alternative to big tech…

Re: Matrix v1.15

#98

Post by Teever »

lrvick wrote: post #65
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 (…

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 communication problems but it just isn't.

Re: Matrix v1.15

#99

Post by graynk »

DavideNL wrote: post #51

It baffles me that when you install the Element App (which uses matrix.org by default), you can not easily find any of your friends, because you cant “connect” your phone number… This makes the App a no-go for everyone and their grandmother. The registration and setup process was so cumbersome, even people with some tech knowledge in my friend circle had trouble getting it to work. Anyway, it seems so user hostile, w…

I genuinely can not understand if this is satire or not. Attaching everything to a phone number is the worst thing that happened to messaging.

Re: Matrix v1.15

#100

Post by Arathorn »

btdmaster wrote: post #96
Arathorn wrote: post #86

Earlier quoted context omitted.

Room membership is still determined by the server rather than the client - but we now warn the user and freeze the room if devices which are not signed by their owner are present in the room. Constraining the user membership to be controlled by the client is Hard in a fully decentralised world, but we're working on it: one option is MSC4256 (which pushes the whole problem to MLS); another option is to run Matrix's st…

Thanks a lot for chiming in! That's nice to hear it's better and improving. View from 1000 feet: maybe a way to lock a room's users would be interesting? So that new users in, say, a DM room do not get decryption keys for messages from the client. Something like a weaker form of "only send messages to verified users", where you could have a DM room with (at most) 2 people. Or, instead, maybe an option to disable forw…

> View from 1000 feet: maybe a way to lock a room's users would be interesting?

That's a really interesting idea - having immutable memberships could be a good band-aid. The problem is that right now the fact that room membership is typically mutable can be valuable: you add assistants into DMs (human or virtual); you can bridge the DM to other platforms; you can add (benign) audit bots for compliance purposes; you can migrate between Matrix IDs by inviting in your new ID and kicking out the old one; etc.

Of course, this same flexibility comes with a risk, and I see the point that it might be better to 'seal' membership if you know this is flexibility you don't want. We'll have a think.

> Or, instead, maybe an option to disable forwarding session keys older than the user's room join event, to keep forward secrecy so that a new user does not get to read old messages (or does this already happen every 100 messages?).

Currently we never forward session keys, so new users don't get to read old messages whatever. This obviously causes its own problems, especially for Slack/Teams style use cases where new joiners expect to be able to read conversation history. Work is ongoing right now to finally fix this (https://github.com/element-hq/element-meta/issues/39), but we are very mindful of the risk of not sharing existing history to the wrong users (or devices), which is one of the reasons it's taken so long to land.

The 100-message thing is separate: it's the maximum number of times a session-key ratchet can be advanced before it gets replaced. In other words, if you steal a session key, you can only use it to decrypt a maximum of the 100 subsequent messages sent by that device.

Post reply on HN