A flutter/dart wrapper for Aries-vcx

[dinbtechit]

I'm working to create a flutter/dart wrapper for aries-vcx using https://cjycode.com/flutter_rust_bridge/ and looking for some guidance on how to get started.

My plan is to:

1. Generate the flutter/dart code from libvcx using the flutter_rust_bridge:ffi tool
2. And then I was thinking about creating the necessary classes and functions in Dart that will invoke the generated FFI code (api -> libvcx methods) similar to the Java Wrapper.

I would like to get an expert opinion on the above steps. Just to make sure that I am not going in the wrong direction.

I am also trying to understand the difference between aries_vcx vs libvcx - which one should I use for the FFI bindings?

Cheers.

[Patrik-Stas]

Hi @dinbtechit great questions! :-) I'll start with context on libvcx following up your question on discord

I am also trying to understand the difference between aries_vcx vs libvcx - which one should I use for the FFI bindings?

• aries-vcx is the core library meant to be consumed from other Rust libraries or programs, agnostic of FFI

• libvcx is opinionated way of all stuff needed to get FFI working in NodeJS, Java, iOS. It has 2 layers

  • api_handle - this is a layer wrapping aries-vcx APIs where each instance of aries-vcx object is stored in Hashmap mapping u32 "reference" number (handle), to the actual aries-vcx object.
  • api_c - this is layer specifying the FFI API, so other wrappers like nodejs, ios, java wrappers have are bindings to these C interface.

  The entire libvcx structure has been created years ago and for example, adding new functions to C layer is quite cumbersome as currently it's up to the programmer to add function to the FFI layer in libvcx, then match up that function signature in the other language wrappers. There are better approaches these days and in fact, we have recently started work on reconstructing NodeJS FFI approach. Before I try to attempt to answer your question directly, let me illustrate our nodejs approach for inspiration.

  We are planning to create new crate, something like api_libvcx_node, consuming libvcx, but only its api_handles layer. This new crate will basically wrap the existing api_handles API, just add some FFI annotations from napi-rs library to auto-generate C API and even the NodeJS bindings. This will generate all of the stuff currently manually handle in libvcx api_c layer. During this work, we might separate out api_handle and the existing api_c layer into entirely new crates as well (let's call it for now libvcx_api_handle and libvcx_api_c).
  With this approach, we'll maintain the same "style" of API as we have currently, as we'll still be operating on the concept of u32 "handles".

  Now coming back to your question #1, I think there's few approaches you could take

  • generate bindings on top of handles layer (with tool of your preference) - however we probably wouldn't want to pollute api_handles directly with a new code specific to some FFI tools, so then I would advise to adopt same approach like we plan for NodeJS - create new crate, building on top of libvcx's api_handles and put everything neccessary to make flutter_rust_bridge:ffi (or other tool) work to get desired results.
  • alternatively, you could forget about libvcx completely, instead of start on greenfield, build on top of aries_vcx directly and leverage the flutter_rust_bridge:ffi tool here directly - depending on how that tool works, you might appreciate freedom, as opposed to building on top of existing code in libvcx. I don't know about flutter_rust_bridge:ffi, but for example with the napi-rs we were looking at for NodeJS, it's possible to annotate entire Rust structures and afaik can handle freeing the memory as well - while with libvcx, this is something what must be handled manually (you create some object, you get u32 handle to that object, you call methods on this object using the handle, when you are done, you should call FFI function to free this object).

As for the question #2 - that sounds reasonable, ideally you'd want to get at least all of the low level binding stuff auto-generated, or perhaps even classes reflecting Rust structures.

Perhaps @gmulhearn-anonyome might have some more thoughts on this.

[Patrik-Stas]

Hi @dinbtechit libvcx has now been split in 2 modules api_c and api_vcx
https://github.com/hyperledger/aries-vcx/tree/main/libvcx/src

If you want to build flutter wrapper, you can try it on top of the api_vcx layer. For inspiration you can take a look at new node wrapper we are building with napi-rs #665 (not yet merged but mostly done at this point)

As I mentioned, alternative to building a new wrapper on top of libvcx/api_vcx would be building it directly on top of aries_vcx. You need to consider if api_vcx brings you some benefits (freeing memory, accessing objects via numeric references).

[gmulhearn]

Hey, Patrik can probably answer more. But, I'd have a browse thru the current android CI scripts for building for android architectures. It requires having the android binary artifacts ready, and then linking them in (check the flags set in the setup.android.sh script around xmq, openssl and sodium). https://github.com/hyperledger/aries-vcx/tree/main/wrappers/java/ci

You might have to do some of this set up and set some of the env variables as part of your build process as well

[gmulhearn]

Particularly, have a dig around the functions: prepare_dependencies , setup_dependencies_env_vars , and set_env_vars within prepare.android.sh: https://github.com/hyperledger/aries-vcx/blob/main/wrappers/java/ci/setup.android.env.sh

These functions download and set up the flags for locating the external android binary dependencies (e.g. zmq) for each android target architecture.

[mirgee]

@dinbtechit I second @gmulhearn 's suggestion. Since you are cross-compiling for Android on MacOS (M1 or Intel?), you need to make sure you are linking against libraries built for the target architecture - enable cross-compilation (PKG_CONFIG_ALLOW_CROSS=1) and point pkg-config away from the system installation of the libraries to the target libraries (*_LIB_DIR, *_INCLUDE_DIR). Besides looking at the scripts mentioned above, which are the best guide, you can perhaps also try taking a look at the build-napi job in the CI, where we cross-compile for M1 Darwin on Intel Darwin.

[dinbtechit]

@Patrik-Stas / @gmulhearn / @mirgee/ Here is an update on my progress and some of the roadblocks I am currently facing.

Take a look at the code here -> https://github.com/dinbtechit/aries_vcx

Please note: The wrapper is NOT 100% done yet.
Here are some of the todos: (PR's are welcome)

• I still have to expose the APIs.
• Offload the native operations to a separate thread so it does freeze the UI.
• Write test cases
• Write a fully functioning example app.
• (low priority) - Support for Web

Ideally, I would like this wrapper to work for the following Platforms:

Platform	CPU
Android	✅ x84, ✅ x86_64,✅ arm7, ✅ arm64
IOS	⏳ x86_64, ✅ arm64, ❌ arm64-sim
MacOS	✅ x86_64, ✅ arm64
Linux	✅ x86_64, ✅ arm64
Windows	✅ x86_64, ⏳arm64
Web	🚫 wasm (Low priority)

Legend	⏳ - InProgress/Pending	✅ - Builds Successful	❌ - Build Errors	🚫 - Not started

🚧 Roadblocks:

1. I'm currently unable to build this for arm64-sim due to this error [Bug] - Unable to build libzmq for aarch64-apple-ios-sim zeromq/libzmq#4508. If you have any suggestions please do let me know. I would like to get it working on ios arm64 simulators.

2. This is not critical but looks like libsodium-sys = "0.0.16" seems super outdated this does not support vendored feature which is preventing me from cross-build the project on my Mac M1. It would be nice if we can upgrade this to the latest so we could do something similar to openssl and zmq-sys as shown below.

   cargo.toml

   openssl = { version = "0.10", features = ["vendored"] }
   zmq-sys = { version = "*" , features = ["vendored"] }

[dinbtechit]

@Patrik-Stas / @gmulhearn / @mirgee -
I am running into a weird issue with libindy_vdr crate, I am not able to cross-compile for x86_64-apple-ios target on M1 mac. For some reasons, it fails to find the x86_64 symbols for libindy_vdr.

There is more information in this github issue - dinbtechit/aries_vcx#5.

Strangely it happens only when cross-compiling for x84_64 IOS on a M1 mac. Cross-compiling X86_64 darwin works fine on M1 Mac.

Do you know what causes this? and is there any workaround to cross compile for x86_64 IOS on M1 mac?