Convert callbacks to trait references

[dhuseby]

The open operation in the bs crate has a function called open_plog that takes two callback functions. I think the more idiomatic way to implement this is to pass in a reference to a trait impl. The current code looks like this:

pub fn open_plog<F1, F2>(config: Config, get_key: F1, sign_entry: F2) -> Result<Log, Error>
where
    F1: Fn(&Key, Codec, usize, usize) -> Result<Multikey, Error>,
    F2: Fn(&Multikey, &[u8]) -> Result<Multisig, Error>,
{
    // ...
}

I think the more idiomatic way is to define a traits and then pass in references to implementations of those traits:

pub fn open_plog(config: Config, get_key: &impl KeyLoader, signer: &impl Signer) -> Result<Log, Error> {
    // ...
}

The update operation in the bs crate has the same callbacks and should be updated as well.

[DougAnderson444]

In the bestsign fork for this, I combined them together:

https://github.com/DougAnderson444/bestsign/blob/706439ba22e04ff1ff6f2c2094dd3b4a481f1cf2/crates/core/src/ops/open.rs#L21

use super::traits::CryptoManager;

pub fn create(config: &Config, key_manager: &mut impl CryptoManager) -> Result<Log, crate::Error> {

//...

/// Users implement this trait to provide the keys for the log
pub trait CryptoManager {
    /// Get a mulitkey for the requested [Key] path.
    ///
    /// with the given parameters based on the user's preference for
    /// key generation (new random, from seed, etc.).
    ///
    /// Mutable self is passed such that the implementation can
    /// update internal state if necessary.
    fn get_mk(
        &mut self,
        key: &Key,
        codec: Codec,
        start: usize,
        end: usize,
    ) -> Result<Multikey, Error>;

    /// Generates proof for this key, such as a signature, over the data.
    fn prove(&self, mk: &Multikey, data: &[u8]) -> Result<Multisig, Error>;
}

[dhuseby]

You're maintaining a fork with a naming collision? Is there a way we can work together on this? Are you going to upstream your changes? I know that you've done this on a few things but I really don't want to go to market with two, mostly the same and similarly named products.

[dhuseby]

I'd love to get a patch for this. I like your design.

[DougAnderson444]

You're maintaining a fork

I really don't want but was necessary at the time to make some mods

Is there a way we can work together on this? Are you going to upstream your changes?

Yes and yes, with the monorepo up and running now this may be feasible.

[dhuseby]

Yes and yes, with the monorepo up and running now this may be feasible.

Excellent. Let me know how I can help get your code upstreamed.