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

Matrix 2.0: The Future of Matrix

matrix.org

Post reply on HN
Print view View original

71–80 of 283 posts

Re: Matrix 2.0: The Future of Matrix

#71

Post by contact9879 »

tptacek wrote: post #49

Just a question, I haven't been paying attention, but where is Matrix on resolving the Nebuchadnezzar vulnerabilities, and is the project still tracking towards switching to MLS instead of Olm/Megolm?

> Outside of Matrix 2.0 work, other big items on the horizon include:

- Adding Rust matrix-sdk-crypto to matrix-js-sdk, at which point all the official Matrix.org client SDKs will (at last!) be using the same stable performant E2EE implementation

- Continuing to contribute Matrix input to the MIMI working group in IETF for > Digital Markets Act interoperability

- Working on MLS for next-generation E2EE

IIRC, the rust matrix-sdk-crypto was their intended fix for the vulnerabilities.

Re: Matrix 2.0: The Future of Matrix

#72

Post by amstan »

Arathorn wrote: post #33
amstan wrote: post #18

It's quite disappointing that there's huge ongoing work around reinventing clients from scratch where the basic functionality of not ringing all my devices while I'm using only one of them [1] is still not there (bug open for years), despite it being a pretty simple fix. [1] https://github.com/vector-im/element-meta/issues/360

The team rewriting Element as Element X is completely different to the folks who would need to make the change in Synapse to not send push to devices who are currently syncing. Agreed we should have fixed this years ago, especially as it's actually a feature in our pre-Matrix system back in 2012. There's basically a blindspot on long-lived missing serverside features like this; i've added it to a new hitlist we're ex…

I offered a simple fix: delay notifications on all except the active client for 30 seconds, if a read reciept gets triggered from the active client then cancel the timer. I couldn't even get anyone in the team to even look at my solution 3 years ago.

Not sure why this feature keeps getting defered for "just about to land and things might be better after" server-side features (see how it has 7 out of 9 "dependencies" resolved) when none are needed.

I've had a couple of friend actually give up on matrix due to this. I also have to keep my phone on silent or else I can't be chatting on matrix without the constant bzzzing.

I'm also amused about the ever growing (currently at $760) bounty on this feature.

Re: Matrix 2.0: The Future of Matrix

#73

Post by rovr138 »

the_gipsy wrote: post #42
UltimateEdge wrote: post #7

> Therefore to use Element X, you need to be running a homeserver with Sliding Sync support, which (for now) means running a sliding-sync proxy which bolts Sliding Sync support on to existing homeservers. I am excited to try out Element X, but I do not want to administer yet another service, namely the Sliding Sync proxy. From a practical perspective, Sliding Sync (MSC3575) is still on the level of a proposal/experim…

Well you can just wait. But the proxy is really lightweight and doesn't require maintenance.

Until there's an incompatibility, upgrade, exposure, memory overflow, or some other security issue/exploit. Unless you're saying that it's immune to everything and will never experience a change or issue.

Re: Matrix 2.0: The Future of Matrix

#74

Post by amstan »

xorcist wrote: post #64
amstan wrote: post #18

It's quite disappointing that there's huge ongoing work around reinventing clients from scratch where the basic functionality of not ringing all my devices while I'm using only one of them [1] is still not there (bug open for years), despite it being a pretty simple fix. [1] https://github.com/vector-im/element-meta/issues/360

Is it really that simple though? Jabber tried to be smart about which device to ring, and sometimes someone ended up with a missed notification. I always felt gutting that complexity and ring all instead would have been the more robust way.

So you consider your phone vibrating loudly on your desk for every recieved message while you're actively chatting and reading the same message on your desktop a correct implementation?

Re: Matrix 2.0: The Future of Matrix

#75

Post by Arathorn »

self_awareness wrote: post #19

How Matrix decentralisation is an improvement over Jabber's decentralisation? (disclaimer: I have no knowledge about neither spec, I'm not suggesting Jabber was better)

It's more that Matrix is different to Jabber/XMPP.

