However, how do one access their diary, when you stopped maintaining it? Is this targeted more at the technically inclined, high-profile people who need to keep secrets?
Personally, I believe that for something like a diary/journal, it should be in a format easily readable by most tools (so a Plain-Text or a MarkDown at best), then it is in a container/folder. Now, encrypt that container/folder instead. In the future, when you need to change the tool for Encryption/Decryption, move the container/folder.
For instance, tools such as https://cryptomator.org comes to mind.
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.
If necessary for things like search, add a cache file to the folder.
Here's a tip: GitHub now allows you to embed a proper video in your README. (https://stackoverflow.com/questions/4279611/how-to-embed-a-v...). Quality would be much better, and people can navigate back-and-forth in the video.
I will improve the experience for this use case in follow up releases, by for example being able to define a arbitrary path for your db file.
Thanks for the feedback!
That's a good win-win situation.
As a fellow obsidian user, I wouldn't scoff at a simple app which does one thing well.
Until the OS needs more memory and swaps your secrets out.
If your machine is fully compromised or actively monitored by a threat actor with physical access, then this tool would not cover you, that's for sure.
If you have any concrete recommendations, I can even give it a try in one of the next releases.
Thanks!
All of the supported operating systems have memory locking functions that prevent swapping out but they are not used in this tool, AFAIK. Also, they are intended to lock things like secret keys that are small and not displayed to the user in a GUI. You can lock the whole process though but a big web browser process is going to significantly up the amount of unswappable memory. Stuff sent to the windowing system may get swapped out too.
More here: https://alabhya.me/rclone
I already pay for a journaling website where I know I can always recover my journals as long as I have access to my Gmail.
So, while I appreciate this security first mindset, for me it actually becomes less interesting. I want my journal to sync to the cloud, I want to be able to unlock it, I don't want to risk losing years of journals if I forget a single key.
I think you should be more cautious about relying on the services of a company like Google that can arbitrarily decide to remove your account data or access. Similar, though the person was fortunate enough to regain access: https://hey.paris/posts/appleid/
You can mitigate hardware failure and data loss, especially for a simple key, but you may not be able to prevent Google from deciding your account is gone one day.
For example, if you set up a password and a key, you can use your key, and if it gets lost or compromised, you can still log in with the password, remove the old key, and generate a new one.
You can do the same in reverse: just use the password and keep the key in a safe place (like a password manager or a physical USB), and if you lose your password, you can still get access with the key.
Thanks again!
One thing I'd push back on regarding the "what if you stop maintaining it" concern: SQLite with AES-256-GCM is about as future-proof as you can get. Both are standards with multiple implementations. The real risk isn't the format dying — it's losing the password. A recovery key export (even just a paper backup of the key material) would go a long way.
For the cross-device case, you might also consider something like Syncthing for sync without any cloud intermediary. Keeps the threat model simpler.
I will improve it further in next releases to make it even simpler (for example, by defining a custom path for the store, which cannot be done currently), but it can definitely be done already.
Regarding the key for recovery: you can already do it. Mini-Diarium already supports both password and public key authentication. So you can use the password and generate the .key file and keep it in a secure place as a backup in case you forget your password (or do it in reverse: use the key file and have the password as a backup).
Thanks again!