Open paulmillr opened 11 months ago
Perhaps out of scope and outside your comfort area, but I wonder if wasm offers any worthy advantage. Might be that the interop cost isn't worth it for like, 512 bits though.
No wasm. Wasm creates opaque binaries that are hard to inspect and may contain malware.
Sorry for going further off-topic, but doesn't that argument also apply to minfied JS? Devs typically inspect source code, not compiled/transpiled output. Also, you don't have to ship opaque binaries - there was some drama recently in the Rust ecosystem when Serde tried to do that.
doesn't that argument also apply to minified JS
yes. also to all build tools. My goal is to provide secure, audited / auditable, small packages. It's up to user to use additional build tools
you don't have to ship opaque binaries
What do you mean? If I publish package with wasm, it would be necessary to include wasm-compiled binaries themselves in the package. That's industry standard. We've (as NPM community) moved away from building packages on user machines because node-gyp shown that it's too unreliable.
Ah derp you're right. I got lost in Rust land for the past few days and lost (or gained) some brain cells.
Now that I think about it... its kinda insane that NPM ships opaque binaries.
Javascript.
Sad!
are there any published benchmarks for this library? Looking for something like this https://www.xaymar.com/articles/2020/12/08/fastest-uint8array-to-hex-string-conversion-in-javascript/
npm run bench
If your app has is bottlenecked because of scure-base, write a comment here.
The current architecture is cool and readable, but not the fastest one. For example,
hex.decode
is slower than in noble-hashes / noble-curves. hex decoding is not used anywhere here, but it is used in scure-btc-signer. base64 is also a bit slow, but so far has not been a bottleneck.