holyknight

In which world are you living? For most programming jobs, the code is absolutely the easiest part of the whole thing, which is just gatekept into absurd bureaucracy and ceremony. Even if coding became 100x faster with 0 errors tomorrow, the software in most companies would still move at a snail's pace.

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.

fair

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?

That's the best test of time

Hi thanks!! You can find more details about the security in the SECURITY.md https://github.com/fjrevoredo/mini-diarium/blob/master/SECUR...

Regarding Tauri, I liked it a lot. This is my first time using it for any serious project.

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

yeah, that's the whole point! :D

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.

Definitely a niche thing. Thanks for the feedback

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

That's definitely an interesting idea

you can certainly do that, indeed.

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

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

yes, that's definitely also a valid approach.

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!

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!

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!

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

Thanks again!

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! I will check that out

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!

not with these hardware prices...

It’s basically the same thing that always happens when you choose a technology because it’s convenient rather than a great fit for your problem. Sooner or later, you’ll hit a wall. Just because you can cook a salmon in your dishwasher doesn’t mean you should.

your premise would've been right, if memory wouldn't skyrocketed like 400% in like 2 weeks.

wow amazing idea

I never understood the craze for "Advent of code". Already at this time of the year the last thing I want to do is code even more.

cool collection