e2ee by default + 3pid invite = fail

[ara4n]

as until the invitee has created an account, we can't encrypt for them

[jryans]

@ara4n says: i think we can fix it with a warning in the composer saying messages sent in encrypted room before anyone has been invited or joined will be undecryptable

[ara4n]

another approach could be to encrypt for a dehydrated device for the user until they exist, but given this breaks E2EE (given the bot driving the dehydrated device will be able to bug history), I think we might as well just send unencrypted and save the simplicity.

I don't think there is any formally cryptographically sound way to encrypt for nonexistent users otherwise, given you need to somehow send the keys to them, and if you send to the server in advance, the server could hand them out to anyone who claims to be that user (e.g. itself).

Alternatively, we could encrypt for the dehydrated device, and encourage the invited user to verify OOB as soon as they're online in order to prove that they are the rightful owner of that dehydrated device, so that even if the server tried to hijack the dehydrated device, the correspondents would know about it. But by this point it might be too late.

Alternatively, we could encrypt but rely on keyshare reqs to rescue the history (requiring the sender to come back online to resend the megolm keys once requested by the receiver, and requiring the keyshare req to bubble up as a notification to the sender, which they currently don't). This is horrible UX.

The least worst option right now feels to be send unencrypted messages until there's a device you can encrypt for.

[t3chguy]

But that only happens if someone manually creates a private room and 3pid invites, for DMs 3pid won't yield an e2ee room unless the account is already bound.

The least worst option right now feels to be send unencrypted messages until there's a device you can encrypt for.

So this is what we do now but with no automation to auto-encrypt after the 3pid fulfils.

For the case where a user manually makes an encrypted room and 3pid invites, the invite UX should probably tell them that they won't be able to decrypt until they follow the link and join

[kittykat]

Invited users should now get keys shared as part of the invite process. I'm going to close this issue for now as that should resolve it. If you feel that there are further improvements which could be made, please file a new issue.