Closed azul closed 6 years ago
We actually might not need this if we can iterate over all our own claims and persist the store instead.
That way we could use our own claimchain to retrieve all peer info.
Regarding "autocrypt uses a different key than what we would expect in our own mails"... We consider autocrypt the authorative source for which key to use. We only track those keys in our own claim chain. Autocrypt will prefer directly received keys and over gossip. So Autocrypt picks a different key then what we expect in two situations:
If that leads to inconsistencies we will recommend verifying the contact in question... but we will not interfere with the selection Autocrypt performs on its own.
On Sat, May 12, 2018 at 01:48 -0700, azul wrote:
Regarding "autocrypt uses a different key than what we would expect in our own mails"... We consider autocrypt the authorative source for which key to use. We only track those keys in our own claim chain. Autocrypt will prefer directly received keys and over gossip. So Autocrypt picks a different key then what we expect in two situations:
- We saw gossip before but there also was a direct key available.
- The person lost their device or has a new key for some other reason.
If that leads to inconsistencies we will recommend verifying the contact in question... but we will not interfere with the selection Autocrypt performs on its own.
that sounds like a good text fragement to include!
Currently we store the peer info in
self.addr2cc_info[addr]
. This will be empty when loading the account from disc.Instead we should