Asynchronous API for WASM

[clehner]

#47 introduces a dependency on async_std, as json-ld's JSON-LD expansion implementation is asynchronous. We keep the existing synchronous API by using block_on internally. But for WASM, block_on does not a return a value, and requires the future to be static, since it uses wasm_bindgen_futures::spawn_local. This is a problem for using #47 with WASM (#52) while keeping ssi's blocking API.

I see the following options to proceed:

• Make block_on/spawn_local work somehow, maybe using global static storage and/or message passing.
• Make json-ld support synchronous expansion.
• Implement synchronous expansion in some limited way instead of using json-ld.
• Require JSON-LD documents to be already expanded for generating/verifying ld-proofs. Add an asynchronous function to perform the expansion.
• Make generate and verify functions asynchronous.

The last option might be the most sensible. I think we want to support asynchronous usage anyway, e.g. to be able to make HTTP requests during expansion and verification.

wasm-bindgen-futures can convert a Rust Future to a JS Promise. So if ssi uses async functions, DIDKit's WASM package should be able to wrap those with Promises.

Non-WASM use of ssi could continue to operate synchronously by using block_on in the application code. I think that would work for the DIDKit CLI and FFIs.
When we start to do actual I/O then we can update the FFIs to integrate with native event loops.

[wyc]

I agree that the last option sounds like a sensible one. Asynchronous usage is definitely a worthy feature to consider supporting, and we can always use asynchronous functions synchronously by blocking as you describe. We could even add custom JavaScript to create synchronous versions of those functions.