aragonCLI extensibility

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!


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 :wink:


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.


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.


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.


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‘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.


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.


GitHub issue: