Need a better module wrapping

[dchest]

We need something like UMD for module wrapping with these features:

• Global nacl/window.nacl.
• CommonJS:
  • Node.js, with PRNG using require('crypto')
  • Browserify/Webpack using WebCrypto, not require('crypto') emulation (without this workaround).
• AMD
• root object inside the module, which can be null or undefined for Node, window for browsers, self (?) for webworkers in browsers (to fix Way to use nacl in web workers #65)

[jo]

I suggest to use browserify for this:

• Write tweetnacl in pure node
• Use https://github.com/crypto-browserify/randombytes
• browserify nacl-fast.js -s nacl > dist/nacl-fast.js

This solves all the requirements stated above (it also considers self), except AMD support.
Its the route we took successfully with PouchDB.

[dchest]

Thanks, I'll think about it, but I don't want to introduce another build tool just for a few lines of code.

[jo]

I totally understand your objections. Just to add: since here is already a build step (uglifyjs) it does not add more maintenance efford. And browserify has been made exactly for this purpose.

[dchest]

@RainaBatwing do you think it will solve #59?

@jo where can I take a look at what browserify replaces Buffer with? Thanks!

[jo]

https://github.com/feross/buffer

[dchest]

@jo thank you! It's kinda big, but would solve #44, #38, and #59. Unfortunately, it's using MIT license, and I'd like to keep TweetNaCl public domain. Maybe I'll write my own? :-) Does browserify allows custom replacements for Node objects?

[jo]

Yes, I think in package.json you can just point to a file or (a node module):

"browser": {
  "buffer": "./lib/buffer.js"
}

https://github.com/substack/node-browserify#browser-field

Extensive docu can be found in the Browserify Handbook.

[RainaBatwing]

I would like to see this change, but I'd much rather you use the browserify Buffer than invent a new one. MIT license is not a restrictive one, and having more code that can potentially introduce bugs seems antithetical to the spirit of tweetnacl as a small audit-able library.

If there really are users who cannot use MIT-licensed software but can accept third party public domain code, they could open an issue later and we can reconsider then?

[dchest]

Thanks for opinions, everyone. I'm sorry that I'm so picky about this change, but I just can't handle this little fact:

• Buffer.js — 38 KB
• nacl.js — 33 KB

I know, an average image on a website is bigger than that, but still I'd like to avoid including a library for frigging byte arrays that's bigger than the whole project. Especially, since Buffer is here mostly for Node.js, which is better served by a native NaCl.

[alax]

So it seems like the arguments are:

Node Buffers (and browserify shim):

• One code base to audit for buffers
• In theory, better audited since it's more widely used
• More consistent buffer implementations
• Solves a few outlying bugs

TweetNaCl typed arrays:

• Typed arrays are native to the browser
• Small, concise code that should be easy to audit

Personally, I'd say stick with the typed arrays, since it does make more sense in the browser. TweetNaCl is great for the client-side, and if you'd like to run it under Node, that's easily doable even with the typed arrays. But, like @dchest mentioned, under Node you really could just use a library with native NaCl bindings, which would definitely offer better performance, and would probably use buffers as well.

So, +1 for the current implementation from me. Small and simple on the client-side, but still fairly simple to use on the server-side if necessary.

[dchest]

Another option is to implement both Buffers and typed arrays as @RainaBatwing proposed in #59. If you pass a Buffer to functions, they will return Buffers, if you pass a typed array, they will return typed arrays.

[RainaBatwing]

My interest in using tweetnacl-js is because I'm developing cross platform p2p apps using NW.js and depending on platform-specific code makes software update distribution much more complicated. For my things, there are no clients or servers. I'd like to have just one version which works on every platform, and I'd like all the application specific code to be in javascript, so anyone can take it and alter it easily. I strongly dislike the idea of shipping binary packages, but most users do not have C build tools on their computer.

[tarun1475]

Use react-native-tweetnacl npm package for using tweetnacl in mobile apps.