At the moment, we have:
- Aragon apps (contracts + frontend), that can be configured and deployed by templates (also named kits)
- Templates (or kits), that also contain contracts + frontend code (for the onboarding configuration screens).
Note: the configuration screens are technically located in aragon/aragon at the moment, but they don’t belong here and should be with the templates (kits) they belong to.
Problems that remain to be solved:
- How to configure an app when installing it from the apps center?
- How to install a template (kit) after a DAO is initialized? Using a “templates” category in the apps center?
- How to group related apps in the menu? (e.g. two apps that are supposed to be deployed together and are acting like a single app).
- How to avoid making authors declare two different setup screens (one for the onboarding, one for the apps center)? What about alternative clients that are not using React?
- Can we have an alternative frontend for an app?
Proposal: Templates (kits) as apps
The proposed solution would be to merge into one entity the concepts of apps and templates. It is going to be named “app” in this post, but we could also decide to name it differently, like “package” or “bundle”.
At the moment, an Aragon App contains:
- A set of smart contracts.
- An app frontend (the web app that comes with an Aragon App).
And a template (kit) contains:
- A list of the apps it deploys (can be found in the package.json but not explicitly declared).
- An optional “setup app”, that lets the user configure the template.
Instead, apps would contain four optional elements:
- A set of smart contracts (Aragon App).
- An app frontend (Aragon App frontend).
- A list of dependencies: Aragon apps that are going to be deployed and are explictly declared (optional).
- A setup app, to let the user configure things before deploying.
How it works
The Aragon app and frontend would behave the same way they do, except they both become optional.
The setup app contains everything needed to configure and deploy the app, including the configuration screens. The configuration screens can be rendered in two (and probably more) different contexts: the onboarding screen, or the app center installation screen. We might decide to use a description language rather than React components, to make these screens safe and easier to render in different contexts.
The app dependencies are going to be listed to the user when installing an app from the app center. We could also decide to list them on the onboarding app, for more transparency.
Just for illustration purposes, this is how the app directory could end up looking like:
my-app/ setup/ # The setup app (what we call template or kit at the moment: smart contract + frontend) ethereum/ # The Aragon app (smart contracts) frontend/ # The web app (named “app” at the moment) arapp.json # The Aragon apps it depends on should probably be declared in this file.
Going further: let apps declare menu items
An app installing other apps could decide to declare the way its menu items behave: we could allow apps to group or hide some of its menu items.
Doing that would mean that the menu is not going to list all the app instances anymore, and would require to have another way to see that. At the moment we already list all the installed instances in the Settings app, but it would be nice to have a friendlier version, maybe with a visualization of the dependencies.
To prevent any surprise, we could let the user know about the menu structure when the app is being installed.
Example: Voting app
The voting app will generally be installed from a higher level app that depends on it (see the Democracy app example below), but can also be deployed from the apps center.
The setup will run if this app is installed from the app center, and allows to set:
- The token.
- The required support.
- The minimum acceptance quorum.
- The voting time.
The current voting app, minus the
Example: Democracy app
When the user chooses the Democracy template on the onboarding screen, it would actually start the setup part of the Democracy app.
@aragon/apps-voting @aragon/apps-vault @aragon/apps-finance @aragon/apps-token-manager
None (this app only deploys and configure other apps).
Example: Voting Roulette app
This is an alternative frontend for the Voting app, that lets people vote randomly by throwing a dice. It is based on the Voting app and only contains an alternative frontend. It could use the menu API to hide the Voting app from the menu, and only display the Voting Roulette item.
It could redirect to the Voting setup directly, or have its own setup (e.g. this app could decide to be opinionated about the Voting roles or settings, or get this information in a different way than the Voting app does).
The Voting Roulette frontend, which interacts with the Voting app contract.