Use trusted device public keys to encrypt folder passwords for syncing

[tmpfs]

No description provided.

[tmpfs]

@conduition there is an edge case with this we should consider.

If we have devices A, B and C. Devices A and B are paired, device B is offline and the owner creates a folder on device A. Now device C pairs with device B which does not yet have the delegated password for the folder (because it was offline) and it won't be able to decrypt the folder password in the account event log (when it syncs) as it wasn't paired with device A when the folder was created (the password was only encrypted using the public key of device B).

[conduition]

Now device C pairs with device B which does not yet have the delegated password for the folder (because it was offline)

How does device B pair with device C without itself coming online? Once Device B comes online, it can pull the new folder and accompanying password before pairing device C.

[conduition]

Even if device B is out of sync, but somehow still manages to pair device C, there should be a way for device C to pull down the latest data, and decrypt everything locally using the vault password. As i noted in slack, there shouldn't need to be direct device-to-device P2P communication except for maybe a very small piece of data (like a key or signature communicated over QR code). Once paired, device C should pull the latest state from the backend server.

[tmpfs]

Agreed, I think you are right, I need to focus the design around the untrusted intermediary server that is also responsible for managing the identity vaults which resolves this problem.

Closing this as it won't be relevant once the server also hosts the identity vault.