We do not encrypt messages proactively for invited users who have yet to join.

[ara4n]

This is a problem for encrypted 1:1s, where it's a common idiom that I'd start a 1:1, make it encrypted, send a secret message, and wait for the other person to accept the invite and answer it -
except right now we don't encrypt these pre-invite messages.

As I understand it, the sender client just needs to check the history visibility settings for a room when issuing an invite, and encrypt appropriately. If the target user doesn't exist or has no devices, then we fall back on element-hq/element-meta#647 to resolve things.

[ara4n]

increasing the priority as (proportionally speaking) this is starting to be a major cause of UISIs for me

[ara4n]

#2713 is an alt approach.

[ara4n]

This is almost done, other than the edge case that if the invited user adds a device after being invited, their new device will not be encrypted for as we have no way to know about new devices as they aren't yet participating in the room.

The solution is to let them participate in the room to some extent before joining - perhaps by having the server join the room on their behalf via a @:server user or similar, same as we might use for peeking over federation (matrix-org/matrix-spec-proposals#1777)

[t3chguy]

This got done