[HN Gopher] Show HN: Mini-Diarium - An encrypted, local, cross-p...
___________________________________________________________________
Show HN: Mini-Diarium - An encrypted, local, cross-platform
journaling app
Author : holyknight
Score : 102 points
Date : 2026-02-19 11:54 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| spangry wrote:
| Looks really cool, I like the pretty but minimalist interface.
| Could I store the SQlite file on, say, google drive so that I
| could access my journal from different devices while the contents
| are still kept secure because they're encrypted?
| holyknight wrote:
| Yes, you can definetely can! Currently you can see the location
| of the .db file on the preferences while your journal is open.
|
| 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!
| kantord wrote:
| I love the minimalism of the UI.
|
| 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.
| holyknight wrote:
| Thanks! I will check that out
| 8-prime wrote:
| No more fighting with gifs for README files. Thanks!
| Brajeshwar wrote:
| 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.
| TheFlya7c wrote:
| 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 wrote:
| 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.
| holyknight wrote:
| 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!
| ddtaylor wrote:
| 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.
| holyknight wrote:
| That's definitely an interesting idea
| andai wrote:
| 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.
| Brajeshwar wrote:
| The Alternate Notational Velocity (nvAlt) was my go-to for a
| very long time. https://brettterpstra.com/projects/nvalt/
| cranberryturkey wrote:
| Nice project. The SQLite-on-cloud-drive approach mentioned in
| another comment is actually pretty solid -- if the encryption is
| done client-side before the file hits the cloud, it doesn't
| matter where it's stored. The key thing is making sure the key
| derivation is robust enough that a compromised cloud account
| doesn't compromise journal contents.
|
| 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.
| crossroadsguy wrote:
| Let alone the cloud, SQLite in iCloud Drive is the reason I am
| not using Bear notes app. After losing to convoluted file
| formats a couple of times I do not consider any journal or
| notes app that doesn't let me see/edit plain text files on the
| disk. I will deal with encryption, storage, etc on my own.
| Those are too personal files to be either locked or go behind
| any amount of friction. I still have tons of files locked from
| Dyrii that was abandoned
| holyknight wrote:
| Hey, thanks for the feedback! Yes, currently in the preferences
| you can see the path of your local SQLite DB file, so you could
| definitely sync that to the cloud.
|
| 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!
| giahug wrote:
| for aem
| khalic wrote:
| Dann, that's a fancy README.md , love it
| holyknight wrote:
| thanks!
| october8140 wrote:
| Obsidian.md
| holyknight wrote:
| yes, that's definitely also a valid approach.
| g947o wrote:
| The biggest problem is that this is not available on mobile
| platforms. Most people do this on their phones, not their
| laptops.
| holyknight wrote:
| The support for it is planned. It was thought from the
| beginning with supporting all the major platforms; I just
| started with the desktop support because there was my best use
| case. But the support is already planned in the near future.
| Android will follow shortly, and an iOS version can be done if
| there is demand for it. Thanks!
| alabhyajindal wrote:
| Here's another approach using Rclone and an editor of your
| choice. Rclone has a built in crypt library that can encrypt your
| data and store it in a cloud provider. I use it along with
| Sublime Text to journal, and store my encrypted data on Dropbox.
|
| More here: https://alabhya.me/rclone
| saberience wrote:
| One major problem, I don't want a journal with unbreakable
| encryption where I lose all my data if I ever lose the key.
|
| 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.
| holyknight wrote:
| Thanks for the feedback! That point is super valid; that's why
| I created it with multiple authentication slots in mind
| (currently, it supports both password and public key
| authentication) so you can use multiple simultaneously and do
| not need to rely on one single point of failure.
|
| 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!
| duskdozer wrote:
| >as long as I have access to my Gmail
|
| 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.
| hackingonempty wrote:
| > Every entry is encrypted with AES-256-GCM before it touches
| disk
|
| Until the OS needs more memory and swaps your secrets out.
| mhluongo wrote:
| Protected memory can be used to fix that. Working on a related
| project that I'm planning to share soon.
| plagiarist wrote:
| I thought we were all supposed to be encrypting our swap. Or is
| there something better an app can do about this?
| hackingonempty wrote:
| We're all supposed to be encrypting our storage too but this
| tool advertises that it encrypts your secrets before they hit
| the disk.
|
| 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.
| mystifyingpoi wrote:
| But so what? Another app can't really read swap file/partition.
| Unless it runs with elevated privileges like root, in which
| case the system is compromised anyway.
| holyknight wrote:
| Hey, thanks for the feedback! That's a valid point; currently,
| my main focus is to secure the store on disk, but this is
| definitely a point which could be improved later on.
|
| 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!
| tptacek wrote:
| The "before it touches disk" thing in the promo copy is silly,
| yes, but there's really no sane threat model for this; from
| every vantage point where this could matter, you already have
| game-over attacks on the app.
| CafeRacer wrote:
| I'm using obsidian and cryfs. Nothing has access to those except
| a few programs. I'm storing notes, files, documents, whatever is
| important and everything is synced to the cloud.
| bayindirh wrote:
| This is the beauty of it. If it works for you it's great. If
| this new app works for others, then it's great.
|
| 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.
| holyknight wrote:
| I also, myself, had a similar setup some time ago; that's super
| valid.
| sanarg wrote:
| looks sleek, fast, and stays true to the privacy-first roots we
| all loved. Awesome job modernizing a classic without losing its
| soul.
| drcongo wrote:
| How are we pronouncing that name?
| holyknight wrote:
| It's based on a latin word so it should be not that far from
| the english pronunciation. It would be something like MIN-ee
| Dee-AIR-ee-um
| goodpoint wrote:
| You can just encrypt your partition and use a file editor.
| holyknight wrote:
| you can certainly do that, indeed.
| 8x wrote:
| There already is another, unrelated "Diarium" journaling app:
| https://diariumapp.com
|
| 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.
| desireco42 wrote:
| Thank you for sharing this, this is very interesting problem to
| tackle.
|
| I find this interesting mostly to understand how you are handling
| encryption and security. I think this is one approach but others
| expressed concern over long term viability.
|
| Using Tauri is also very interesting. How did you find using it
| for this simpler case?
|
| Anyhow, very cool project. Don't aband it :)
| otterpro wrote:
| I like the idea, as a niche project for users that don't have
| control over their hardware/OS, or run on USB flash for
| portability.
|
| 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.
| sneak wrote:
| key reuse, and probably other issues in a homebrew cryptosystem
| that wraps AES.
|
| is there a reason we aren't using high level crypto libraries in
| 2026?
| holyknight wrote:
| Thanks for the feedback. This is why I built it FOSS.
|
| 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
___________________________________________________________________
(page generated 2026-02-19 23:01 UTC)