Look into WASM support

[TimoGlastra]

Would it be feasible to create a WASM layer, like the FFI layer, so we can use anoncreds-rs in the browser and possibly easier in Node.js.

We could use something like wasm bindgen for the bindings and wasm-pack for packaging the module, fully typed.

this might, still unsure, make it possible the same anoncreds implementation in AFJ for the browser and Node.js.

The biggest blocker here is ursa compilation for WASM. I have taken a look at this myself, a while ago, and did not get it to work. @whalelephant did get some parts to work so we might be able, with some work, to get it working.

Related Ursa work: https://github.com/blu3beri/ursa/tree/wasm

[whalelephant]

hey that would be awesome to run it in the browser!

Yes, I made the verifier mod compile to WASM (only the verifier - due to the requirement onchain no randomness) by introducing a onchain feature.
It did not have the JS binding.

As @andrewwhitehead mentioned before, the dependency amcl repository is no long available.
The one I used have also very recently been made as archive.
Looking at the discord under Ursa, looks like some restructuring is happening. Perhaps @swcurran might have some insight as to how to proceed?

@blu3beri I cannot seem to access your branch.

[berendsliedrecht]

Looking at the discord under Ursa, looks like some restructuring is happening. Perhaps @swcurran might have some insight as to how to proceed?

I believe there is ongoing work for this yes with the main goal of creating a 1.0.0 release.

@blu3beri I cannot seem to access your branch.

Yes, I deleted it as it's merged into main :)

Re the AMCL part, I am not sure what we have to do there but that is more of a problem in general and not related to wasm, right?

[berendsliedrecht]

I actually got anoncreds compiled for WASM. Not too sure on the exact things I did anymore but I sure I could reproduce it again.

@TimoGlastra wasm might also be a good replacement for the ffi-napi issues we ran into. Instead of changing to a node addon, wasm makes a lot more sense.

[genaris]

@TimoGlastra wasm might also be a good replacement for the ffi-napi issues we ran into. Instead of changing to a node addon, wasm makes a lot more sense.

I think it's a great idea! It would certainly save development time. Not sure if there is any drawback compared to the more 'classical' approach (remember, ref-napi looked promising and...) but given that the work should be done for browser case anyway, I think it's worth a try.

[berendsliedrecht]

@TimoGlastra wasm might also be a good replacement for the ffi-napi issues we ran into. Instead of changing to a node addon, wasm makes a lot more sense.

I think it's a great idea! It would certainly save development time. Not sure if there is any drawback compared to the more 'classical' approach (remember, ref-napi looked promising and...) but given that the work should be done for browser case anyway, I think it's worth a try.

The issue with ref-napi, is that it has been unmaintained for 2 years already (when it was chosen, more than a year ago now I believe, it wasn't obvious yet).

WASM has ever growing support and theoretically it is possible to use WASM in React Native. As long as wasm-pack/wasm-bindgen keep support, which I am very sure of, I think it is the correct way to move forward.

The drawback is of course that we need to maintain an FFI layer for React Native, and all the other wrappers and now another layer for WASM.

[berendsliedrecht]

https://github.com/blu3beri/anoncreds-rs/tree/wasm this version is compilable to wasm.

Since crates.io does not support git dependencies, we would likely have to wait for Ursa 1.0, but work can, in theory, already get started.

One thing that is still open is dealing with the anoncreds object handles as this is only implemented for FFI. We might be able to just omit them and pass structures in for everything instead of the handle.

[whalelephant]

Re the AMCL part, I am not sure what we have to do there but that is more of a problem in general and not related to wasm, right?

Yes, I was just pointing it out because for my case I had to fork it to remove any rand dependencies for onchain operations and I wasn't sure if it would compile without but your branch shows it is compatible.

[andrewwhitehead]

It would be nice if we could use something like uniffi or Diplomat to target both WASM and reactive-native (and maybe get rid of some boilerplate in Python), but I'm not sure that either would be a drop in replacement at the moment.