search

hyperledger / aries-vcx

aries-vcx is set of crates to work with DIDs, DID Documents, DIDComm, Verifiable Credentials and Hyperledger Aries.
https://didcomm.org
Apache License 2.0
123 stars 82 forks source link

Create Alice Faber CLI Demo for aries_vcx (Rust) #870

Open gmulhearn opened 1 year ago

gmulhearn commented 1 year ago

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:

Conditions

Open Questions

gmulhearn commented 1 year ago

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

Patrik-Stas commented 1 year ago

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 https://github.com/hyperledger/aries-vcx/pull/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 commented 1 year ago

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 commented 1 year ago

@gmulhearn started the implementation https://github.com/hyperledger/aries-vcx/pull/952

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