Paul Miller

The pure results on M1 are as such: ``` generatePrivateKey() x 265,957 ops/sec @ 3μs/op getPublicKey(generatePrivateKey()) x 6,300 ops/sec @ 158μs/op sign x 4,888 ops/sec @ 204μs/op verify x 950...

yeah, i'm just saying that even without buffers, your abstraction layer may be too thick, because verification is ~1k ops/sec, not ~500, so it's useful to compare those raw results;...

For aes, we're using this approach in EF repo: https://github.com/ethereum/js-ethereum-cryptography/blob/master/src/aes.ts It uses node or web browser native built-ins. I'm sure there is zero need in polyfilling AES when web browsers...

Crypto-browserify is garbage that was last updated in 2017. It's not one dependency - it's at least 12. And I don't think it was thoroughly audited, like our approach.

I would argue against this. This would make key-tree bigger...the use case is not defined/popular enough

i've made it esm-only - lmk if you'll need to bring back common.js

Could you provide more info to us? For ex., package.json and brunch config.

Don't think this is supported right now. For autoprefixer we advice to use `postcss-brunch` — besides stylus-brunch

just use [scure-base](https://github.com/paulmillr/scure-base) which is independently audited, minimal, 0-dep base64 lib.

i’ll probably ask once again: what’s wrong with forum for GitHub projects based on own API — http://ost.io? just hadn’t seen any direct negative responses to that