Planning/Discussion to make this repo the Hyperledger aries-mediator-service repo
Closed this issue · 16 comments
I'd like to use this issue to initiate the process of making this repo the aries-mediator-service repo in Hyperledger. The purpose of the repo is to make a repo that can easily used by developers for developing mobile wallets (or any other application that needs a mediator), and that can be used as the basis of a production mediator deployment. This should be kind of like the von-network repo, but for a mediator service.
The initial version of the mediator will be based on ACA-Py. It will not be a fork of ACA-Py, but ACA-Py artifacts will be pulled in. Ideally, the repo should be configured such that if someone decides to create a new mediator not based on ACA-Py, that this repo would work essentially the same way for the users. Initially, this repo will contain a configuration of ACA-Py that is optimized to be a mediator, including the configuration of a container image that is pushed to Docker Hub (or GitHub's Container Directory?) and can be easily used in a development environment. Documentation is needed for the simple developer use case, and should provide guidance and examples for production deployments.
I'd like to see the ACA-Py Alice-Faber demo updated to use artifacts from this repo as soon as it is available.
I propose that we start with @ianco reviewing the repo and looking at from the perspective of making it easy to use for ACA-Py and Bifold developers, much as he has done in the past with the Alice-Faber demo in ACA-Py.
@dbluhm other than generating the initial invitation, is the toolbox required for mediation?
RUN pip3 install --no-cache-dir git+https://github.com/hyperledger/aries-acapy-plugin-toolbox@v0.1.0
@dbluhm other than generating the initial invitation, is the toolbox required for mediation?
RUN pip3 install --no-cache-dir git+https://github.com/hyperledger/aries-acapy-plugin-toolbox@v0.1.0
No, this was included simply for convenience but would agree it should not be included in an aries-mediator-service repo.
FYI I've done an initial refactor here: https://github.com/ianco/infra-mediator/tree/mediator_refactor
- added a
managescript to build, start and stop the containers - moved acapy-specific stuff to
acapydirectory - refactored the config = mediator settings are in
acapy/conf/mediator.ymland the other parameters are set through environment variables (set in themanagescript) - default configuration is to run locally with ngrok
- added support to detect PWD or PWV (in progress, not working yet)
What other environments do we need to support? I notice that Indicio had AWS support, however there was a comment that "TODO Fix amazon builds" so not sure if that was working?
I suggest we may want to look at Google Cloud Shell (https://cloud.google.com/shell) instead of PWD/PWV as the "play with's" seem a bit flakey
Not sure about the best way to support other mediators (other than aca-py), my thought is to build everything into a single docker-compose.yml file and then use the manage script to control which services are started (for example in PWD/PWV mode the ngrok service isn't started). We could add a ./manage start --mediator xxx parameter and then based on this parameter start the appropriate mediator service ... this would all be hard-coded into the manage script but I don't think that's unmanageable ...
Great stuff!
Regards Not sure about the best way to support other mediators (other than aca-py) I think the point is not to. What we want is to have a service that is a mediator such that people don't have to care much about what is under the covers. And, if we decide later that we want to replace ACA-Py with something else, we can do that.
The only challenge with that is if there is a controller API for adding a business logic container to the mediator. Do we want to have that added (with a dead simple sample) with the ACA-Py API or with a limited API - and how much overhead/effort does that add? The sample would just accept any requests as they arrive -- and have a place for business logic to be inserted.
We (eventually -- not out of the box unless it is zero effort) want to provide both "run it locally" (what you have) and "run it in production" guidance and (if possible) automation. That will be added as experience is gained -- perhaps as docs, configs and scripts -- or a combination of the three per platform.
The only challenge with that is if there is a controller API for adding a business logic container to the mediator. Do we want to have that added (with a dead simple sample) with the ACA-Py API or with a limited API - and how much overhead/effort does that add? The sample would just accept any requests as they arrive -- and have a place for business logic to be inserted.
It's not a big deal to write a simple controller to auto-accept all connections (vs using the aca-py auto- flags)
We (eventually -- not out of the box unless it is zero effort) want to provide both "run it locally" (what you have) and "run it in production" guidance and (if possible) automation. That will be added as experience is gained -- perhaps as docs, configs and scripts -- or a combination of the three per platform.
Running in prod is also fairly straightforward, I can add a flag to the manage script to disable ngrok, and otherwise all that's needed is an explicit ENDPOINT url (whatever url aca-py's endpoint is exposed), I'll add some docs around this.
Cool -- I think it would be best to start with a simple controller included and to turn off the auto-accept settings.
For the demo mediator controller I'm planning to lift the code from here: https://github.com/bcgov/aries-vcr-issuer-agency/tree/main/endorser
This, similarly, is a demo controller for an endorser for the Aries VCR Issuer Agency, written in NodeJS and Feathers.
The alternative is to use Python, but I'm seeing NodeJS is becoming more common.
Anyone else have an opinion?
👍
Demo controller is now available here: https://github.com/ianco/infra-mediator/tree/mediator_refactor (can run either stand-alone agent in --auto mode, or start up with a controller that responds to connections requests).
@dbluhm I suggest that Indicio move the infra-mediator repo to hyperledger (and I suggest to rename something like aries-mediator-service so it's more clear what it is)
... and then I can open a PR with my updates
Great stuff -- would love to see this! I think we have to make sure that the license is done at least (if not already) and I agree that the name change should happen. Is the DCO on the entire repo complete, or do we have to basically collapse the history? Love to see this available sooner than later :-). But I always say that...
Is the DCO on the entire repo complete, or do we have to basically collapse the history?
I did a spot check and it looks like all the commits are DCO signed off (but we'll find out soon enough when we try to move the repo over).
I reached out to Ry on Hyperledger RC to (hopefully) get the transfer process started 🙂
sure - next steps: rename the repo as you would like it to be, and transfer the repo to me
Just doing a final sanity check and then I will initiate the transfer!
I have now:
- renamed the repo to aries-mediator-service
- transferred the repo to myself (because of github restrictions on where org repos can be transferred)
- requested transfer of the repo to @ryjones
done!