upvote
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.

reply
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.

reply
When I had a Mac I used an encrypted volume in Dropbox. (Not sure if that's a good idea, but I didn't have any issues.)

I used Notational Velocity in those days :) A rare gem of ergonomics.

Later I did the same thing with a VeraCrypt volume.

Now I'm in Obsidian, which has its own encryption (if you trust 'em!), but never quite got the frictionless feeling of NV back.

reply
The Alternate Notational Velocity (nvAlt) was my go-to for a very long time. https://brettterpstra.com/projects/nvalt/
reply
yeah, currently you can export your journal to json or markdown files. So you can walk away at any point. Vendor lock-in is one of the main things i wanted to avoid. That's why I sticked with boring and standard libraries and encryption as much as possible. Thanks for the feedback!
reply
You could store the encrypted contents in an IPFS collection or just use old DHT. Obviously someone else needs to access the content to keep it fresh (even if they don't have the ability to decrypt it), but considering it's markdown you could run an "official" seeder that seeds everything or just have each client run an IPFS node etc.
reply
That's definitely an interesting idea
reply
deleted
reply