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

171–180 of 283 posts

Re: Matrix 2.0: The Future of Matrix

#171

Post by gwd »

Arathorn wrote: post #67
brunoqc wrote: post #62

Rip matrix p2p. I wonder if they were serious about it, or if it was just vaporware (a la Musk) to get more funding. It has been announced years ago, they raised millions and they have big governments contracts. WTF is going on?

wtf is going on is that: a) p2p matrix works pretty well as a proof of concept - you can try it from https://arewep2pyet.com ; it’s not remotely vapourware. b) funding has been spent on core Matrix dev and making Element kick ass (cf Element X) c) an awful lot of very large Matrix + Element deployments (eg LuxChat in Luxembourg, Merkury 2.0 in the Polish MOD, many German local authorities) decide to run Matrix deploy…

Just poking around matrix.org, it's not clear exactly how one would "route [some] $[s] to support development" other than paying someone else for a hosted server. Our open-source project just switched to using Matrix from IRC; we're not really big enough to warrant hosting our own Matrix server, so most of us are just using matrix.org. We have some industry funding, and try to support other open source projects when we can; but not on the order of $250/mo (which if I'm reading it right, looks like the cheapest product on element.io -- $5/user/mo, min 50 users). If matrix.org accepts donations, it's not at all clear from your website.

Re: Matrix 2.0: The Future of Matrix

#173

Post by [deleted] »

brunoqc wrote: post #62

Rip matrix p2p. I wonder if they were serious about it, or if it was just vaporware (a la Musk) to get more funding. It has been announced years ago, they raised millions and they have big governments contracts. WTF is going on?

[deleted]

Re: Matrix 2.0: The Future of Matrix

#174

Post by Arathorn »

mike-cardwell wrote: post #142
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…

I just set it up. Wasn't that difficult: 1. Added a new postgres db and user 2. Added a new dns name 3. Added a new cert for the new dns name 4. Added a new vhost to nginx to proxy to a new port using the new dns name and cert 5. Added a simple docker-compose to my config 6. Added a snippet to my .well-known/matrix/client Don't imagine it will take much maintenance. Container will be updated along with the rest of my…

The most important thing is to keep it updated, as we're fairly rapidly iterating on it, and most of the Element X bugs we've seen have actually turned out to be a stale Sliding Sync proxy deployment. Glad it was fairly straightforward.

Re: Matrix 2.0: The Future of Matrix

#175

Post by fabrice_d »

Arathorn wrote: post #96
eviks wrote: post #55

Do they also plan to ditch the desktop Electron version for the users to enjoy similar performance improvements?

Element X actually runs really well on macOS already on Apple Silicon; I regularly use it as my desktop app whenever Element Web is having... issues. It would be amazing to plonk matrix-rust-sdk into Element Web and switch Electron for Tauri or something... but one thing at a time.

It would be nice to provide first class support for state of the art web clients (both desktop and mobile). That would fit your opening stance of "Matrix has been going for over 9 years now, providing an open standard for secure, decentralised communication for the open Web" more than apps tied to the iOS/Android app ecosystems.

Re: Matrix 2.0: The Future of Matrix

#176

Post by xorcist »

derin wrote: post #162
btobolaski wrote: post #151

Earlier quoted context omitted.

Doesn't the use of ntfy change this (Android only, I think)? Homeserver pushes to an ntfy topic, app on phone is listening to that topic. Of course, this just moves the intermediary to ntfy but you can also host a different ntfy server which I hope element supports.

It does. I use ntfy with a ntfy server on one of my VPSs, and I use the official ntfy account on GMS as an intermediary. It works fine, but I'll probably switch back to Matrix's push server at some point. Edit: With Synapse + Element, obviously.

Thanks for sharing. Are you switching back because of pricing, or reliability issues?

Re: Matrix 2.0: The Future of Matrix

#177

Post by preya2k »

jacooper wrote: post #156
preya2k wrote: post #138

Earlier quoted context omitted.

Looking forward to your talk tomorrow in Berlin.

Which talk? Is there a link?

This one: https://summit2023.matrixmeetup.de/conference/talk/AXGMEA/

Don’t think there’s a live stream. But there might be a recording afterwards.

Re: Matrix 2.0: The Future of Matrix

#178

Post by Arathorn »

dingnuts wrote: post #160
Arathorn wrote: post #60

Earlier quoted context omitted.

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 scr…

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.

Re: Matrix 2.0: The Future of Matrix

#179

Post by Arathorn »

preya2k wrote: post #177
jacooper wrote: post #156

Earlier quoted context omitted.

Which talk? Is there a link?

This one: https://summit2023.matrixmeetup.de/conference/talk/AXGMEA/ Don’t think there’s a live stream. But there might be a recording afterwards.

There should be a live stream. (And I might even make it there in time to give the talk).

Re: Matrix 2.0: The Future of Matrix

#180

Post by cyberax »

vilunov wrote: post #150
cyberax wrote: post #137

Earlier quoted context omitted.

Jabber core protocol (XMPP) is kinda like SMTP. It deals with transmission of messages between two peers. Just like with SMTP, you can federate servers, so they can exchange messages between each other. And the similarities don't end here. XMPP doesn't have built-in support for encryption (apart from the basic TLS encryption for the transport layer), it doesn't have support for message archiving and chat history sync…

Most of criticism of XMPP with regards to fragmentation and extensions can be applied to Matrix as well. In fact, the sliding sync itself already fragments the ecosystem by not being supported out of the box by many server implementations and therefore homeservers. Encryption often has to be enabled with some machinations as well if we're talking about clients other than Element (and electron-based). On the other han…

This criticism kinda misses the point. E2EE, especially for group chats, is _the_ reason to use Matrix. It's an extremely hard problem, and you'll basically need to replicate what Matrix does if you want to solve it.

Doubly so when you add federation.

It required more than one iteration of Matrix to get it right, which I (personally) totally expected to happen. I don't think XMPP will _ever_ get it right.

Regarding clients, I don't think Element is worse than most (all?) XMPP clients when you look at the functionality past simple 1-to-1 messaging. And forget about mobile apps, XMPP just sucks on mobile.

Post reply on HN