Migrate to Latest Aries Cloud Controller and Playground Structure
wip-abramson opened this issue · comments
What?
This is a big task.
Development of the controller progressed through @lohanspies and DIDx. Code is here https://github.com/didx-xyz/aries-cloudcontroller-python
Pip package is here: https://pypi.org/project/aries-cloudcontroller/
I would live to see this repo migrate to use this dependency. Rather than have local version of the controller code within the repo itself (currently libs/aries-basic-controller
In my view this repo should become more of an education and experimentation playground for using the controller to do useful things. In many ways I would like to see the current PyDentity codebase superseded by the code in here - https://github.com/wip-abramson/aries-jupyter-playground
The playground basically takes lessons learned from building out PyDentity and the associated OM Course to create a simplified approach to spinning up any set of agents and Juypter notebook interfaces to write custom business logic.
There are numerous improvements to the approach and structure of this repo in my view. These include the splitting of projects or tutorials onto separate branches, rather than having the repo grow larger and more complex with each new project. And the development of configurable recipes that make it easy for people to get started building their own flows.
However, there is still a lot of value in the PyDentity repo currently, especially the tutorials and projects. Ideally we would migrate all of these into their own branch.
The other challenge is that all projects using the Sovrin Staging Net are now out of date. As this network has transitioned to a permissioned, pay per transaction style. Instead, we should use http://greenlight.bcovrin.vonx.io
Why?
The repo will become much cleaner, easier to use and maintain. Maintainance is important as ACA-Py is continuously updating their API and at least until we reach a 1.0 version it will not be that stable.
There is also the need to do some refactoring anyway to be inline with the latest cloud controller. So all notebooks currently produced need work for them to be usable.
Breakdown
Would like some input on this from @lohanspies and @H4LL. This is a big change. What is the best way to manage this?
I think what we have produced here is of huge value, but currently its not the most accessible so hasn't achieved its potential beyond a small circle of folks who already know how to use and manage it's complexities.
Additional Context
This is just to start a conversation about how we might go about this transition.
@wip-abramson I'm happy to contribute.
As the webhook handler no longer lives as part of the controller That will be the biggest part that is actually a re-write in my opinion. The rest is replacing more or less.