-
Notifications
You must be signed in to change notification settings - Fork 24
Why the requirement on webcrypto? #22
Comments
If you want to do that, you can shim the global object appropriately. But we don't want to include these shims as they increase the bundle size very considerably. |
Ok true, why not use js libraries for hash functions though? Is the performance improvement worth the loss in browser support? |
The combination of size increase + performance was worth for us yes. The majority of js-ipfs in the browser relies on webrtc to do real peer to peer connections in the browser, which restricts us to new browsers already in a lot of use cases. But it would be great to have a shim that one could just include in older browsers to offer support there. It shouldn't be too hard to implement one that just takes the js based implementations and emulates the same api. |
Almost 10x perf improv. It is definitely valuable to have a way to use JS crypto libraries instead of WebCrypto, happy to accept a PR that brings that in. |
I have my own fork which uses the native-crypto package, which will use webcrypto when available and js libraries elsewhere. It might be overkill for this though, as we only use hashing functions. https://github.com/duomarket/js-multihashing-async Note this fork uses a native-crypto global when available, it's not a dependency, this is because in my use case native crypto is imported by a different browserify bundle. |
FYSA WebCrypto in Chrome is available only in secure contexts and Firefox is also planning to introduce the same restriction. We should provide a better error message to address errors caused by insecure origin (PR #30). |
old issue gonna close this, feel free to reopen |
It would be fairly simple to import native-crypto or a similar library that falls back on js libraries for crypto in the absence of webcrypto; in the meantime, js-ipfs doesn't work in a webworker in safari, and in other bad browsers.
The text was updated successfully, but these errors were encountered: