Posted by holyknight 10 hours ago
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.
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.
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.
Speaking of which, I have notes / journal entries dating back several decades, all in plain text files. I'm worried about these new projects and their longevity and whether it'll be actively supported 30 years from now. For simplicity, I'd use gocryptfs, Veracrypt, or other general file-based encryption which suits your risk tolerance, and use whatever editor (ie Obsidian, vscode, OneNote, etc) I want to use.
It's a paid app, not open source, but I've been using it for years and it has been working very well for me.
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.
is there a reason we aren’t using high level crypto libraries in 2026?
On the libraries: Mini Diarium actually does use established, widely audited crates rather than rolling its own primitives. See https://github.com/RustCrypto/AEADs for AES-256-GCM, https://github.com/RustCrypto/password-hashes for key derivation, and https://github.com/dalek-cryptography/curve25519-dalek + https://github.com/RustCrypto/KDFs for the key file ECIES scheme. The thin cipher.rs wrapper just handles nonce prepending with no custom crypto primitives.
On key reuse: the master key is intentionally shared across entries (as in Signal, 1Password, etc.), but each encrypt() call generates a fresh 96-bit nonce from the OS CSPRNG, so the (key, nonce) pair is never repeated.
That said, I am not a security expert by any means. If you've spotted something concrete, a specific call site, a protocol flaw, or a library you'd swap in, I'd genuinely love to hear it. Open to PRs or a discussion issue.
Regards