Client: App center onboarding

[luisivan]

It would be helpful to have a lifecycle diagram of what linking/assinging permissions entails in order to create a UI for it. I guess @izqui can provide it, but I'm also assigning it to @chris-remus in case it needs to be re-assigned to someone else.

[onbjerg]

Not sure what the issue is exactly about, is this for the permissions app or something else?

[jounih]

@onbjerg I'm working on design for a new "App center" where you can enable (and disable) new apps once we start having more than just the default apps. These could be community written apps.

Apps may need to request permissions, which should be shown to the user in the UI when enabling them - so I'd need to know what kind of permissions can be requested so I can design it.

[izqui]

I will try to summarize what needs to happen for an app to be completely installed:

1. Create app instance. kernel.newAppInstance(...) or kernel.newPinnedAppInstance(...), this call require the sender to have APP_MANAGER_ROLE in the Kernel with at least access to the bases namespace. After the first install of an app, you shouldn't need a role to deploy new instances, but right now the Kernel requires the permission regardless (cc @sohkai, we may want to fix this).

2. Set outgoing permissions to the new app if the app needs permissions over other apps in the org. This will require the sender to be the permission manager of that given permission. E.g.: Installing the Payroll app requires the Finance app's permission manager for NEW_PAYMENT_ROLE to grant the permission to the newly deployed Payroll app. In case no instances of the permission exist, it needs to be created with an entity with CREATE_PERMISSIONS_ROLE in the ACL. Outgoing permissions can be found in the artifact.json file, with the appId and version of the required app. The user should be prompted to select the app to install with, and maybe even allow to deploy a new instance of the other app.

3. Initialize app. The deployed app will probably require a transaction to be correctly parametrized, there is a risk associated with doing this in multiple transactions, as the initialize transaction might be frontrunned and the app can have miss-leading parameters forever. Information of the initialization parameters can be found in the artifact.json file.

4. Set incoming permissions. For setting the access control for the newly deployed app. It needs to be created with an entity with CREATE_PERMISSIONS_ROLE in the ACL. A list of all the roles an app defines can be found in the artifact.json file too.

Given the amount of transactions required to do so and the high risk of front-running, we should intend for app installation to be done in just one transaction by using a DelegateScript EVMScript runner that can get executed by one app in case some entity (e.g. Voting) has permissions to do everything required. In the case that not one entity can perform everything, this complicates immensely.

My proposal is that apps could come with an installation script (it could be deployed as part of artifact generation by aragon-dev-cli) which could be defined in the artifact.json file that could look like this:

contract PayrollInstallScript {
  function exec(Kernel dao, Finance finance, address payrollManager) returns (bool) {
     Payroll payroll = dao.newAppInstance(finance.appId(), finance); //  1
     dao.acl().setPermission(payroll, finance, finance.NEW_PAYMENT_ROLE()); // 2
     payroll.initialize(finance);  // 3
     dao.acl().createPermission(payrollManager, payroll, payroll.NEW_EMPLOYEE_ROLE(), this); // this is whatever runs the script, lets assume voting

    return true; // suicide prevention
  }
}

Because DelegateScripts get executed with a delegatecall, everything would be run as if it was logic in the executing contract, and this can be used for the executing contract to retain rights on the deployment, in this case it would be the permission manager for Payroll management.

Also this script is completely trustless and reusable in many DAOs, you can think of it as an app base contract

[lkngtn]

Would also enable to you install multiple instances of the same app? (not sure how you would differentiate them in the menu)

Specifically having multiple token managers (groups), and multiple voting apps (based on different parameters/tokens) would be incredibly useful for creating more complex organizational structures within the dapp.

[onbjerg]

@lkngtn Yes. They are differentiated by their app identifier, specified in the app front-end.

For example, the token manager identifies itself with the token symbol it is managing, so in the menu you would see:

- Token Manager (collapsible menu)
  - ANT
  - SPANK
  - ...
- Voting
  - A
  - B
  - ...

[lkngtn]

Hmm might consider using a label rather than token symbol, I imagine within an org there may be many tokens (if they are being used for groups) and a short symbol might be too restrictive?

[onbjerg]

@lkngtn This is up to the front-end, could totally be configured as well. The labels are not defined by Aragon.js or the contracts, so changing this behaviour is super trivial.

[sohkai]

@izqui

After the first install of an app, you shouldn't need a role to deploy new instances

Could you get into situations where someone could continuously spam you with new instances to clutter an UI (if they had the correct permissions, they could fully install these new app instances too)? Unless there's a use case in mind where it'd be nice to allow anyone to install a new instance after the first install, I wouldn't change this.

[izqui]

@sohkai If they have the create a permission role that's virtually the same as being able to install an instance, as (AFAIK) the logic for determining what apps are installed in an org is just a function of ACL events and not Kernel NewAppInstance events.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for contributing to Aragon! 🦅