I would like to make the case for rethinking how we are currently onboarding users and thinking about how they use Aragon.
To help illustrate I’m going to use the example of the Aragon Cooperative, because it is a clear and reasonably well documented use case. For additional information on the Aragon Cooperative please see the forum post introducing it. The process of thinking through how a user would go about using Aragon to achieve that specific use case has lead to much of this thinking… However, the process outlined should be sufficiently general to allow users to take advantage of the full flexibility of the Aragon Platform for other use cases as well.
Trying to create the Cooperative using Aragon is posible by writing a custom deployment script in solidity but is currently not possible in the UI or with the CLI. I’ve outlined some enhancments to the CLI that would enable more advanced users to get there, but it would be great to have similar capabilities available to users who are only familiar with the web3 frontend. The following suggestions are intended to offer an alternative way to think about onboarding, app installation, and permissions that would enable users the same flexibility from the UI.
Creating a new organization
Currently when you create a new organization at mainnet.aragon.org, you are prompted to name the organization, and then you are asked to choose a template. You are not given the option to start from scratch. This is problematic because the user may not want to use a template at all. In the case of the Community Cooperative, neither the multi-sig organization or the democracy template would be a good fit.
I think it would be better if we had every user set a name and then immediately be taken to a blank organization:
From there, the user could be prompted to add and configure applications to meet their specifc needs. They could be prompted to
- Add a vault and finance app
- Create a “group” (Token Manager app instance)
- Configure a vote (Voting app instance)
- Grant permissions
Each action associated with a new app instance would launch an application specific configuration process, there has been some discusion about how this might work in the context of the App Center.
When adding an instance of the token manager (side note: we may want to rename this to group manager!), the user would choose whether they want to create a Token Group, Reputation Group, or Membership Group and a Minime Token and Group Manager would be deployed with the corresponding settings.
When adding an instance of the voting app, they would need to specify an existing token manager instance or point to an existing minime token adress.
App Installation versus Instantiation
Currently we think about “Installation” as the process of adding a permission in the ACL to a given instance of an application. I think we can provide a more intuitive experience if we break the current concept of installation into two seperate processes.
When a user Installs an app the organization becomes aware that the user would like to use the application and can provide instatiation options in different areas – All of the core apps could be “Installed” by default but not have any instances deployed. The Home app would display options for deploying a new instance of all installed apps.
Instantiation would be the process of deploying an instance of an installed application. The user would be prompted to configure the instance during the application specific onboarding sequence described in the previous section.
With the existing onboarding process, a User can initiate either a Democracy or Multisig organization with come with a specific set of applications that have been programmed into what is called a “kit”. If the User wants to add additional applications that were not included in the respective kits, they would have to use the CLI. This means that Users have relatively minimal need to modify permissions. However, with the two step process described in the previous section, Users would need to interact with permissions more frequently, and it will be common for organizations to have multiple instances of the same application referenced.
As the permissions become more complicated it can become quite confusing which entities have what permissions, especially at a glance, with the way the current interface is designed. For example in the AGP1 org which has two instances of the Voting app installed, if you examine the permissions it can be difficult to discern which instance of the Voting app each “create new votes” role is associated with.
In the case of the Aragon Cooperative the permissions would end up something like this:
Providing a visual representation of the permissions in an org could help make understanding the permissions which have been configured much easier. However in order to create a visualization like this we may need some additional metadata about applications.
|Token (Token Manager)||Voting||Voting|
|Membership (Token Manager)||Finance||Survey|
|Reputation (Token Manager)||Vault|
|Individual (Address)||Token Manager|
By categorizing applications in this way we can understand their interactions a bit better. Groups are individual or sets of addresses. Constraints are optionally attached to Endpoints and apply conditional logic to execution.
Each instance of the Token Manager app is both a Group and an Endpoint and must therefore be represented in the visualization twice. The Voting app acts as both a constraint and as an endpoint (binding and non-binding respectively), but does not need to be represented in the visualization twice.
Multiple constraints can be linked together before connecting to an eventual endpoint, as is the case with vote->finance->vault.
Given the close relationship between instatiating an app and assigning permissions, it may make sense to allow users to instatiate apps directly from the permissions interface. The user could add a new group, constraint, or endpoint to the visualization, and then connect them together to set permissions.