Turn aries-vcx into consumable crate

[Patrik-Stas]

The problem

Currently there's no good way to consume aries-vcx from other Rust code.

Solution 1 - Aries-vcx as consumable crate

Here I am proposing structuring aries-vcx into 4 layers. But that doesn't mean we should have them all exposed from the crate.

• HandleAPI (not exposed from crate) - enforces memory management. I don't see why someone using aries-vcx from rust would want to deal with u32 object handles and loose all the typing smartness. This should not be exposed, but stay as internal layer only leveraged by C-Callable API itself.
• ComfortAPI - This layer puts together Aries state machines and agency client - good example is updateState, as described on the picture. This would be likely level of abstraction someone would want to operate on if there was intention to use VCX Agency as well.
• DirectAPI - This is API of Aries state machines, agency client. These objects are already something the consumer of ComfortAPI is dealing with in parameters / return values and there should be option to call methods on these structures directly. It could also be that someone is only interested in using Aries state machines directly.

Steps to take:

1. Rename api to api_c. Then api_c module to be more "pure", as currently it does more than handling FFI calls, more specifically it:

   • Some function are reading data from settings.rs, passing it down to further called functions (see vcx_schema_prepare_for_endorser for example).
   • Spawning work on threadpool.

   2. Create api_handle module. This will contain basically the logic and state shared across threads - currently in src/*rs files which take u32 object "handles" as input/output.

   3. Create api_comfort module. This should have similar API as api_handle however input/outputs should be typed with Rust structures. This layer will contain logic gluing together multiple structures / operations on top of them (for example updateState()). This layer should not have any state of its own.

   4. Create api_direct which would include:

      • Aries state machines
      • agency client
      • other operations (pool, wallet, ledger operations)

Pros:

• As someone building Rust agent, the only runtime dependency would be libindy and libnullpay. But aries-vcx crate would be "the whole package".
• Consumer of the crate can take full advantage of Rust typing
• Consumer of the crate can decide not to use Agency
• Because consumer of the crate doesn't deal with handles as we have them now, and is not forced to shared any internal state across threads, it's possible to write Aries2Bob integration tests, each party running in its own thread without any interference between them.

[Patrik-Stas]

Updated architecture

This splits Rust portion of AriesVCX repo in 3 layers, 4 crates.

1. C-Bindings crate
   • Rust project depending on the main AriesVCX crate, providing C ABI interface and memory management (providing references to in-memory vcx objects via u32 handles)
2. AriesVCX crate
   • This is the definition "what AriesVCX" is. This will be our main artifact, directly consumable as crate in 3rd party Rust projects. This is layer where we glue up runtime dependencies (libindy), agency (downloading and updating agency-stored messages), networking (what client to use for network comm, dealing with SSL) and use AriesFSM Crate to deal with Aries protocols.
3. AriesFSM Crate
   • Essentially codification of Aries RFCs, should be with almost no dependencies. It should be very simple, only reflect Aries protocol state machines, message types, transitions and transition inputs. Given the simplicity, this crate should be compilable to WASM and should serve as cornerstone of differently opinionated Aries implementations.

[Patrik-Stas]

Generally implemented, but before we close we should:

• improve APIs exposed by the crate https://github.com/hyperledger/aries-vcx/issues/325
• publish on crates.io https://github.com/hyperledger/aries-vcx/pull/309

[Patrik-Stas]

Updated architecture diagram

[Patrik-Stas]

aries-vcx can now be considered consumable stateless aries crate which can simultaneously manage multiple wallets and multiple pool connections.

• Example how aries-vcx can be consumed: https://github.com/hyperledger/aries-vcx/tree/main/agents/rust/aries-vcx-agent