Live data from Hacker News

Native Matrix VoIP with Element Call

element.io

21–30 of 130 posts

Re: Native Matrix VoIP with Element Call

#21
post #8

> And, the big one drum roll, please ... we will be integrating this into Element so you can have voice and video rooms, and hold group video calls inside the Element app natively over Matrix. I'd love to replace my teamspeak server with this. Discord is tempting, but I'd rather host it myself.

That's the exciting bit for me. I love Matrix, but video and voice being primarily "call" based is painful, when what I really want is a dynamic voice/video room that people can quickly and easily drop in and out of, like in Discord.

Re: Native Matrix VoIP with Element Call

#23
post #8

> And, the big one drum roll, please ... we will be integrating this into Element so you can have voice and video rooms, and hold group video calls inside the Element app natively over Matrix. I'd love to replace my teamspeak server with this. Discord is tempting, but I'd rather host it myself.

For what it's worth, Matrix / Element already have something like this with the built-in Jitsi integration in (some) clients. The UX isn't great right now in my opinion (which will hopefully change when this project gets merged into Element) but if all you want is rooms, text and voice, then you're already set with the current setup. You can self-host a Jitsi instance and use it in Matrix rooms as an integration. Dep…

Yes but the current UX for that is terrible. With the proposed MSC linked in the blog post, Matrix will additionally gain Teamspeak/Discord like voice channels [1].

With this we could finally have a proper Teamspeak/Mumble bridge for voice that gets properly represented on the Matrix side which is amazing :D

Also kinda funny that Teamspeak only recently started using Matrix for their global chat feature [2].

Maybe now after the gitter acquisition, Element should consider acquiring a certain voice-focused company ;)

**

[1] https://github.com/matrix-org/matrix-spec-proposals/blob/mat...

[2] https://community.teamspeak.com/t/teamspeak-5-beta-bug-repor...

Re: Native Matrix VoIP with Element Call

#24

> We’re also working with the Tauri core team to provide cross-platform lightweight desktop apps as soon as possible! How about a lightweight cross-platform Matrix client that doesn't rely on Electron?

Well, it doesn't use Electron, it uses tauri, which doesn't bundle chrome but uses the native browser and is therefor much smaller, faster und more lightweight.

Re: Native Matrix VoIP with Element Call

#26

Has anyone looked into their implementation of E2EE for calls? My naive assumption is they are brokering some kind of shared key exchange as opposed to requiring everyone to send an individually encrypted stream to everyone else.

The post says there is no E2EE at the moment. They're probably talking about signalling, since with the current implementation of full mesh you get E2EE 'for free' in WebRTC.

Also the post mentions: https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls...

Re: Native Matrix VoIP with Element Call

#27

> We’re also working with the Tauri core team to provide cross-platform lightweight desktop apps as soon as possible! How about a lightweight cross-platform Matrix client that doesn't rely on Electron?

Why not just use FluffyChat?

https://fluffychat.im/

Re: Native Matrix VoIP with Element Call

#28

> We’re also working with the Tauri core team to provide cross-platform lightweight desktop apps as soon as possible! How about a lightweight cross-platform Matrix client that doesn't rely on Electron?

Tauri + Electron (or Hydrogen) provides a lightweight cross-platform Matrix client that doesn't rely on Electron...

Meanwhile, Nheko, NeoChat, Fractal and others provide very usable lightweight native cross-platform Matrix clients too. Element is also working on its own experiments (TBA) based on matrix-rust-sdk.

Re: Native Matrix VoIP with Element Call

#30

Has anyone looked into their implementation of E2EE for calls? My naive assumption is they are brokering some kind of shared key exchange as opposed to requiring everyone to send an individually encrypted stream to everyone else.

The post says there is no E2EE at the moment. They're probably talking about signalling, since with the current implementation of full mesh you get E2EE 'for free' in WebRTC. Also the post mentions: https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls...

So in the initial beta we haven't turned on E2EE, purely because it will make it way harder to debug any problems which surface.

However, at this rate, things are looking pretty stable and i'd expect us to enable it in the next few weeks. It uses normal Matrix E2EE, which means a Double Ratchet between the pairs of devices participating in a given conversation, which is then used to secure the signalling which is used to set up the calls between the devices. The call media is transport-layer encrypted via DTLS and SRTP, so as long as the signalling with the DTLS fingerprints is secured by Matrix E2EE, the whole call fabric will be E2EE.

https://github.com/matrix-org/matrix-js-sdk/pull/2002 is the PR we actually need to merge in order to enable E2EE on it, ftr.

Post reply on HN