> 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.
Native Matrix VoIP with Element Call
21–30 of 130 posts
Re: Native Matrix VoIP with Element Call
#22Re: Native Matrix VoIP with Element Call
#23> 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…
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?
Re: Native Matrix VoIP with Element Call
#25Re: Native Matrix VoIP with Element Call
#26Has 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.
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?
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?
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
#29I feel if XMPP just had some better tools this push for Matrix would be unnecessary.
Re: Native Matrix VoIP with Element Call
#30Has 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...
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.