In Matrix, your chatrooms synchronise chat history between servers (rather than passing messages around), and that history is replicated equally over the participating servers, a bit like Git.

In XMPP, you pass messages between clients on different servers using a given server as a hub, and clients can choose to back up their message history on their local server.

Which architecture you prefer probably depends on whether you think instant messaging should be about passing messages or archiving chat history.

Re: Matrix 2.0: The Future of Matrix

#76

Post by thomastjeffery »

amatecha wrote: post #28
__s wrote: post #27

Earlier quoted context omitted.

What's the problem with e2e encryption for those organizations? The problem is if they give those orgs a backdoor

Oh yeah, I actually asked them about that. They said there aren't any backdoors[0]. We're all good, no worries! :) :) [0] https://mastodon.matrix.org/@element/110340953550548309

It's one of the most significant open source messaging systems that exist today. Anyone can audit it at any time.

What more do you want?

Re: Matrix 2.0: The Future of Matrix

#77

Post by amatecha »

thomastjeffery wrote: post #76
amatecha wrote: post #28

Earlier quoted context omitted.

Oh yeah, I actually asked them about that. They said there aren't any backdoors[0]. We're all good, no worries! :) :) [0] https://mastodon.matrix.org/@element/110340953550548309

It's one of the most significant open source messaging systems that exist today. Anyone can audit it at any time. What more do you want?

How do you know the matrix.org server or the element.io web client is running the same code as the source posted publicly? How exactly do you, personally, audit a hosted service? The answer to both questions is: you don't.

Re: Matrix 2.0: The Future of Matrix

#78

Post by nobody9999 »

amatecha wrote: post #25

Regular reminder Matrix/Element work closely with law-enforcement to provide encrypted comms for them. It's a sector Matrix/Element actively markets to and deals with. My personal view is I'm not using a chat platform designed/developed by an organization so eager to partner with governments and law enforcement agencies. There's Element's Chief Product Officer & Managing Director presenting at the European Police Con…

>Regular reminder Matrix/Element work closely with law-enforcement to provide encrypted comms for them.

Thank you for the reminder. Based on that, are you claiming that Matrix servers/clients are insecure or have government back doors?

If so, what evidence do you have that supports such a claim?

If not, why should I care? I'm not a fan of many organizations/individuals. Should I survey them all to create a database of software those folks use and refuse to use any software they use? What value would I derive from such actions?

Unless you're claiming the former (evidence please), what difference does it make? I use Matrix servers/clients only on hardware that's under my physical control. And I use free (libre and beer) versions of Matrix implementations, so I'm not even giving the developers any money.

Or are you making the argument that LEOs shouldn't have access to secure communications protocols?

I guess I'm confused because I don't understand what the issue might be. If you'd elucidate, I'd much appreciate it!

Re: Matrix 2.0: The Future of Matrix

#79

Post by Arathorn »

xorcist wrote: post #69
Arathorn wrote: post #48

Earlier quoted context omitted.

Hmm… we haven’t had notification problems like that in many years, from memory. Any idea if this was trying to deliver push notifs to Android without using Google? (Which historically has been painful thanks to Android OS versions terminating the app in the bg). Element X has totally rewritten notification code (given it’s moved from Kotlin to Rust) and should be much more robust for bugs like this. Sorry you got bit…

Communicating via Apple or Google is sadly required these days. How does that work with matrix? Does the protocol specify how to trigger those notifications? Do I need to register for a Google API key when setting up the server? I can't recall seeing anything about that in the configuration file.

https://thomask.sdf.org/blog/2016/12/11/riots-magical-push-n... is a great blog (back when Element was called Riot) explaining how it works :)

Re: Matrix 2.0: The Future of Matrix

#80

Post by smashah »

Matrix is great but when is the tech industry going to deal with the fact that many, if not all, bridges are against the respective services' ToS and subsequently put the developers of those bridges under legal risk? Whatsapp has already sent legal threats to multiple bridge-component level project maintainers without any recourse.
Post reply on HN