Hi everyone,
We had a call yesterday with Daniel and Gabi to discuss the paths toward the extensibility of the aragonCLI. Here is a short summary if anyone wanna give feedback!
Rationale
The motivation behind this work is to allow third-party devs to extend the existing aragonCLI with custom apps. For now the aragonCLI is quite monolithic and pretty hard to update / extend: every additionnal command needs to be merged into the main aragonCLI repo which is not really scalable. Yet, as the Aragon Coop use case has shown, the aragonCLI is a decisive part of the Aragon stack when it comes to satisfy specific / complicated needs. Moreover, the use of a CLI-based interface can be of great help when it comes to iterate quickly over new apps / features as it allows anyone to quickly test / experiment with these new apps / features without requiring devs to spend a lot of time developing a polished web / desktop interface.
Example use-case
My team is actually developing a Fundraising app relying on a modified version of the Agent app to introduce a safeExecute function assuring that no collateral tokens are transfered when one initiate a transaction on a external target contract. Jorge has done a great job providing a CLI interface to the Agent app and our Fundraising app would definitely need a interface of the same kind. This is unpossible for now unless we get this interface integrated into the main aragonCLI repo which would not necessary make a lot of sense.
I believe this example use-case is far from being unique and that the CLI could / should definitely become an Aragon interface of its own in the future - alongside the Aragon Client / Desktop. Plus, it would so cool is someone developed an interface to browse votes and submit yours from the CLI 
Features
The idea is for the aragonCLI to provide the following features on the medium term.
1. Command integration
If one call aragon foo <arg1> <arg2> in the terminal, foo not being a native command, the aragonCLI should look for an aragon-foo binary in the path, forward <arg1> and <arg2> to it, and spawn it into a new process.
2. Event / Promise based aragon-wrapper
For now, the Aragon wrapper - providing generic DAO informations to app developers: installed apps, permissions, etc. - is based on RxJS. This is a mess when it comes to develop node-base / CLI apps because RxJS stuck the process and requires devs to force exit() the process. Daniel is already working on providing an Event / Promise based version of the aragon-client package and the same should be done for the aragon-wrapper package.
3. State caching
The aragonAPI should somehow provide state caching for third-party developers to rely on it and focus on their application logic instead of having to implement event reducing / caching by themselves. This is already the case for react-based Aragon and the caching system should be updated to handle node-based applications.
4. Signing
The main concern when it comes to develop node-based / CLI Aragon apps is the need for devs to re-implement their own RPC connection / Frame integration / signing system. The Aragon CLI already handle this and it should provide third-party devs an easy way to use its own mechanism.
Roadmap
Now, all of this features are the ideal state we’d like to reach at some point. This is not gonna happen in one week, of course, so Daniel and Gabi proposed the following roadmap.
Short-term
Implement feature #1
This should not require too much work. This won’t help third-party dev a lot either, but at list CLI extension could look like ‘native’ apps.
Medium-term
Implement feature #2
Implement feature #3
Implement an API for extensions
There are already some efforts to separate the « aragonCLI API » from yargs for the purpose of facilitating testing. This can be extracted into its own package and published to npm so that node-based extensions can do:
import AragonNode from “@aragon/node”
const { address } = await AragonNode.dao.new(‘democracy’, { environment: ‘aragon-rinkeby’ })
This cli-api API could also expose some requested functions to third-party devs such as signing, etc. It would also facilitate the development of node scripts to deploy daos, install apps, etc. We still have to come up with a name for this cli-api like package.
Long-term
Consider sandboxing functionality
Currently extensions can directly read from the home folder (private keys or other sensitive data) or use the CLI directly in a malicious way without the user to figure out. We should consider security implications and try to abstract away tx signing, etc.
