Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native Matrix VoIP with Element Call

element.io

Post reply on HN
Print view View original

31–40 of 130 posts

Re: Native Matrix VoIP with Element Call

#31

Post by arianvanp »

jfkimmes wrote: post #26
Godel_unicode wrote: post #22

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

Mesh doesn't scale for large conference calls though. Usually some SFU needs to be in play. But that's only possible if you have Insertable Streams support which for now only Chrome has

Re: Native Matrix VoIP with Element Call

#32

Post by zaik »

encryptluks2 wrote: post #19

I feel if XMPP just had some better tools this push for Matrix would be unnecessary.

As of recently, Dino already can do video conferences based on XMPP and other clients are working on it as well. There is also a bidirectional SIP/XMPP bridge, so it integrates with other existing Internet Standards: https://sip.cheogram.com/

Re: Native Matrix VoIP with Element Call

#33

Post by Arathorn »

Taywee wrote: post #21
youerbt wrote: 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.

MSC3401 specifically provides for this UX, with the `m.intent` field used when you instantiate an `m.call` within a room (https://github.com/matrix-org/matrix-spec-proposals/blob/mat...):

* `m.intent` to describe the intended UX for handling the call. One of:

1. `m.ring` if the call is meant to cause the room participants devices to ring (e.g. 1:1 call or group call)

2. `m.prompt` is the call should be presented as a conference call which users in the room are prompted to connect to

3. `m.room` if the call should be presented as a voice/video channel in which the user is immediately immersed on selecting the room.

Element Call implements `m.room` effectively (in that you get slung directly into the call once you click on the link). Once we integrate this into Element itself, then the plan is to support all three different intent types: `m.ring` for "group calls", `m.prompt` for "conferences" and `m.room` for discord-style voice/video rooms.

Re: Native Matrix VoIP with Element Call

#34

Post by caslon »

encryptluks2 wrote: post #17

> 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?

There are already like a dozen Matrix clients that don't use Electron. It doesn't take much effort to go to the Clients list and pick one out.

Re: Native Matrix VoIP with Element Call

#35

Post by caslon »

Arathorn wrote: post #28
encryptluks2 wrote: post #17

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

Calling Fractal usable is maybe a bit of a stretch, but there are a lot of really good Matrix clients now!

Re: Native Matrix VoIP with Element Call

#36

Post by traspler »

Arathorn wrote: post #13
traspler wrote: post #6

Do the Homeservers act as Signaling, STUN and TURN servers or are there additional components necessary? Will the SFU part in the future also be part of Synapse or will/are these things split?

The homeservers act as signalling servers. For STUN/TURN you need to run a separate TURN server (typically coturn), as per https://matrix-org.github.io/synapse/latest/turn-howto.html . The future SFU will similarly be split from the homeserver, with the initial implementation based on either Signal-Calling-Service, ionsfu or mediasoup (we're evaluating all three). Of course, the point of being standards based is that…

Thanks a lot for answering in detail!

Re: Native Matrix VoIP with Element Call

#37

Post by panick21_ »

This is really cool. I really feel like this ecosystem is hitting its stride.

The list of upcoming features is long and sometimes I don't understand how they can have so many things going on at once.

Features tend to take a few years to mature, but that is not a bad thing.

I will be setting up my own server shortly, something that I have been thinking about for a while and maybe try to develop something.

Congrats to the team.

Question:

The OpenID part, would it not be cool if Matrx would offer something like a federated SSO experience? So that on other webpages you could use your matrix login instead of Github/Google and co. Hosting that server yourself would be fantastic.

There are of course some issues with Attribute retrieval if user can host these servers themselves.

Re: Native Matrix VoIP with Element Call

#38

Post by kitkat_new »

encryptluks2 wrote: post #19

I feel if XMPP just had some better tools this push for Matrix would be unnecessary.

please read the article (and linked MSC [0]) first and check out how this decentralized(!) conferencing proposal works.

I don't think tools that implement this exist in the XMPP ecosystem at all.

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

Re: Native Matrix VoIP with Element Call

#39

Post by panick21_ »

Arathorn wrote: post #33
Taywee wrote: post #21

Earlier quoted context omitted.

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.

MSC3401 specifically provides for this UX, with the `m.intent` field used when you instantiate an `m.call` within a room ( https://github.com/matrix-org/matrix-spec-proposals/blob/mat... ): * `m.intent` to describe the intended UX for handling the call. One of: 1. `m.ring` if the call is meant to cause the room participants devices to ring (e.g. 1:1 call or group call) 2. `m.prompt` is the call should be presented as…

So will the room have a setting to make a voice video only room, a mixed room or a chat only room?

I assume m.ring would not be needed if its a something like a Teamspeak room.

Re: Native Matrix VoIP with Element Call

#40

Post by danShumway »

Arathorn wrote: post #14
jfkimmes wrote: post #11

Earlier quoted context omitted.

I feel like this is a misunderstanding. You can already self host 'Element Call' and point that to your own homeserver. The passage you're referencing just refers to their hosted Element Call client. I'm pretty sure they're currently trying to move away from credentials-based login on 3rd-party clients to token-based authentication. I would guess they open up their hosted client when they finished implementing this n…

Yup, the grandparent post is a misunderstanding. Basically, we want Element Call to work with a single click to a URL without requiring any account - much as Jitsi and similar do. Therefore it needs to pick a default homeserver. Currently it doesn't play well with existing Matrix accounts (as it will sync in loads of chatrooms which are irrelevant when you just want to do a call), so for expedience we just create acc…

> using your existing server auth

Complete sidenote, but just to expand on the above, the OIDC work is particularly exciting because (at least my understanding is) it opens the door for letting people use a single Matrix account for a lot of different "stuff" on top of Matrix.

There have been some interesting conversations and demos I've seen about using Matrix rooms to help with P2P sync for apps, and there are already bots on Matrix that use Matrix rooms for notifications so you don't need to send emails. But setting that stuff up is kind of challenging if you don't want to make a dedicated new user for each app or grant access to your account -- and (again, assuming my understanding is correct) I vaguely suspect that we might start to see a lot more 3rd-party apps built to integrate with Matrix once it's easier to point someone at a webapp and say, "just log in with your Matrix account, and it'll only have access to one room that's specific to this app."

So imagine potentially having a collaborative app that's hyper-focused on one task, like a collaborative D&D messaging platform or some crud. And in the backend, everyone using that app uses their regular Matrix account, and under the hood it's just sending messages to a shared room -- and then as a developer you don't need to worry about handling a bunch of encryption and user accounts and all of that stuff, you might not even need a backend at all.

Post reply on HN