Live data from Hacker News

Native Matrix VoIP with Element Call

element.io

71–80 of 130 posts

Re: Native Matrix VoIP with Element Call

#71
I run a hybrid conference [0] with a physical track and an online track. All tracks communicate using Matrix.

Element Call sounds like something I should integrate into the conference experience, but logistics and audience size is a concern. We'll be entering 1k+ territory this year.

[0] https://handmade-seattle.com

Re: Native Matrix VoIP with Element Call

#74

Earlier quoted context omitted.

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.

It wouldn't be a setting; the intent would be set based on how you initiated the call. If you hit a big 'call Alice and Bob!' button you'd get a call which rings them both; if you hit a 'start a conference' you'd get a Teams/Zoom-style conference; if you hit 'create a voice/video room' button you'd get a Discord-style voice/video room. (N.B. we might not bother with the group-calling option in Element; haven't decide…

Thanks for the extra info. I'm really looking forward to the fruition of this, and will happily be trying out this current Element Call beta quite soon.

Re: Native Matrix VoIP with Element Call

#75

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 confere…

Maybe a bit off-topic but will upcoming Matrix Live also be hosted via Matrix VoIP now? ^^ (At least the smaller ones like interviews where the number of participants is <=8 until compatibility with SFU is done)

sure! :D

Re: Native Matrix VoIP with Element Call

#76

My only concern is does this expose your IP to participants? This is one benefit of Discord Voice channels vs Discord Calls (which are end to end but expose your IP to everyone on the call, and theirs to you, so much so, you just open a console log and you can see them all...).

Currently yes, but it's trivial to fix and we'll do so on Monday - see https://news.ycombinator.com/item?id=30570436

Sounds like hiding IP is going to be opt-in? I'm not sure what the implications are of TURN but what would be the downside of making IP-hiding the default?

Re: Native Matrix VoIP with Element Call

#77
post #73

Why is this an Element thing and not a Matrix thing?

The protocol, spec (MSC3401) and underlying client heavy lifting (matrix-js-sdk) are all Matrix; contributed by a mix of Element employees (Robert, me, Dave) and community contribs (Simon B). The app skin itself on top is Element, given most of the work and the original idea is from Element folks - same reason that Element itself is a product from Element-the-company even though 95% of the code is underlying Matrix projects. The Matrix Foundation itself is a non-profit to look after all the Matrix protocol and reference implementations but doesn’t ship user-facing products, just as W3C and Linux Foundation don’t.

Re: Native Matrix VoIP with Element Call

#78

I run a hybrid conference [0] with a physical track and an online track. All tracks communicate using Matrix. Element Call sounds like something I should integrate into the conference experience, but logistics and audience size is a concern. We'll be entering 1k+ territory this year. [0] https://handmade-seattle.com

please wait until we’re out of beta! :)

Re: Native Matrix VoIP with Element Call

#80

Earlier quoted context omitted.

Currently yes, but it's trivial to fix and we'll do so on Monday - see https://news.ycombinator.com/item?id=30570436

Sounds like hiding IP is going to be opt-in? I'm not sure what the implications are of TURN but what would be the downside of making IP-hiding the default?

it would increase latency badly (the turn server for the call.element.io instance is in the UK, so all traffic would bounce through it, often unnecessarily), and it would cost us loads on bandwidth as a result. It also means that the turn server sees all the IPs and metadata of who is calling who, which may not be an improvement if you trust your caller more than your server admins!

For instance, two users on the same LAN calling each other would end up bounced via the UK, which is a bit unfortunate if they are in Australia.

The solution is really to switch to using SFUs everywhere, which then solves both firewall traversal, scalability and privacy (assuming you’re happy for your SFU to know your IP - but if you’re happy for your TURN to know it, then it’s probably fine).

Post reply on HN