[georgyo]

I cannot think how you could possibly do the key exchange securely and automatically, if you want to give a link to someone and have it "just work".

If all you have is the URL, then the server sees the encryption key.

Video conferencing also rarely has users register. So there isn't a way to validate users either. And even if they did register and users didn't care about the extra friction, multiple devices means either the server stores your private key, or you have many keys which is much harder to verify.

E2EE is much easier on phones, which is why Signal is so good. The identity is your phone number, and you can only have one key associate with your number. That key never leaves your device. Conceptually easy.

Video conferencing has none of those advantages, and I don't know how you would make it conceptually easy for users without reducing the security.

[waterhouse]

I don't know much about the broader context, but to this part:

> If all you have is the URL, then the server sees the encryption key.

Not necessarily. It's possible to put the key after a "#" in the URL, which allows client-side code to use it without sending it to the server. This technique is used at ZeroBin, among other places. (Edit: This is actually done in the video in the OP as well.)

[crznp]

You could still make the phone a primary device and allow it to perform the key agreement and pass control off with a QR code, but that is complicated and leaves open the question of who is allowed in this conference.

So perhaps you just give up on persistent identity: just have an unencrypted waiting room, the organizer and their delegates can approve people in the waiting room to enter the encrypted conference.

[GordonS]

Do you mean kind of like how authentication is sometimes handled on input/UI constrained devices (e.g. TVs), where a message could be played to callers, asking them to enter a one-time code at a particular website?

On the face of it, this could work quite well for most people.