You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
🟡 Same CIDs for the same content vs Lotus different hash functions (see below)
🟡 Different CIDs for the same content vs IPFS (although IPFS still stuck in v0 so we have that problem anyway since we use v1)
🔴 Less de-duping
UPDATE:
Thanks to @vasco we know that blake2js is way slower than sha256. It is not surprising because sha256 uses native webcrypto in the browser and Node.js crypto module. There is an npm module with native bindings for Node.js and a module with a WASM version of blake as well. The work to integrate and test this would be huge and there's no benchmark data for either module so it might not even be faster than the native sha256 versions. Unless there are objections I vote we stick with sha256 hashing for now but switch chunk size and max children.
The text was updated successfully, but these errors were encountered:
We're considering a change to the default chunking parameters that will more closely reflect the defaults chosen by Lotus:
Current IPFS defaults:
262144
174
Lotus defaults:
1048576
1024
Why?
Same CIDs for the same content vs Lotusdifferent hash functions (see below)UPDATE:
Thanks to @vasco we know that blake2js is way slower than sha256. It is not surprising because sha256 uses native webcrypto in the browser and Node.js crypto module. There is an npm module with native bindings for Node.js and a module with a WASM version of blake as well. The work to integrate and test this would be huge and there's no benchmark data for either module so it might not even be faster than the native sha256 versions. Unless there are objections I vote we stick with sha256 hashing for now but switch chunk size and max children.
The text was updated successfully, but these errors were encountered: