Dropping TweetNaCl

[christianbundy]

Issues like #3 make me wonder whether this module would be better as a wrapper around sodium-chloride and sodium-universal, dropping support for TweetNaCl entirely. Trying to bridge two disparate APIs into a consistent interface is hard work, and unless we feel very strongly about TweetNaCl vs Sodium-JavaScript I think this might be the right move.

[christianbundy]

I didn't realize that we actually have at least three providers:

• Browser:
  • Big: libsodium-wrappers (emscripten)
  • Small: TweetNaCl
• Node.js: Sodium-Native

I took the various chloride-* modules and pulled their histories together to create one (much smaller) repository that uses Sodium-Universal, but unfortunately there are a few functions missing. More info here: https://github.com/sodium-friends/sodium-javascript/issues/19

---

Here's my branch: https://github.com/christianbundy/chloride/tree/sodium-universal

---

Compatibility:

• [x] crypto_sign_PUBLICKEYBYTES
• [x] crypto_sign_SECRETKEYBYTES
• [x] crypto_sign_seed_keypair
• [x] crypto_sign_keypair
• [x] crypto_sign_BYTES
• [x] crypto_sign
• [x] crypto_sign_open
• [x] crypto_sign_detached
• [x] crypto_sign_verify_detached
• [x] crypto_box_PUBLICKEYBYTES
• [x] crypto_box_SECRETKEYBYTES
• [x] crypto_box_seed_keypair
• [x] crypto_box_keypair
• [x] crypto_box_MACBYTES
• [x] crypto_box_easy
• [x] crypto_box_open_easy
• [x] crypto_secretbox_easy
• [x] crypto_secretbox_open_easy
• [x] crypto_auth_BYTES
• [x] crypto_auth
• [x] crypto_auth_verify
• [x] crypto_hash_BYTES
• [x] crypto_hash
• [x] crypto_hash_sha256_BYTES
• [x] crypto_hash_sha256
• [x] crypto_scalarmult_BYTES
• [x] crypto_box_PUBLICKEYBYTES
• [x] crypto_sign_ed25519_pk_to_curve25519
• [x] crypto_box_SECRETKEYBYTES
• [x] randombytes_buf

[staltz]

@arj03 What are you relying on in the SSB browser demo?

[arj03]

Browser core is very dependant on sodium-browserify to have web assembly working. JS is insanely slow compared to web assembly. So I don't really care about tweetnacl. I would actually like to get rid of tweetnacl as that makes the bundle smaller. So big +1 from me :-) Great work @christianbundy.

And thanks for the ping @staltz I didn't have notifications turned on for this repo until now.

[christianbundy]

Sweet. I'm curious to benchmark libsodium-wrappers (emscripten) vs sodium-javascript (handwritten) once all of the methods are ported. If we can just depend on sodium-universal that'd remove lots of complexity from this module and consolidate our libsodium dependencies to the sodium-friends org.

[christianbundy]

I ran sodiumperf against libsodium-wrappers and sodium-javascript and it looks like this might actually give us a nice performance boost:

• libsodium-wrappers.txt
• sodium-javascript.txt

(This assumes that my PRs into sodium-javascript are merged, and currently leaves out crypto_sign_ed25519_pk_to_curve25519 because I've only written tests, not the implementation.)

[mixmix]

Have read this, but haven't got super familiar with details. Please tag me if you need my attention on this.

FWIW I'm mainly using graphql to connect from browser to back end, so don't use eg ssb-client which needs this much. Happy to trust your expertise

[christianbundy]

:tada:

All of our required functionality has been released in Sodium-Javascript!