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

11–20 of 130 posts

Re: Native Matrix VoIP with Element Call

#11

Post by jfkimmes »

mawise wrote: post #7

> Element Call is built entirely on Matrix: it doesn’t need any additional servers to get going. You can run it against your existing Matrix homeserver to provide complete self-sovereignty… > In the near future, we will support using the app with any homeserver I really hope this isn't an indicator how how Element the company will be focusing more on their paid offerings to the exclusion of supporting private homeser…

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 new authentication scheme to avoid the doubled effort and to discourage using your homeserver credentials on "random" clients.

Re: Native Matrix VoIP with Element Call

#12

Post by jeroenhd »

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.

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. Depending on your teamspeak setup you can enable guest access to your server, enable registration for server user accounts (or manually register it for specific members), or only let people with existing accounts from other servers join in (their own, matrix.org ones, you name it). You might also need to tweak the ACLs a bit, but other than that you'll have all the core features Teamspeak and friends provide.

I think the biggest difference between the existing Matrix group call system and what's been announced here today is the new UI/UX, and the fact that the native group call API and reference implementation are nearing completion. Both are great news, but don't necessarily add new user-facing features to the Matrix ecosystem.

Re: Native Matrix VoIP with Element Call

#13

Post by Arathorn »

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 you'll be able to mix & match SFUs and MCUs from other vendors.

You can find out more about the architecture from my talk at Commcon (https://2021.commcon.xyz/talks/extending-matrix-s-e2ee-calls...) - or Robert's talk at FOSDEM: https://fosdem.org/2022/schedule/event/matrix_metaverse/

Re: Native Matrix VoIP with Element Call

#14

Post by Arathorn »

jfkimmes wrote: post #11
mawise wrote: post #7

> Element Call is built entirely on Matrix: it doesn’t need any additional servers to get going. You can run it against your existing Matrix homeserver to provide complete self-sovereignty… > In the near future, we will support using the app with any homeserver I really hope this isn't an indicator how how Element the company will be focusing more on their paid offerings to the exclusion of supporting private homeser…

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 accounts on its default homeserver to get going.

However, we're in the process of moving Matrix over to OIDC for auth (as per https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s...), at which point apps like Element Call should be able to easily hook into your existing account on your own homeserver using your existing server auth. In other words, the server will auth you, not the client. Combined with Sliding Sync (aka Sync v3) https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s... this will then let you securely and efficiently use your existing Matrix account with apps like Element Call without it all getting bogged down with your existing chatrooms (or needlessly giving Element Call access to conversations it shouldn't care about).

Finally, this is beta: the auth/reg stuff is very much placeholder - for instance, it doesn't even expose password reset, given the upcoming shift to OIDC.

Re: Native Matrix VoIP with Element Call

#15

Post by Arathorn »

3np wrote: post #4
kitkat_new wrote: post #3

Earlier quoted context omitted.

I think it does in theory (Matrix supports changing room addresses), however what is the benefit of this as opposed to using the same address for all meetings?

The person you're replying to wants to set it to something custom, to make it memorable and meaningful.

We have this today. https://call.element.io/whateveryouwant does what you'd expect.

Re: Native Matrix VoIP with Element Call

#16

Post by jeroenhd »

I wonder if this setup can be leveraged to create a Twitch-like streaming solution based on Matrix. The group call setup is clearly not built for such a use case, but if you only stream to a small audience (say, people paying for a certain perk on Patreon?) you could probably use this quite easily.

The client would need better support for alternative inputs, of course, such as the RTMP suggestion found on the Github issues page, but it can and should work.

What I'm also curious about is how this fits in with the experiments on the peer-to-peer mesh system (running a homeserver on every client). Forwarding video across a web of clients would become bandwidth and CPU intensive real fast and the added latency would be non-negligible.

I'll be watching this play out with great interest, that's for sure.

Re: Native Matrix VoIP with Element Call

#20

Post by Arathorn »

From my perspective, the really exciting thing about this that it works equally well in mobile web browsers as well as desktop web - clicking on a link on Mobile Safari should Do The Right Thing without having to install anything.

Moreover, because it's built on Matrix, MSC3401 (https://github.com/matrix-org/matrix-doc/blob/matthew/group-...) means that we'll finally have decentralised cascading video/voice conferences once the SFU (selective forwarding unit) component is added into the mix. So, for instance, users on the same homeserver will get their video feeds relayed locally with minimal latency... and then users on another remote homeserver will also get mixed locally with minimal latency, trunking the two together. If the link dies or one homeserver dies, the conference will keep going - i.e. precisely the same semantics as normal Matrix.

Post reply on HN