Matrix 2.0 — How we're making Matrix go voom!

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%...)

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

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.

Element Call ( link ) is (very) late stage beta - it doesn’t currently use SFUs although we demonstrated one (waterfall) at FOSDEM: ▶ this video The thing keeping it in beta has been a set of really annoying intermittent bugs, which we’ve ended up tracking down by adding full opentelementry support; should expect to exit beta in the next few weeks (currently gathering data to check we really did fix them). Meanwhile we’re experimenting with other SFU implementations (eg LiveKit) to see if we can avoid reinventing the wheel there. Element Call style VoIP is already proposed for the Matrix spec - MSC3401 and MSC3898.

this is also how the Element X rewrite of the Element Matrix client works - although with Rust rather than Zig. We had to add async support to unffi for a good experience from Swift (and Kotlin) tho! ▶ this video has some deets.

ooh awesome. I'm just starting the video but I'm really hoping sharing is improved on iOS. Like full quality video sharing from the share sheets, or seeing my matrix rooms/contacts in the top row of contact suggestions, but most importantly the ability to add 'comments' to photos/links I share with people e.g. share a link to a GitHub repo or a photo and be able to quickly say something in the same sheet without having to switch to the app and say the thing and the back to my browser edit: had to use YouTube in the end: ▶ this video

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