It is actually not necessary.
On Tue, 16 Jul 2024 at 14:15, Tim Henkes <syndace(a)web.de> wrote:
I think this can be compared to calls or A/V in that
both devices are
expected to be actively used while the transfer is happening. I think this
should be possible even on aggressive platforms like iOS.
Aggressive or not, it might actually be unnecessary, at least according to
our vision of multi-device encryption.
We have discovered that whenever there are encryption session that are
encrypted for one of your devices, and not the other, this leads to a
horrible user experience that can't be recovered in no way. Grabbing the
wrong device and seeing 'unable to decrypt message' which is decryptable on
another of your devices is really, really bad and inconvenient, and we
treat such incidents as a severe error.
So our solution is to require the sender to encrypt messages for all valid
devices of the message recipient, warning the user really aggressively if
one of those devices is not trusted (via fingerprint matching or our other
method of verification via code), nudging the user to perform device trust
procedure. This way, the only history you need to synchronize conversations
that happened prior to addition of this new device just once, at device
initialization. For this, you don't need to create some complex protocols
that would continuously sync history.