WIP: expose a JS api through WASM. #17
Conversation
There was a problem hiding this comment.
This is awesome work. Thank you for cutting through the brush and the bramble to figure out if this API is even feasible on the JS side 🙌
For the practical implementation, I think what I would like to see is a newtype that wraps a KeyMaterial and exposes the Promise-ified version of the interface.
This leaves open the question of JS-exposing the rest of the API. KeyMaterial is a good start, but we also need to provide:
UcanBuilderDidParser(keeping in mind implications of DidParser/BytesToKey API should enable use of other DID methods #3 & Abstract over DIDs with an async verify interface #16)ProofChain- Some coherent notion of expressing capabilities; this may just be a POJO/JSON API on the JS side
- Capability attenuation will be interesting; right now we depend on the Rust type system to make it work, so we need some generalized way to do the same work without making as rigid an assumption about object shape
And finally, I think packaging for JS should be done in a different project root. Absent a better alternative, I would like to take a page out of Rapier's playbook: a separate project root for a thin, ergonomic JavaScript shim over a WASM-targeted rs-ucan (written in TypeScript). My hope is that JS-specific packaging details can be neatly compartmentalized this way.
Thanks again for enduring all of the papercuts @fabricedesre ❤️
ucan-key-support/demo/index.html
Outdated
| let data = new TextEncoder().encode("Hello World!"); | ||
| let signature = await keyMaterial.sign(data); | ||
| try { | ||
| await keyMaterial.verify(data, signature); |
| pub fn wasm_get_did(&self) -> WasmResult<Promise> { | ||
| let me = self.clone(); | ||
|
|
||
| Ok(future_to_promise(async move { |
I started on that one, will post my hack soon. Warning: wasm-bindgen and lifetimes are not the best friends :)
Ok - that's where I think something like wit (https://github.com/bytecodealliance/wit-bindgen) is better since it makes it easy to import interface implementations from JS. I'll give it a try later.
You scare me.
Right, I'm not sure either how deep in the strongly typed side we need/want to go for that.
Indeed...
I agree - it's weird to hook up the wasm builds to ucan-key-support. But I don't expect much difficulty on that side. |
Unfortunately wasm-bindgen can't expose structs with lifetimes, so this commit removes the lifetime on UcanBuilder. This requires an additional Clone bound added to KeyMaterial, breaking non-wasm builds.
No description provided.