WIP: expose a JS api through WASM.

[fabricedesre]

[fabricedesre]

This leaves open the question of JS-exposing the rest of the API. KeyMaterial is a good start, but we also need to provide:

* `UcanBuilder`

I started on that one, will post my hack soon. Warning: wasm-bindgen and lifetimes are not the best friends :)

* `DidParser` (keeping in mind implications of #3 & #16)

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.

* `ProofChain`

You scare me.

* Some coherent notion of expressing capabilities; this may just be a POJO/JSON API on the JS side

Right, I'm not sure either how deep in the strongly typed side we need/want to go for that.

  * 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

Indeed...

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.

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.