Handle JSON input/ output in online sync between devices feature

[SarahRemus]

We are currently developing the functionality of syncing the TTL data to Google Drive, related to #913.

I would like to implement some methods to handle the JSON input and output, so we can guarantee that only valid TTL data is imported into TTL.

When exporting the data, I think it would be good to encrypt it with a passphrase that the user enters into TTL. I was thinking of using json-file-encrypt 2 for that. If the user loads the data back into TTL, he has to enter the passphrase used before and then the data gets decrypted and imported into TTL.

I was thinking of additionally checking if the JSON schema is correct with jsonschema, however, I'm not sure if that is event necessary if we are encrypting the data anyway.

What do you think, @araujoarthur0 @tupaschoal @thamara?

I would like to work on this! :)

[araujoarthur0]

When exporting the data, I think it would be good to encrypt it with a passphrase that the user enters into TTL. I was thinking of using json-file-encrypt 2 for that. If the user loads the data back into TTL, he has to enter the passphrase used before and then the data gets decrypted and imported into TTL.

Looks cool! I also think the custom passphrase should be optional. Some people might not care enough to encrypt the JSON, while some will. When they don't, we still encrypt with a fixed string just so the file is not editable.

I was thinking of additionally checking if the JSON schema is correct with jsonschema, however, I'm not sure if that is event necessary if we are encrypting the data anyway.

I agree that it might feel unnecessary given the encryption. But it would be good if we had the schema even for internal reasons. We never know what might come in, or even across releases if we change the format. Might even be good then to have a schema version number in the JSON so we define compatibility. I also just like JSON schemas hahaha

[SarahRemus]

Looks cool! I also think the custom passphrase should be optional. Some people might not care enough to encrypt the JSON, while some will. When they don't, we still encrypt with a fixed string just so the file is not editable.

Yes, that is a good idea!

I agree that it might feel unnecessary given the encryption. But it would be good if we had the schema even for internal reasons. We never know what might come in, or even across releases if we change the format. Might even be good then to have a schema version number in the JSON so we define compatibility.

Okay, I see that! :) I will start working on the JSON validator. I think it's a good idea to split this issue into two PRs. One for the file de/encryption and one for the validation.

[araujoarthur0]

Sure!

[SarahRemus]

I'm done implementing the validation of the TTL JSON. @araujoarthur0 could you update the sync branch, so I can create a pull request that only includes my relevant changes?
Or should I create a pull request on main, as this feature might be used by other parts in the code as well? (And it's independent of #913.)