crypto
stringref
crypto | stringref | |
---|---|---|
3 | 2 | |
25 | 34 | |
- | - | |
7.2 | 0.0 | |
6 months ago | about 1 year ago | |
TypeScript | WebAssembly | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
crypto
- Typescript/WASM library with cryptographic operations based on libsodium, Shamir secret sharing, Merkle trees. Runs on Nodejs and the browser. Feedback is encouraged!
-
The Risks of WebAssembly
From my recent experience with WebAssembly developing a cryptographic library for Nodejs and the browser [1], I have to say that once someone needs to use memory allocation, typed arrays from JS to WASM (I did not manage to make the opposite work) etc. it quickly becomes obvious that there is lack of documentation and build system fragmentation that only hurts community growth IMO. If I was less motivated to finish the undertaking, I would just give up and go with libsodium-wrappers or tweetnacljs.
I started with clang targeting wasm32-unknown-unknown-wasm as my build system but this just did not work with malloc/free, unless I was targeting WASI, but if I targeted WASI I would not be able to run the module in the browser except with a polyfill that was hard to set up with C/TS stack. I ended up with emscripten because it was importing the module with all the right helper functions but there I was getting memory errors on debug mode but not in production. I needed to pass the Uint8Arrays from JS to WASM in a very specific way (with HEAP8), otherwise the pointers were not working properly, but I was not able to find this in the documentation. I only found out from a stackoverflow comment somewhere after two weeks of brain melting (why would Uint8Array(memory.buffer, offset, len).byteOffset not work?).
After I compiled the project successfully and the JS was giving the correct results, I decided to compile with -s SINGLE_FILE command in order to make the package as portable as possible, but this increased the size significantly because it translates the bytes into base64 that are then converted into WASM module from JS. A package manager of a compiled language that outputs cross-env JS that solves these problems automagically would be, IMO again, a game changer for the ecosystem. I believe this is what AssemblyScript tries to achieve but I honestly could not make it work for my project after experimenting with it for one or two days.
I get that a lot of the problems come from the incompatibility of browser and Nodejs APIs and different agendas from the various stakeholders, but I would very much like to see these differences be reconciled so that we can have a good developer experience for cross-platform WASM modules, which will lead to more high-performance components for JS, which is a programming language that affects so many people.
[1] https://github.com/deliberative/crypto
- Show HN: WASM/TS library for Ed25519, Shamir secret sharing, AEAD secret boxes
stringref
-
Extism Makes WebAssembly Easy
The idea of Wasm as a universal plugin system is very promising. But string passing is maybe not the best example to highlight, considering that Wasm is introducing stringref to enable zero-copy string sharing between the Wasm runtime and host language.
https://github.com/WebAssembly/stringref/blob/main/proposals...
-
The Risks of WebAssembly
> dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith
I certainly disagree with that take. I only see one person being frustrated because his concerns were being thrown under the rug as "non important", I would recommend you to read on dcode's blog to learn more about how the timeline happened [1]. There are always things to improve regarding how we communicate, of course, but those should not be used as a weapon to attack or dismiss someone but as means to improve.
It's also important to note that a few months after, the Wasm committee realized of the mistake and actually tried to solve it with the Wasm Stringref proposal [2].
The issue is not about if using UTF-8 or UTF-16 is the way to go, but how disagreement is being handled in what's supposed to be an open community
[1] https://dcode.io/#webassembly
[2] https://github.com/WebAssembly/stringref
What are some alternatives?
rawr-x3dh - TypeScript Implementation of X3DH
modsurfer - Devtools to validate, audit and investigate WebAssembly binaries.
e2esdk - SDK to build end-to-end encrypted web applications
js-string-builtins - JS String Builtins
json-hash - JCS (JSON Canonicalization Scheme), JSON digests, and JSON Merkle hashes
component-sandbox-demo
component-model - Repository for design and specification of the Component Model
memory-control - A proposal to introduce finer grained control of WebAssembly memory.
awesome-wasm-runtimes - A list of webassemby runtimes
AnswerOverflow - Indexing Discord Help Channel Questions into Google
jco - JavaScript tooling for working with WebAssembly Components
wit-bindgen - A language binding generator for WebAssembly interface types