Brian Warner

Hm, actually the ownership issues might make the second approach hard to implement for API-layer authors. They can't really provide a distinct InputHelper object because it needs to interact with...

I talked with @alex at pycon today, and we decided that a "1+2" API is probably be best way forward. The main API entry point should take both the normal...

Also, maybe we should have a simpler completion function that combines the namplate and the words. There's an important difference between the two (you can't query for words until you've...

WASM is great. Yeah, maybe we write the "wormhole core" approach (in #1) in a way that can be compiled to wasm, and then the IO wrapper gets written in...

Mind you, the amount of JS you'd need to write for the platform-specific IO layer might be considerable..

Does this require `nostd`? Or providing a memory allocator of some sort?

I started experimenting with this over the weekend. Two stumbling blocks I've hit so far: * we use `sodiumoxide`, and of course that must compile a large C library, which...

Once we get the core library compiling to WASM, the next step is to write JS glue code to satisfy its IO needs. The core is written as a function...

Ok the second problem will be solved by an upcoming release of `curve25519-dalek` that switches to use `zeroize` instead of `clear_on_drop` (which depends upon `zeroize-1.0` being finalized, but that sounds...

@burdges pointed out that cargo features are additive, so if the glue code declares its own dependency upon `clear_on_drop = { .. features = ["no_cc"] }`, then that'll push the...