Indy VDR wrapper for React Native

[TimoGlastra]

We've been having some discussions in the Aries Bifold and Aries Framework JavaScript (AFJ) calls on how we can adopt the new shared components libraries in AFJ and React Native (RN).

Posting this here so we all have a shared understanding on the approach we want to take.

Currently the AFJ / Indy SDK architecture looks as follows:

• Indy SDK for NodeJS is direct FFI wrapper around libindy
• Indy SDK for RN is JavaScript layer talking to RN layer (Swift + Java) talking to iOS and Java wrappers around lbindy.

This was the most straightforward approach for Indy SDK for the following reasons.

• React Native doesn't allow you to directly invoke a c-callable library or c-code.
• There were already wrappers available for iOS and Android.

React Native is working on a re-architecture that allows you to directly invoke c-code from the JS side. Using JSI (JavaScript interface) an interface from JS to in theory any (c-like?) language can be created with an interface already defined for c++.

What this means is instead of the multi-layer architecture that we needed for the Indy SDK in RN we can create a single C++ wrapper that works for both iOS and Android.

One of the benefits of this new architecture is that the JS->C++ interface can be generated from the TypeScript interfaces. That means we can define the API once in TypeScript (maybe even take the current TS interfaces from the NodeJS wrapper) and generate the C++ boilerplate from it. Same as with indy-sdk we would like the NodeJS and React Native public APIs to match

• https://github.com/microsoft/react-native-tscodegen - Allows to generate TS -> C++ interface from TS interfaces
• https://github.com/craftzdog/react-native-quick-base64 - Library already using JSI
• https://github.com/craftzdog/react-native-quick-md5 - Another library using JSI
• https://blog.inkdrop.info/how-i-improved-my-react-native-app-50x-faster-13d566061e84
• RN JSI Issue
• RN TurboModules / CodeGen Issue

The re-architecture is still WIP and not publicly released yet. This doesn't mean it can't be used yet. As you can see there are libraries using it, and RN uses it internally. There's just not been a lot of focus on DX and documentation yet. So some research is necessary to determine the best approach.

In our discussion on the Aries Bifold call we discussed this is still probably the route we want to go, as it will save a lot of complexity and resources over time. First starting with Indy VDR as it is standalone from Aries Askar / Indy CredX. If we have the setup ready doing the same trick for the other libraries should be more straightforward.

cc @JamesKEbert @swcurran @karimStekelenburg @jakubkoci @andrewwhitehead

[karimStekelenburg]

Nice work @TimoGlastra, this is a very clear overview of the potential gains of using this method 👍 . After looking into it, do you have any idea if it would be possible to call a Rust FFI interface directly using the CodeGen API, or do we really need a C-like layer in between?

[andrewwhitehead]

I wonder if cxx would help with the C++ layer?

[TimoGlastra]

call a Rust FFI interface directly using the CodeGen API, or do we really need a C-like layer in between?

AFAIK we really need a C-like layer in between. The JavaScript Interface (JSI) makes it possible to communicate between JS <-> C++ in React Native and a c-callable library doesn't conform to this interace. Maybe in the future there will be something like a JSI -> FFI thing, but I'm not sure that's even possible.

I wonder if cxx would help with the C++ layer?

I think it could help. I'm not sure how much extra work that's going to be, as that also requires to write Rust code as I understand it.

[swcurran]

Bumping the priority of this -- @andrewwhitehead . Particularly if we get a DID Indy implementation and possibly an AnonCreds implementation independent of an Indy ledger. And we want to be able to use all three components with AFJ and Bifold.

[TimoGlastra]

impeccable timing @swcurran.

@blu3beri is starting work on this next monday. We've already created a POC that provides the architecture for all shared compoents: https://github.com/blu3beri/react-native-turbomodule-tscodegen

Maybe there's some ways you can work together @blu3beri and @andrewwhitehead?

[berendsliedrecht]

Yeah that would be nice! With everything setup in that repo we only have to write the typescript interface and calling the rust method in cpp (which is just passing the arguments through, quite easy).

I am sure I will have some questions later on though :)

[andrewwhitehead]

At the moment I'm working on cleaning up the FFI interface a bit, making data types a bit more consistent and adding a standard C header. At the moment you can find one in the Go wrapper which is quite similar (also created using cbindgen I believe) although I've updated a few method signatures.

I'll be doing the same for indy-credx and aries-askar to make sure the interfaces are consistent where possible.

[TimoGlastra]

Took us some time....