Caching strategy handles change poorly

[GalenReich]

Currently, it is difficult to update a puzzle if a mistake is identified. This is because of the caching strategy in run_on_mount_and_update .

At the moment, the unencrypted content of a puzzle that is unlocked by a user persists in thewir browser, even if the encrypted content was updated.

This could be addressed by using the previous puzzle's solution to unencrypt the updated (encrypted) puzzle

How to handle the decryption of a locked puzzle when the answer to a previous puzzle changes to the answer of challenges remains a mystery to me.

There is probably a better way of implementing the logic, so overhauls are welcome.

[GalenReich]

Ideally, any changes would allow existing users to preserve their current progress.

[franklindyer]

What do you think of this?

1. Each puzzle is assigned a long random string (e.g. in uuid format) which is never changed. Call it the puzzle's "secret".
2. Clients receive an encrypted copy of each puzzle's secret, encrypted using the puzzle's solution string as the key. When the solution changes, so does the encrypted secret (but the unencrypted secret does not).
3. Each non-initial puzzle is encrypted using the random string assigned to the previous puzzle.

This would avoid erasing a user's progress if the solution to one of the solved puzzles changes.

[franklindyer]

I went ahead and implemented the above in PR #7 - let me know what you think :-)

This does not do anything with your caching issue - but it should prevent the decryption from breaking in the case when answers need to be changed retroactively, so long as the uuid-style "secret" of each puzzle is not.

[GalenReich]

This is a great idea, thank you! I'll have chance to review the PR properly next week, but this looks like a good first step! 🚀