Most of the "affordability" and "pricing" discussion is pointless because we don't have any real numbers on their margins per token. So, yes, they are subsidizing their subscription plans compared to the API prices, but the API prices could already be stupidly inflated, so the relative price comparison is a nothing burger.
Until we know (or at least get a hint) on their margins on API prices, any pricing discussion is pointless.
People are missing the long-term horizon on this. Yes, definitely, you can automate most of your workflows as a software engineer with today's LLM frontier capabilities fully E2E. But many things are still super open:
-First, cost is not a settled topic yet. We have no indication that automating everything E2E will be a cost-effective way of doing stuff. So the bare minimum is that you will need some expert designing the workflows in a token-efficient way. Worst-case scenario, tokens become super expensive and only certain parts of the job can be efficiently automated and many companies are not even able to afford tokens.
-Second, the system you just "created" is just a static snapshot of today. Yeah it may work fully automated for 6 months, maybe a year. What then? Breaking changes? Updates? Re-designs? What if the quality slowly degrades until nothing ever works again? Who will fix that? There are so many unknowns that it is borderline irresponsible to make guesses on what can be automated sustainably long-term or not. Unless you are OpenAI's Codex team wasting a billion tokens a day on automating and self-improving everything, there is a high chance that everything you set up today is completely useless in a year.
-Third, the core engineering workflow hasn't changed a single bit. People like stakeholders, product owners, PMs, etc. can come up with ideas and things to build but someone needs to take decisions on what gets built and what doesn't, balance out paying down technical debt vs. feature development, incorporate new domain knowledge into the system (Or would you expect your PM to be tweaking the prompts about a new regulation regarding GDPR or a completely new legal framework that changes the whole thing?)
-Fourth, probably the most important one. If you think AI will soon get good enough to get self-improving and self-sustaining enough to replace full engineering departments E2E with no supervision then nothing else matters because we will all end up without a job and living on UBI (not only tech people). So why do you even care? If it happens it doesn't matter, and if it doesn't happen we just continue doing what we were doing until now. Why do you care?
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.
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.
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!
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).