Comment by greatgib
16 hours ago
Libsodium’s goal was to expose APIs to perform operations, not low-level functions. Users shouldn’t even have to know or care about what algorithms are used internally. This is how I’ve always viewed libsodium.
...
Over the years, people started using these low-level functions directly. Libsodium started to be used as a toolkit of algorithms and low-level primitives.
That is interesting to see the common fallacy of what we think users want versus what they really want.
The important point is to be able to recognize that and not coerce users into using your project only how you envisioned it and only like that. Some projects are failure on that count having switched on dictatorial direction on that aspect.
>That is interesting to see the common fallacy of what we think users want versus what they really want.
Or a fallacy of what users think they want versus what they really want.
Non-cryptographers shouldn't use cryptographic primitives directly in security critical coffee paths. Libsodium tried to protect users from themselves in that regard. I think that's a worthy goal - library should try to make it impossible to use it incorrectly, which means high level primitives.
See also one of my favorite cryptographic essays, "If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong" https://people.eecs.berkeley.edu/~daw/teaching/cs261-f12/mis...
I wrote a C++ implementation of the Framework for Integrated Test (FIT) called CeeFIT, and I was really proud of the way it registered fixtures at compile time.
Anyhow, I was surprised that more than one user was using CeeFIT as a sort of batch runner for C++ code, feeding in rows tabular data and executing it against their code. There were a couple bugs I had to fix to support their use cases.
I was just happy to have users.
Some of the most successful products were originally intended for a completely different use case. R7 rockets, Viagra, Hugging Face. The ability to pivot - and to recognize when to pivot - is what makes or breaks.
[flagged]
> The important point is to be able to recognize that and not coerce users into using your project only how you envisioned it and only like that. Some projects are failure on that count having switched on dictatorial direction on that aspect.
There is certainly a balance there. If every function inside your code is now considered part of your API contract, almost anything is a breaking change and you can basically forget about ever meaningfully refactoring that codebase.
Many times making things private or marking them as internal-only is the right call.
I'm not really intimate enough with libsodium to judge if they made the right cut there or not in hindsight.
> and you can basically forget about ever meaningfully refactoring that codebase.
Ummm why? Breaking changes aren't the end of the world? Deprecate and communicate clearly and people are usually fine with them (if it's meaningful progress instead of churn).
They are. Every breaking change is a pain point for your users/customers. Every time they have to do something to work around your breaking change, it's an opportunity to reconsider whether they need you or whether using your product is worth the trouble.
1 reply →