Consider using WebAssembly for the browser implementation

[kripod]

Related article: https://blog.bitjson.com/just-released-webassembly-version-of-secp256k1-10x-faster-than-javascript-eb3cebe4d411

[dcousens]

@kripod what is the route for detecting support for that?

[kripod]

@dcousens It isn’t trivial, but I found the following answer on StackOverflow: https://stackoverflow.com/a/47880734

[dcousens]

@bitjson do you encourage users to compile their own WASM? What is the release process for inclusion in a library like this (or others).

[fanatid]

I had seen this article yesterday, performance make impression.
Not sure what we should do here, I'd like that users compiled WASM themselves (on same reason why I removed prebuild bindings). Also looks like we need elliptic in any case, because sometimes WASM can be not supported by old browsers.

[bitjson]

@dcousens I don't think it's particularly necessary for users to compile their own. If users are already trusting the javascript they're getting from NPM, they might as well trust the WebAssembly too. If not, users should audit both themselves, and part of doing that would be to run the WASM compilation step (or check that entities they trust have signed it). Not a new problem in the Node.js space though.

For now, I've opted to avoid even PGP signing anything, since I'd rather people not trust me at all. (In the future, I'm hoping to use something more definitive than PGP, like BitAuth, then I might start signing things. 😄)

[fanatid]

WebAssembly + n-api addon in fanatid/fcrypto