tweetnacl-js VS Ed25519Tool

This is great, finding NaCl (libsodium) has been a godsend, specifically the JS lib.

1 - https://nacl.cr.yp.to/

2 - https://github.com/dchest/tweetnacl-js

On cryptography, our whitepaper shares information on the general cryptography choices - login, authentication, keypairs, etc. It's quite similar to password managers or encrypted communication apps. In the actual product (code here https://github.com/skiff-org/skiff-mail), we use the library TweetNaCl (https://github.com/dchest/tweetnacl-js) which is designed to be fast, trustworthy, and performant

Working with encryption more broadly will equip you to understand the fundamentals that underpin the web3/crypto world: hashes, asymmetric crypto, signatures, signature chains, etc. And it also has many uses, of course, outside the web3 realm.

If you're working with Node, tweetnacl.js (https://github.com/dchest/tweetnacl-js) gives you secure defaults and a nice API to start learning and building with.

Once you're familiar with this stuff, blockchains/cryptocurrency/web3 loses a lot of its mystery. They're essentially all just different takes on using key management and signature chains to verify identities and

Those things are not the same. With the Berne Convention Implementation Act of 1988 (and the earlier Copyright Act of 1976, which went into effect in 1978), all works were by default copyright protected. In the absence of a legal notice, nobody can reliably use this for anything at all. Most jurisdictions don't even have a way of reliably dedicating anything to the public domain, hence the existence of permissive licenses. Please at least consider adding the ISC or MIT or Unlicense text or similar to a LICENSE or NOTICE file in your repository. An example: https://github.com/dchest/tweetnacl-js/blob/master/LICENSE

I'm concerned about the `#` character in the URL.

# means fragment and that's kept local and not sent to the server unless client side Javascript sends it to the server. I would use an identifier that doesn't already mean something to the URL.

See https://github.com/Cyphrme/URLFormJS#query-parameters-fragme... (Also see https://github.com/Cyphrme/Path)

For an example where this is relevant: https://cyphr.me/ed25519_tool/ed.html#?msg_encoding=Text&msg...

And see https://www.rfc-editor.org/rfc/rfc3986#section-3.5

For browsers this problem is partially solved as subresources may be integrity checked. Further, there have been proposals like DOMTegrity, that provides a complete solution. For now, yes, full integrity checking isn't done automatically in browser, but it may be done automatically using git or manually as is normally done for any software downloaded not using a package manager or git.

The only reason the evil tool is now the second result is because this backdoor angered me so much I created the (now) #1 tool, that runs in browser, never sends off keys, and is fully open source. Feel free to click on that one all you want and star it on Github. Just practicing, "cypherpunks write code". 😉

git clone https://github.com/Cyphrme/ed25519_applet.git