[waterhouse]

> end to end encryption makes multi-party chats hard. The basic issue is that you don't want to burden end points with sending the video streams to all users. ... The mandatory end to end encryption was circumvented by connecting to a central server.

Dumb question: Can't you choose one video encryption key K, use ten thousand individual secure connections (with different keys) to share K with all the other users, then encrypt your video with K and let central servers mirror it all they like? (Could even have other clients do some mirroring, bittorrent-style.) Regarding downsampling: if the client has only enough CPU and bandwidth to put out one stream, then, yeah, that doesn't work very well, but otherwise you could put out multiple streams (all encrypted with K) of different quality.

[traspler]

So from what I understood, the clients had no way of accessing an encoded WebRTC video frame before it was sent over the network. Only with the new Insertable Streams is this possible. So they kind of plan to do what you say, encrypt it "manually" on client and let the router mirror it. Sharing the key as you proposed still dictates that you can p2p connect to all participants. Sadly that's not possible in all NAT situations and you would still need a TURN server for the clients to meet, having a again a central point.

[garmaine]

Not a dumb question at all. That’s exactly how this would be sensibly designed. Does WebRTC’s built in E2EE encryption not do this?