Managing persistent values

[claucece]

Some ideas:

• if the private key file is deleted, the client profile, prekey profile and prekey messages should be regenerated as well.
• if the forging key file is deleted, the client profile and (maybe) prekey profile should be regenerated as well.
• if the shared prekey file is deleted, the prekey profile should be regenerated as well.
• if the prekey messages are deleted should we deleted the published ones as well?

[olabini]

Actually, if the private key file is deleted, we don't need to regenerate the prekey messages. They will still be valid.
And with regard to the forging key, if that file is deleted, we can still get the public key value from a client profile - so we only need to regen the forging key if both client profiles AND the forging key file is gone. We probably don't need to regen the prekey profile in this case

About prekey messages - yeah, if we notice that we don't have as many prekey messages locally as are published for us, then something is definitely wrong - we should probably try to drain the prekey messages from the prekey server to get back to a good state.

[claucece]

Thanks @olabini

It should be then:

• if the private key file is deleted, the client profile and prekey profile should be regenerated as well.
• if the forging key file is deleted get it from the client profile.
• if the shared prekey file is deleted, the prekey profile should be regenerated as well.
• if the prekey messages are deleted, delete the published ones as well
• if the client profile is deleted, get its info from the current priv key if there is
• if the prekey profile is deleted, get its info from the current shared prekey if there is

[claucece]

As discuss, the functionality to check for validity should be done the moment you read the persisted data, but we should have a timer that checks for this validity as well. I've been thinking that when we want to start a conversation; we should also check for the validity of data; but do no publishing/writing action if it is wrong, just fail (for example, if the long-term public key is invalid, just fail and not generate a new one and write it to a file).

[claucece]

@olabini @giovaneliberato @DrWhax thoughts?

[olabini]

Yeah, sounds good to me. So we have two different functions - one that "ensures", including reading from disk, creating stuff - and another that "verifies" and just returns failure if something is incorrect. The second one should ideally be used before most OTR actions are taken.

[DrWhax]

No extra thoughts, I agree with the idea outlined here.

[olabini]

Basically all of this functionality is there now. The only thing is we don't delete messages on the server if they are deleted locally. I'm not sure how to do this in a good way, honestly, and whether it makes sense.
I'll close this for now.

[claucece]

The only thing is we don't delete messages on the server if they are deleted locally. I'm not sure how to do this in a good way, honestly, and whether it makes sense.

What we perhaps need to do, is show a good error message for the user in this case. I don't think we are showing anything at all.