Hacker News Reader

Comment by minimaxir | Hacker News Reader

Incidentally, an unexpected benefit of the server-relay FaceTime implementation is the ability for Apple to allow 32-person FaceTime calls which was a feature just announced on Monday.

View on HN

Wouldn’t that require not being end to end encryption as well?

They can’t stitch and re-encode the video streams if they can’t decode it server side.

You could multiplex multiple adpative-rate encrypted video streams into a single stream per viewer, keeping the content of each encrypted and choosing which bitrate streams to include in the multiplexed output according to current bandwidth. There's no need to actually decode them, you just have to know which encrypted streams are which. All composition would then be done on the clients. This is just a possibility for how it could be done, I have no idea how Apple actually does it. For best results, you'd probably need some non-encrypted metadata about the streams too, e.g. timing information.

Couldn’t you just encode the video for all 31 other public keys?

I believe Apple explicitly said it was still end-to-end encrypted.

You never encrypt anything but the session key with the public key in this case all chat participants will exchange a single shared session key.

Wouldn't this increase the upload bandwidth needed by 31?

There might be a way for it to be end-to-end encrypted, but it's not a simple problem.

You could use a block cipher for the actual video stream with a single key, and encrypt that key with all 31 public keys.

That was the kind of thing I was thinking of. One video stream someone encrypted so any one of X people could decode it.

They specifically note it is still end-to-end encrypted. But I don’t have the details.

iMessage has been doing Group Messaging with end-to-end for years without much issue.

The problem isn’t the key exchange but the data.

Most messaging based solutions keep the same individual key exchange for group sessions also instead of figuring out some key ring or exchanging a key between all individuals.

This simplifies things and allows you to have only one key exchange algo.

Video and any other high bandwidth application would require you to always have a shared key on a group level because otherwise you are doing a lot of extra work and a lot of exra upload.

If you’re ferreting the messages as is between the parties sure but I thought they’re creating the combined stream server side. That way it’s less bandwidth and processing on each client and the functionality would work with any “legacy” phone too.

I’m pretty sure that they multiplex the video into a single stream and tell the clients decode the relevant ones. The server can also do some detection on the device to flag a stream as the focus stream without having to be able to decrypt the data the server can also tell the clients to what bitrate encode their transmition depending on the number of participants and which clients are in focus at the time e.g. if you aren’t talking send a 480p stream if you are send a 1080p one.

Reply on news.ycombinator.com