Should be a trait about rust-multihash

[vmx]

Thanks for the suggestion. I agree that the current API is not as nice as it could be. Though there is a reason why the MultihashDigest is what it is today. I deliberately decided (see #63 (comment) for more information) that I don't want to introduce another trait. I want to have a trait that also works for trait objects. The digest crate has two different traits (Digest and DigestDyn) for that reason. I wanted to get away with only a single one. I prefer APIs where there's only one way of doing things.

Hence I suggest that for libipld, we use the MultihashDigest for now and if it turns out to be used a lot and hence it's unergonomic or if it becomes a performance bottleneck, we can still introduce it then.

[dvc94ch]

but libp2p actually uses it in the same way, so it's costing both libipld and libp2p a heap allocation, for no reason

[vmx]

IIRC, the usage in libp2p needs it to be a trait object. But I'll check again tomorrow.

[dvc94ch]

No it just requires a digest function on code. That can be implemented without boxing it first

[vmx]

Yes, it could be used without a trait. My idea was that custom code tables work with the whole ecosystem. This way every code table would also need to implement a digest() function. That might be OK for libp2p as it probably will never use a custom codec table. Though that's not true for IPLD.

[dvc94ch]

So what we need is a different trait, a Code trait that includes a digest function?

[dvc94ch]

In any case can you merge the cid pr and review the ipld pr? Then we can revisit the issue...