Look into WASM support about anoncreds-rs HOT 8 OPEN

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.

from anoncreds-rs.

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.

from anoncreds-rs.

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?

from anoncreds-rs.

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.

from anoncreds-rs.

@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.

from anoncreds-rs.

@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.

from anoncreds-rs.

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.

from anoncreds-rs.

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.

from anoncreds-rs.