search

haskoin / secp256k1-haskell

Haskell bindings for secp256k1 library
Other
24 stars 36 forks source link

Reorganize the repo to have multiple packages, and add optional features as separate packages #43

Open evgeny-osipenko opened 1 year ago

evgeny-osipenko commented 1 year ago

@jprupp You seem to be the current maintainer of this repo. :)

This is mostly related to the recoverable signature support in #42

As I can see it, the main problem behind the recovery, ECDH and some other features, is that they can be disabled at the native library's compilations stage, and if the resulting .so lacks a feature that the Haskell binding requests in a foreign import, that causes a build failure on the Haskell side. In the past, this was dealt with by guarding the optional features behind Cabal flags and -XCPP, but then that was removed, I presume, due to unwieldiness of these flags.

I think, as an alternative solution, we can split the Haskell bindings into multiple separate packages, e.g. keep the unconditionally available functions in secp256k1-haskell, and move others into secp256k1-haskell-recovery, secp256k1-haskell-ecdh etc. A downstream dependency could then list its requirements as a plain list of libraries. For example, the EIP-712 library that I'm currently working on would simply list secp256k1-haskell-recovery in its dependencies, as the recoverable signatures are an integral part of the EIP-712 protocol.

Then, when building the final application on the target machine, only the features that are actually used would be required from the user-side libsecp256k1.so. If the feature is absent, it would still trigger a build failure, but now it's more justified — if there's no support for the recoverable signatures on the target machine, then it's simply impossible to implement EIP-712 and run dependent programs, sans re-implementing the cryptography from scratch in pure Haskell.

As all of these libraries are still logically parts of a single entity (haskell bindings to a native lib), it would still make sense to keep them in a single repository (like servant, for example).

So, the main question is: I can re-organize this repo in this manner and move the recovery support in #42 into a separate package, but I don't know if that's actually a direction that this project wants to move in. Should I go ahead and make a PR to turn this into a multi-package repository? What do you think?

ysangkok commented 1 year ago

It sounds good to me. Another option would be to just vendor the library as cbits and stop relying on system libraries.

evgeny-osipenko commented 1 year ago

Making your own library in cbits (or in pure hs, for that matter) goes against the principle of not rolling out your own crypto, so I would rather avoid this scenario.

ysangkok commented 1 year ago

No, I am talking about copying in the actual libsecp256k1 library. I am not talking about writing new cryptography code. For example, see cmark-gfm-hs.

evgeny-osipenko commented 1 year ago

What is the status on this proposal? Are there any updates from the maintainers?