Ideas for next major update

[paulmillr]

• Remove cryptoNode import! Requires to ditch support for nodejs v18 (EOL 30 Apr 2025)
• Remove import maps. Change @noble/hashes/sha3 to @noble/hashes/sha3.js
  • Import maps are not browser-friendly etc
  • Before doing this, actually test in real browser
• Test in different environments:
  • bundler-less browser
  • deno
  • bun
• See how package can fit for JSR.io
• Rename / refactor
  • crypto / cryptoNode => webcrypto (to match noble-ciphers)
  • sha256, sha512 => sha2? not sure yet
  • blake2b, blake2s, blake3 => blake?
  • ripemd160 => ripemd?
  • sha1 => legacy? and add md5??

Maybe also:

• Make package ESM-only
• Re-audit (need $ funds)

[imcotton]

Any thoughts on adding non-cryptographic hashes? e.g.:

• CRC32
• Murmur3
• xxHash
• City
• etc...

[paulmillr]

What would be the use case?

[imcotton]

In general non-cryptographic hashes give synchronize call which widely applicable.

CRC32 is good for quick integrity check.

Both Murmur3 and xxHash commonly used in Bloom Filter, however existing widely used NPM packages all using old syntax (ES5, CJS) and have no updates in 5-6 years.

In case of Murmur3, rarely handle utf8 correctly¹. Jumping rabbit hole forks lead to inactive non-resolved issue²

Footnotes

1. https://github.com/cimi/murmurhash3js-revisited ↩

2. https://github.com/karanlyons/murmurHash3.js/issues/13 ↩

[wasd171]

Would be great to have a properly supported murmur3 hash for Kafka-like projects!

[imcotton]

Btw, I'm currently settle on fnv1a as alternative to Murmur3, changeable via:

• npm:@sindresorhus/fnv1a
• jsr:@std/crypto crypto.subtle.digestSync('FNV32A')

[paulmillr]

Quote from contributor about ESM transition:

---

Got it, thank you for explaining the rationale! Might be worth considering that extended support for Node.js v18 will be provided for users of among others:

• Debian bookworm (EOL 2028-06)
• Ubuntu 24.04 LTS (Standard Support ends 2029-04; Legacy Support ends 2036-04)
  • For illustration, they still do provide extended security maintenance updates for Node.js v4 for 16.04
• Amazon Linux 2023 (Support for nodejs v18 until 2028-08)
• Enterprise Linux (RHEL, SUSE) typically provide extended support as well but I couldn't find up-to-date info on those easily
• Various independent vendors provide OS and container images and deployments with independent maintenance support

So for these users, Node.js v18 will not actually be deprecated during 2025 and some users will expect to keep using their supported runtime versions beyond the upstream maintenance window.

Not meaning to imply that ethereum-cryptography should match all of these (or even strictly needs to consider any of it, though it would be nice¹), just that "when nodejs v18 is deprecated" is not an entirely black-and-white question and hopefully bring some nuance to the ESM-only timeline consideration.

Footnotes

1. If it were me, I think it could be a good target to aim at having if not mainline then at least critical and security-related bugfixes backported to a major version runtime compatible during lifetime of Debian bookworm (2028-06) if not also Standard Support for Ubuntu 24.04 LTS (2029-04). Or if not that, at least until both distros have new stable/LTS versions providing newer Node.js versions (~2026?). This is considering users who are comfortable using the vendor-provided versions but where either nvm, or "compile it from source" are non-starters (for compliance reasons or otherwise). And if we're doing that, I imagine that maintaining two separate build systems will not be worth the headache.... ↩

[mahnunchik]

+1 to add md5 😉

[paulmillr]

md5 is available here: https://gist.github.com/paulmillr/405d7f1efca6e37bee63d6499cd4c8f9