What hashing functions should we support when verifying CIDs

[olizilla]

We introduced early checking of CAR files block bytes against their CIDs in https://github.com/web3-storage/web3.storage/pull/1069 for sha2-256 only. This is the default hashing function used in ipfs add. If any other hashing function is used we won't verify the blocks up front, we'll let the IPFS nodes in the cluster figure it out later... which isn't a great UX for a user, who would like to know as early as possible if we think the upload is malformed.

Instinctively we might say "let's support all the hashing functions!!!" which is reasonable, but we need to keep an eye the bundlesize as we can't deploy more than a 1Mb worker to Cloudflare. And we need to keep an eye on the throughput, if an esoteric hashing fn has is resource intensive to calculate we might see very slow uploads for those CARs. It's notable that sha2 is "built in" to subtle.crypto while other hashing fns will need us to bundle a wasm or js impl.

[olizilla]

Out of the box, js-ipfs ships sha2-256 and sha2-512 as far as I can tell... others would have to be configured

js-IPFS ships with all multihashes exported by js-multiformats, including sha2-256 and others. Additional hashers can be configured using the hashers config property. – https://github.com/ipfs/js-ipfs/blob/9a40109632e5b4837eb77a2f57dbc77fbf1fe099/docs/IPLD.md#bundled-multihashes

https://github.com/ipfs/js-ipfs/blob/709831f61a822d28a6b8e4d6ddc2b659a836079f/packages/ipfs-core/src/components/index.js#L11

hashes https://github.com/multiformats/js-multiformats/blob/a1b38c235809287e284c7bde80634e669e6d1ac6/src/basics.js#L21

https://github.com/multiformats/js-multiformats/blob/master/src/hashes/sha2-browser.js

https://github.com/ipfs/js-ipfs/blob/709831f61a822d28a6b8e4d6ddc2b659a836079f/packages/ipfs-core/src/components/index.js#L87-L94