Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Using your first solution (a custom pion SFU relay), and selectively routing the streams between "edge" servers would be similar to Octo, as shown here.

Using TURN servers instead would not have the benefit of SFU (i.e. clients will have to upload to each peer) - i.e. its still a full mesh network.

Using TURN servers with SFU would work similar to your pion solution, however it would also use more bandwidth, as it would be forwarding the same streams multiple times for each peer routed through that TURN server (instead of once per stream with SFU)

As for e2e encryption over webrtc via an SFU - yes, this is possible, but its currently very messy (wasm video encoding and encryption streamed over an SFU-bound datachannel with full mesh distribution of the encryption key). There are plans to implement "Insertable Streams" which you will be able to transform (e.g. encrypt) which will allow this to work without the hacks.



>As for e2e encryption over webrtc via an SFU - yes, this is possible, but its currently very messy (wasm video encoding and encryption streamed over an SFU-bound datachannel with full mesh distribution of the encryption key). There are plans to implement "Insertable Streams" which you will be able to transform (e.g. encrypt) which will allow this to work without the hacks.

So currently Jitsi meet the one on the web site is NOT e2e encrypted?


Yeah, not e2e encrypted when it goes through videobridge (as per this article).

I haven't checked, but its possible for 1-to-1 or small meetings they may go full mesh, which would be e2e encrypted - a few platforms do this.

edit: just checked and jitsi is "full mesh" for 2 participants - if you have 3 or more (video) participants, it switches over to SFU.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: