| ▲ | TheFlya7c 8 hours ago | |
I think there are two different concerns mixed together: 1) Can I still read my data in 10 years? That’s mostly about open, well-documented formats + an export path. A journaling app can still be “safe” here if it can export to Markdown/plain-text (or at least JSON) and the on-disk schema is documented. 2) Can I decrypt it in 10 years? That’s about using boring primitives (AES-GCM, Argon2/scrypt/PBKDF2) and keeping the crypto layer simple. If it’s standard crypto, you’re not locked to one vendor the way you might be with a bespoke format. The “plain files in an encrypted folder” approach (Cryptomator/VeraCrypt) is totally reasonable—and arguably the simplest threat model—but you do give up a lot of what makes a journal app nice (full-text search, tags, structured metadata, conflict handling, etc.). SQLite + client-side encryption is a fine compromise if there’s a solid export and the KDF/password story is strong. The biggest real risk is still: losing the password. A printable recovery key / key export would help more than switching formats. | ||
| ▲ | armchairhacker 8 hours ago | parent [-] | |
Make the journal app store its data in plain-text Markdown files in an encrypted folder (or ZIP). If necessary for things like search, add a cache file to the folder. | ||