Create Alice Faber CLI Demo for aries_vcx (Rust)

[gmulhearn]

For new rust consumer of the aries_vcx crate, it would be nice if we had a simple CLI demo application/s of the classic Faber (issuer/verifier) and Alice (holder/prover) interactions.

This demo application would help new rust consumers see the expected flows of interactions for the different DI roles.

Some existing examples:

• ACA-py: https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/README.md
• Cheqd/AFJ: https://github.com/cheqd/cheqd-aries

Conditions

• 2 different rust CLI applications (Alice & Faber)
• Uses aries_vcx rust crate directly
• Walks thru: Connection establishment, Credential Issuance/Receiving, Proof presentaiton/verification
• Reference the demo from the repo's documentation (README), for new comers to look at

Open Questions

• Should the demo support revocable credentials? or keep it simpler with non-revocable?
• Indy profile or modular_libs Profiles? or support both?
• Application assumes we are running the localhost ledger? or support for any ledger (e.g. some .env config)?
• What message transport mechanism for agents?
  • Could just be a simple actix localhost server for posting and picking-up messages (no special mediator protocols)
  • In the future we would likely switch this to use the mediator (+ mediator client) implementation, once it's ready

[gmulhearn]

We do have some existing "demos" in the tests directory i think. But IMO they are not very accessible. open to suggestions

[Patrik-Stas]

Yeah it would be great for adoption and onboarding

Some thoughts:

Uses aries_vcx rust crate directly
might lead to duplication with ariese-vcx-agent code. Depends what's the main purpose of such demo

1. show aries-vcx code usage, as code example,
2. or demo of the overall workflows, lib capabilities, utility tool for testing

I think the 2nd is more important than the 1st point, as to understand aries-vcx API, that should be achieved by better docs, looking at integration tests using aries-vcx directly
So assuming we would agree the main goal is 2nd point, then I think it makes sense to build such demo on top of aries-vcx-agent https://github.com/hyperledger/aries-vcx/tree/main/agents/rust/aries-vcx-agent (which is also used to in Aries AATH). But then obviously we wouldn't want to build the CLI stuff into it directly, but rather in another layer on top of aries-vcx-agent which we kind of started #692

2 different rust CLI applications (Alice & Faber)

I think if we complete some outstanding level on the CLI stuff above, we would have shared CLI tool for any agent, but perhaps for purpose of demo there can be difference in initialization on startup, or some scripting

Walks thru: Connection establishment

Just a remark which I think would be easily agreed on, but definitely have to use non-mediated connection to the demo setup as easy as possible. As you say: (I agree)

Could just be a simple actix localhost server for posting and picking-up messages (no special mediator protocols)
In the future we would likely switch this to use the mediator (+ mediator client) implementation, once it's ready

Indy profile or modular_libs Profiles? or support both?

Definitely just modular_libs, hopefully we'll get rid of indy profile soon. But aries-vcx-agent currently operates with indy stuff. It's good point we'll need to tweak it to use modular libs and integrate those changes to AATH asap

[gmulhearn]

Forgot to post update after previous meeting:

1. we've decided to keep it as simple as possible. e.g. 2 files/binaries (alice and faber) which directly use aries_vcx (rather than via the existing agent wrapper). This is bcus the intention is to demonstrate the raw aries_vcx APIs, rather than have the demonstration hidden behind a few calls
2. CLI will be as simple as possible and all happen within the 1 file. No advanced aries_vcx CLI tool implementation
3. create and use a dumb relay implementation with actix (ran as a separate binary), in the future could be updated to use the mediator client being worked on within the current lfx 2023 mentorship. IMO we should consider how this dumb relay could be used elsewhere for integration tests etc.
4. use modular_libs!

[Patrik-Stas]

@gmulhearn started the implementation
#952

Won't demonstrate whole flow, but I'd like to establish connection. The code is yet fairly messy.