[Autocrypt] Ambiguity about resets in the current level 1 spec?

[Vincent Breitmoser]

> Which interpretation is correct? Do we no longer have resets?

Of course we do :) The logic just moved: The data is now stored in a dumb way,
just timestamps and key data. Then a recommendation can be calculated from that
data.

The "state reset" we had earlier is now basically the "discourage"
recommendation, which occurs when the timestamp of the last seen message with an
autocrypt header is more than 35 days older than the last seen message without
one.

Three considerations played into this:
1) If it's possible to encrypt, but not advisable due to a stale autocrypt
header, the user should still have an option to do so. If we did this
differently, it's very likely most MUAs would break that SHOULD.
2) For the use case where messages are regularly received from the same peer,
sometimes with and sometimes without Autocrypt headers, we don't want to "flip
flop" between "discourage" and "available" all the time. Hence the 35 days delay
before a key is considered stale.
3) As for moving the logic from "parse time" to "compose time", the idea is that
saving the data "raw" and calculating the state only on demand makes the
database schema trivial, and (probably) makes a migration easier if we ever
change the recommendation algorithm.

Nice to hear from you! Good to see things are still moving with Mailpile!

 - V