> I've had to rely on key sharing quite often (even requiring manually requesting keys a bunch of times) for E2EE to work reliably.
This is because it's papering over edge cases in E2EE.
> Having the sending party re-encrypt messages for a new device require the other party to be online
We never make senders re-encrypt messages like this, and we never would.
Firstly, key-sharing from the sender does require the other party to be online already.
Otherwise, if you have the keys in an existing device, you could get them onto your new device by backing them up on the server - or using "dehydrated" devices; where the 'new' device you log into is actually one which is stored encrypted on the server, and "re-hydrated" into a new device when you login... and so already has your keys. These have security trade-offs obviously (what if your online backup gets pwned? what if your dehydrated device gets pwned?) but it's not obviously worse than exfiltrating the missing keys from the sender.
This is because it's papering over edge cases in E2EE.
> Having the sending party re-encrypt messages for a new device require the other party to be online
We never make senders re-encrypt messages like this, and we never would.
Firstly, key-sharing from the sender does require the other party to be online already.
Otherwise, if you have the keys in an existing device, you could get them onto your new device by backing them up on the server - or using "dehydrated" devices; where the 'new' device you log into is actually one which is stored encrypted on the server, and "re-hydrated" into a new device when you login... and so already has your keys. These have security trade-offs obviously (what if your online backup gets pwned? what if your dehydrated device gets pwned?) but it's not obviously worse than exfiltrating the missing keys from the sender.