Non-additive feature flags are problematic about curv

[omershlo]

Enabling only a single curve is by design. No cryptographic system should use multiple curves simultaneously.
About the aliases: maybe, I think it's a matter of personal taste :)

[djc]

There is an established idiom for naming things in Rust libraries, though:

https://rust-lang-nursery.github.io/api-guidelines/naming.html

IMO following that consistently should generally be preferred over personal taste (though obviously there are backwards compatibility concerns at this stage).

[omershlo]

I think that because of the backwards compatibility issue it will not be possible to change it now. But we should definitely follow the established idiom . Thanks!

[omershlo]

having said that - I would love to see an additive feature version of Curv library. It would be really interesting and useful (we get this request a lot)

[djc]

One version to do this would be to split this repository into five separate crates, one per curve + one base crate that only holds the common traits. This would make things more obvious. Then you could keep the shared curv crate as a high-level interface that depends on all of these others.

Still, this adds quite a bit of extra complexity. IMO it would be better to bite the bullet and simply stop providing the top-level types. With some reorganization, this means that dependencies add an extra path component to their imports (use curv::GE -> use curv::secp256k1::GE).

[omershlo]

cc: @oleiba exactly what we have talking about.
Another bonus is that we will be able to put some of the crates at crates.io

[oleiba]

We worked around this issue, by having the depending library to use curv of different tag, and if needed a different package alias in Cargo.toml.

For example, we have https://github.com/KZen-networks/gotham-city which depends both on https://github.com/KZen-networks/curv directly with feature ec_secp256k1, and on https://github.com/KZen-networks/multi-party-eddsa which depends on curv with feature ec_ed25519.

So we added an additional tag on curv e.g. v0.2.0-ed25519 (on the same commit as v0.2.0), and https://github.com/KZen-networks/multi-party-eddsa uses this tag with feature ed_25519. That way https://github.com/KZen-networks/gotham-city does not break and is able to import both features of curv.

[djc]

So if you use that as a backwards compatibility shim for now, then it should also be fine to change things to not have the top-level exports in a 0.3 release?

[oleiba]

Yes, we now follow semver semantics so you can break backwards compatibility and update the version accordingly, e.g. 0.2.0 -> 0.3.0.