Determine the use-case for a JS-packaged rs-ucan

[cdata]

We need to determine the scope and use-case for wielding WASM-targeted rs-ucan from JavaScript. Please share your use-case for a JS-packaged rs-ucan in this issue.

In #17 , we have seen the first pass at making WASM-targeted rs-ucan legible to JavaScript. The use case of wielding rs-ucan from JavaScript has always been in-scope for this project, but the plan for how to do it has been vaguely defined.

There are many technical and logistical details to consider for this endeavor. JS packaging is a complex topic on its own, and when we add the detail that there is a Rust-compiled WASM module in the mix, we get an additional layer of complexity.

With infinite time and attention we could address many different use cases. However, in the interest of being somewhat tactical, let's figure out how folks would actually like to use such a package in practice. What is your use case for a JS-packaged rs-ucan?

Please note: it is a non-goal to decide specific tools and/or API designs in resolving this issue (although feel free to hypothesize about such things). We should strive to figure out how folks want to use the package in order to know what to build to support them, and that can guide our tooling / API choices.

[cdata]

@matheus23 @dholms @fabricedesre @expede @bmann @hugomrdias CC'ing you all since you were either participating or mentioned during relevant Discord discussions.

[cdata]

Some things to consider:

• The JS package use case is currently served by the actively maintained project https://github.com/ucan-wg/ts-ucan
• Fission is working on a Webnative SDK in Rust
  • They will expose rs-ucan in user-facing API in this Rust SDK
  • The SDK will also be offered as a JS package

[matheus23]

The JS package use case is currently served by the actively maintained project https://github.com/ucan-wg/ts-ucan

At the moment ts-ucan should cover UCAN use cases from JS/TS.

That said, @fabricedesre mentioned he really didn't like dealing with bundlers & packaging, which was a point in favor of js-bound rs-ucan.

• Fission is working on a Webnative SDK in Rust
  • They will expose rs-ucan in user-facing API in this Rust SDK
  • The SDK will also be offered as a JS package

Yeah. And once we're getting to that, we'll possibly only need rs-ucan to have a rust API and provide webnative "tailored" JS API. I'm not sure whether it's possible to share JS bindings across rust projects? I'm guessing that'd be possible, and that'd probably be useful for us? But it's all still unclear. We don't really know what exactly that'll look like, and we'll need a bit until we'll get to that.

[bgins]

One use case for a JS-packaged version is for the validator in the UCAN Community website: https://ucan.xyz/validator/

The validator does the following:

• Decodes from a token
• Checks that a UCAN is not too early or expired
• Checks for a valid signature
• Checks that proofs are valid and prove what is claimed

The validator currently uses ts-ucan and works with 0.8.x UCANs.

We want to use the validator as a test case for using rs-ucan in a web app. It won't be the most complete test case because it doesn't need to generate any UCANs, but it could be a good first step because it is less complicated than other use cases (no need for key support or signing).

We have an issue in the community website repo: ucan-wg/ucan-community-web#52

---

Would it be alright if I made an attempt to add JS packaging support? Perhaps I could start by adding verification methods only?

I saw in #17 there was a discussion around using the Rapier approach to packaging. I'd be happy to replicate their approach for rs-ucan.