5 ms·

a few problems: >Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. how are you doing this exactly? a 50

a few problems: >Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? How do you plan on doing that without any substantial lag? >2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second you have managed to double your egress for almost no value.

XelNika 6y ago
> you have managed to double your egress Only compared to the current, unencrypted version. For E2E encryption, the alternative, as I see it, is pushing out an encrypted video stream per recipient. He has reduced his egress from O(n) to O(1).
michaelt 6y ago
> how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? By doing whatever Signal and Whatsapp do to support 50-person encrypted group chats. > you have managed to double your egress Not at all. Firstly, the whole point of having two streams is to accommodate viewers with different bandwidth requirements, so the second stream will be a fraction the size of the first. If I'm already uploading HD video at 5 Mbps, and I start also sending an SD stream at 1 Mbps, my egress has risen by only 20%. Secondly, the h264 spec provides for 'Scalable Video Coding' [1] where a high quality stream can have a lower quality 'subset bitstream' allowing a high-quality video to be converted to low quality by selectively dropping packets. So your egress might not rise by even 20%! Although this h264 feature is less widely used, potentially raising engineering costs. [1] https://en.wikipedia.org/wiki/Scalable_Video_Coding https://en.wikipedia.org/wiki/Scalable_Video_Coding
marcosdumay 6y ago
> how are you doing this exactly? A master node negotiates a symmetric key that lasts for the duration of the call. The master is either selected by the server or in round of Paxos, and since everybody has the same key, if he leaves it just needs a new round of negotiation.

XelNika 6y ago

> you have managed to double your egress Only compared to the current, unencrypted version. For E2E encryption, the alternative, as I see it, is pushing out an encrypted video stream per recipient. He has reduced his egress from O(n) to O(1).

michaelt 6y ago

> how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? By doing whatever Signal and Whatsapp do to support 50-person encrypted group chats. > you have managed to double your egress Not at all. Firstly, the whole point of having two streams is to accommodate viewers with different bandwidth requirements, so the second stream will be a fraction the size of the first. If I'm already uploading HD video at 5 Mbps, and I start also sending an SD stream at 1 Mbps, my egress has risen by only 20%. Secondly, the h264 spec provides for 'Scalable Video Coding' [1] where a high quality stream can have a lower quality 'subset bitstream' allowing a high-quality video to be converted to low quality by selectively dropping packets. So your egress might not rise by even 20%! Although this h264 feature is less widely used, potentially raising engineering costs. [1] https://en.wikipedia.org/wiki/Scalable_Video_Coding https://en.wikipedia.org/wiki/Scalable_Video_Coding

marcosdumay 6y ago

> how are you doing this exactly? A master node negotiates a symmetric key that lasts for the duration of the call. The master is either selected by the server or in round of Paxos, and since everybody has the same key, if he leaves it just needs a new round of negotiation.