Hacker News Reader

Comment by Brajeshwar | Hacker News Reader

This is Nice.

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.

View on HN

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.

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.

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.

The Alternate Notational Velocity (nvAlt) was my go-to for a very long time. https://brettterpstra.com/projects/nvalt/

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!

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.

That's definitely an interesting idea

You could also use plain markdown files, any free Markdown editor/IDE, and git, and sync with a remote Git repo using gcrypt for encryption (git-remote-gcrypt).

It's just a bit of a pain to set up, and also, not mobile-friendly.

yeah, that's the whole point! :D

Reply on news.ycombinator.com