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.

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.

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, 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!

No more fighting with gifs for README files. Thanks!

Thanks! I will check that out

You can reload the page. It's an animated gif that shows the full app functionality.

But your feedback is still valid. It's unfortunate that OP used the login screen as the last frame; it'd be better to show the app as the last frame, or just loop the animation.

thanks for the feedback, i think i will loop the gif. I was more focused on making it as small as possible to be fast and i forgot about the looping.

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!

Definitely a niche thing. Thanks for the feedback

The real encrypted journal is hidden among several fake ones, so two authentication factors are used: the key and the journal ID.

thanks!

Honest answer: The pain of setting up an encrypted container. This seems simple, single use and immediately ready to use after downloading.

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!

You certainly can, this is just a different flavor of solving a problem that can be solved in multiple ways.

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.

I also, myself, had a similar setup some time ago; that's super valid.

yes, that's definitely also a valid approach.

you can certainly do that, indeed.

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

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

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!

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

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

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!

This site is not for bots, go away please.

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.

Protected memory can be used to fix that. Working on a related project that I'm planning to share soon.

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.

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!

I thought we were all supposed to be encrypting our swap. Or is there something better an app can do about this?