Matrixdotorg
2 HN recommenders · recommended in 4 months, 2023–2024
48:45 · 16K views · Feb 7, 2023
A FOSDEM 2023 talk from the Matrix team on Matrix 2.0, covering sliding sync, the Element X client rewrite and next-generation calling. It explains how Matrix aims to match the speed of proprietary messengers.
HN threads link it as the primary source for Matrix's performance claims and sliding sync improvements.
8 comments from Hacker News
Fixing this has been the primary focus of the core Matrix team over the last year - we revealed the end result at FOSDEM a few weeks ago, and it literally improves performance to be better than Telegram/Discord/Slack or anything else we've benchmarked against: this video If you're feeling adventurous, try develop.element.io and enable Sliding Sync in Labs, and you should get instant login, sync, and orders of magnitude better performance (but it is definitely beta). You may need to run your own SS proxy, for which we published a guide yesterday: [LINK]
Matrix 2.0 will put an end to that trait plaguing the protocol's viability. With the new "sliding" sync, clients will be able to fetch stuff much more efficiently (and more akin to Discord's API, for example) than before. Syncing an freshly logged-in account takes seconds instead of minutes and syncing messages when returning to the app is instant. They presented this at FOSDEM this year: this video
If you watch the video, you'll see that we're making the client-server protocol crazy lightweight ( this video ) and that we're adding the ability to remove servers entirely and go full P2P: ( this video ). So you're working on stale data here. (Also, only about 35% of users we're aware of are on the matrix.org server, not 99%...)
The Matrix team spent 15 years building SIP stacks before we gave up and created Matrix, so I can answer this with some confidence: Superficially, Matrix looks a bit like SIP: for 1:1 calls, you send an m.call.invite (like a SIP INVITE) to someone; they answer with an m.call.answer (like a SIP 200 OK); eventually someone hangs up with an m.call.hangup (like a SIP BYE). However, the differences are: * As a transport, everything goes over normal Matrix signalling (by default HTTPS+JSON) rather than SIP's mix of UDP and TLS sockets. As a result, no need for SIP's three-way handshakes inherited from its UDP transport * As a result, you inherit Matrix's end-to-end-encryption and decentralisation for free (so no special Routes, Vias, Record-Routes, branch parameters etc from SIP - it uses the Matrix client-server and server-server APIs over HTTPS instead) * Everything is trickle ICE by default for rapid call setup, no need to wait until you have all the ICE candidates to proceed with the call * No offerful/offerless invites: everything is offerful. * Matrix piggybacks on WebRTC for its media protocol, so you don't have the fragmentation of different media transports that SIP has inherited * Matrix (as of [LINK] ) now supports multiparty native VoIP calls in the same conversation: effectively letting you signal full-mesh, SFU and MCU style multiway video/voip using the same mechanism as you'd use for a 1:1 call. This is probably the biggest difference in the end: with Matrix's VoIP
P2P Matrix is a dialect of Matrix where the server runs inside the client itself - see arewep2pyet.com for details. In other words, there are no servers (other than optional store-and-forward relays). It's insanely cool - you can see a demo at this video . It's also unfunded and on hiatus until someone provides some $ so we can work on it again. Right now, normal Matrix is a client-server model: you can't send messages from a client without it talking to a server (and then to another server, and then to another client). MatrixRTC VoIP and Video calls in Matrix 2.0 also go via server (for now), in order to support multiple participants and firewall traversal. Obviously, both messages and calls are end-to-end-encrypted (other than in public chatrooms), which makes it less important that they go via a server today.