Live data from Hacker News

Jitsi Meet: open-source video conferencing

meet.jit.si

81–90 of 96 posts

Re: Jitsi Meet: open-source video conferencing

#81

We were using this for a while to do meetings for sr.ht, but we recently switched to - believe it or not - Mumble. It's old and unsexy but damn it's reliable.

Does this work properly on mobile/without headsets for you?

Our problem was that we had way too much echo/reverb, especially when people were not using headsets. Just having one non-headset user killed it for us. IIRC even one user talking into their phone normally (i.e. no "loudspeaker" setting activated on their phone) killed our conversations because people heard themselves talking. I've tried finding a setting that would be OK to use when no headset is available, but I just couldn't get it to become bearable.

I'd really like to use something self-hosted, but I can't control what devices people use, and users are way too used to simple interfaces. I've also tried a self-hosted Jitsi meet instance more than a year ago, which for some reason has much better echo reduction, but it sometimes didn't work for one or two of our colleagues for unknown reasons, maybe because most of us have Firefox, not Chrome, or mobile browsers. The android app didn't work on my Sony Z1, but I've since changed phones and it seems to work now.

Re: Jitsi Meet: open-source video conferencing

#82
post #59
post #47

Friendly reminder that meet.jit.si is not end-to-end encrypted. So, unless hosting your own instance, using the website or the videoconference integration in Riot means your conversation is routed through an Atlassian-owned server. See https://github.com/jitsi/jitsi-meet/issues/409#issuecomment-... .

afaik jitsi.riot.im (the Jitsi Meet instance used by Riot) is provided by New Vector, not Atlassian

That's slighty better, I guess. It's still quite misleading if you are self-hosting a matrix homeserver, though.

Re: Jitsi Meet: open-source video conferencing

#83
post #73
post #47

Friendly reminder that meet.jit.si is not end-to-end encrypted. So, unless hosting your own instance, using the website or the videoconference integration in Riot means your conversation is routed through an Atlassian-owned server. See https://github.com/jitsi/jitsi-meet/issues/409#issuecomment-... .

Hey there, Jitsi dev here. Yes, that is correct (except the Atlassian bit, we are owned by 8x8 now). Currently WebRTC does not provide the necessary tools to make E2EE possible while still being able to use smart video routing techniques such as simulcast and SVC. There is hope! In order to be able to have E2EE 2 things are needed: * some metadata must be available without decrypting packets, this is (mostly?) availa…

> There is hope! In order to be able to have E2EE 2 things are needed:

That's really good news: then we'll have a very easy to use and reasonably secure option for video conferencing.

By the way, thank you for making this software.

Re: Jitsi Meet: open-source video conferencing

#84
This looks very similar to appear.in . We used to use appear.in about 7 years ago, when it was open like this. Unfortunately, all of these type of services require some kind of revenue model, and it usually requires them to limit or completely close their "open" versions.

Re: Jitsi Meet: open-source video conferencing

#86
post #81

We were using this for a while to do meetings for sr.ht, but we recently switched to - believe it or not - Mumble. It's old and unsexy but damn it's reliable.

Does this work properly on mobile/without headsets for you? Our problem was that we had way too much echo/reverb, especially when people were not using headsets. Just having one non-headset user killed it for us. IIRC even one user talking into their phone normally (i.e. no "loudspeaker" setting activated on their phone) killed our conversations because people heard themselves talking. I've tried finding a setting th…

I've never tried it on mobile.

Re: Jitsi Meet: open-source video conferencing

#87
post #82
post #59

Earlier quoted context omitted.

afaik jitsi.riot.im (the Jitsi Meet instance used by Riot) is provided by New Vector, not Atlassian

That's slighty better, I guess. It's still quite misleading if you are self-hosting a matrix homeserver, though.

There is nothing that prevents you hosting your own jitsi as well and configuring your matrix stack to point at it.

Re: Jitsi Meet: open-source video conferencing

#88
post #80

Earlier quoted context omitted.

Nextcloud Talk is end-to-end encrypted, but not as easy to set up as Jitsi Meet. https://nextcloud.com/talk https://github.com/nextcloud/spreed

To be accurate: no tool that relies on webrtc is end-to-end encrypted. So, no, it isn't. It is encrypted on the wire, just like the other tools mentioned here.

Are you saying that the developer's claims in this issue discussion are wrong?

https://github.com/nextcloud/spreed/issues/37

He says that video/audio in calls are end-to-end encrypted when the server is using the default PHP backend, but not the high-performance backend (an optional paid and proprietary enterprise upgrade).

> video/audio is already end-to-end encrypted

> By default with the internal signaling backend audio/video calls (no matter if 1:1 or group) are end-to-end encrypted.

> and without the HPB its always paar-to-peer [sic] and therefor end-to-end encrypted.

> Chat is currently not end-to-end encrypted, only the audio/video of calls are.

Someone mentioned Jitsi's statement and the developer responded:

>> But I don't understand why the Jitsi people write, "WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption." That would only be true if I decided to use an additional HPB solution, wouldn't it? But not out of the box.

> Exactly, I guess for better user experience and performance they have a SFU or MCU in place (our HPB is an SFU), and therefor it stops being end-to-end encrypted

Re: Jitsi Meet: open-source video conferencing

#90
post #34

Earlier quoted context omitted.

it was my understanding that the reason for copyright assignment was that the FSF believed it would be difficult to defend the copyright of a project if it was owned by multiple people. with several high profile cases in the linux kernel i think this belief has been shown to be overcautious and maybe this has led to a relaxation of the position.

That sounds very reasonable. It's very possible that I'm wrong.

i'd like to point out that your theory sounds just as reasonable, and the truth will only be found by checking actual FSF sources
Post reply on HN