On 'aragonpm.eth' governance

AGP-28

On the previous ANV, AGP-28 was voted on and approved by ANT holders. It described a process for governing the creation of new repos on the main aragonPM registry (aragonpm.eth) as well as publishing new versions to the existing repos.

Deploying a new version to any of the existing repos would require a vote to be approved with a supermajority (66.6%) by the token holders of the APM organization. The AGP proposed an initial set of token holders that would have governance power over the registry.

When the AGP was proposed, it assumed that the network would continue engaging an Aragon Network Security Partner. The ANSP would receive tokens to govern aragonpm.eth together with Aragon One.

At the moment, the AGP process doesn’t have a concept of an AGP’s execution being dependent on another AGP passing. Because of this, given that AGP-37 (security partner retainer) was rejected in ANV-2 (the same Network vote in which AGP-28 was approved), Aragon One would be the only entity with voting power to control aragonpm.eth.

Therefore, AGP-28 cannot be implemented as specified as there is no ANSP. If only Aragon One were to receive tokens, the actual governance of the registry wouldn’t change but it would make the deployment process more complicated.

After some consideration, it has been decided to defer the implementation AGP-28 for the time being, and potentially submitting a new AGP to amend AGP-28 to add some changes and a new initial token distribution.

Beyond AGP-28: segregating repo ownership in aragonpm.eth

The current AGP-28 specifies that all the repos in aragonpm.eth would be governed by the same voting process. This means that every update to an app in the registry (even minor frontend fixes) would need to go through a 3 day vote which is inconvenient for apps that are updated regularly.

Thanks to the architecture of aragonPM, different repos can have different publishing permissions. A possibility for an enhancement to AGP-28 would be to have Flock teams submit requests to the Aragon Association (or a ‘technical council’ type body elected by the AA or ANT holders) for the creation of new repos or direct publishing rights to existing repos. This would allow Flock teams to directly publish updates to the repos they have permissions over (as Aragon One currently does). The AA would be the manager of all the permissions, having the ability to revoke publishing permissions.

The existing governance structure that AGP-28 proposes could still be used to publish new versions in some repos that are deemed critical and in which the delay and added coordination cost for deployment are worth it for the extra security.

A criteria would need to be stablished for what apps should be hosted in aragonpm.eth. In my opinion, apps that have had a professional security audit via the Network’s Security Review process should be in the main aragonpm.eth registry. I’d really appreciate to hear some feedback on this by other Flock teams.

5 Likes

Hey !

I totally agree with this post. We discussed this during the last All Dev Call and I think the rationale for a package to hit aragonpm.eth should be:

  1. apps that have had a professional security audit, and
  2. apps that the network / association is commited to maintain on the long run [if Aragon Black or Autark teams disappear for some reason the network / association will somehow transfer ownership on the fundraising / reward app]

I was also thinking that in the future we could maybe envision a slight update to aragonPM contracts to handle parameterized permissions. This way we could make it so that:

  1. minor and patch upgrades [frontend ones] can be published at the discretion of the team maintaining them.
  2. major upgrades [contract upgrades] should be published through the Agent app of some security council DAO [including other flock teams, AA, etc.]

I’m not sure there is a need to wait for this to bootstrap the governance process but it would provide another security layer to make sure e.g. we can’t publish a scammy upgrade [or even initial version] of a sensitive contract to stole some funds somewhere.

7 Likes

This is something we should certainly look into for the next version of aragonPM. It was a slight oversight that the original does not support this parameterization; part of it being that the argument type of uint16[3] is slightly onerous to parse in the ACL. If we decide we would like to stick to the “contract changes only on majors” rule, we could simply have a parameter for whether a new version is a major upgrade or not.

It is not entirely clear when this new version of aragonPM will come though, as it is not current scheduled (let’s sync after 0.8 once you have a bit of breathing room @osarrouy), so I agree we shouldn’t get hung up waiting for it before implementing other changes to the aragonpm.eth Instance’s governance.

2 Likes

Yeah. That sounds good. Aragon Black will have some breathing room after Aragon Fundraising release so there will be some space to update aragonPM.

In the meanwhile I’ve just added it to the list of requested features here so that it stays in our pipeline :slight_smile:

4 Likes

As it was agreed on the previous All Devs Call, we should deploy a sub-registry for Flock teams to be able to deploy apps even before they are ready to be included in the main aragonpm.eth registry. This sub-registry would have a more relaxed governance process and would allow teams to publish new versions of their apps quickly.

Flock teams would provide an address that will be granted permission to create new repos in this sub-registry. When creating a new repo, the creator specifies an address (aragonCLI’s aragon apm publish sets it to the same account by default) that will get permission to publish new versions and is set as the permission manager for the role (being able to grant/revoke the permission to publish new versions to other accounts).

If an app that has been published to this new registry is ‘moved’ to the main registry it wouldn’t be trivial to migrate existing users (see issue).

I personally like the flock.aragonpm.eth name for the sub-registry although some people were in favor of naming it experimental.aragonpm.eth. If the developer wants to signal that an app is still experimental, it can already be done by setting a status flag in the arapp.json file, which will be shown in the app list. I don’t have strong feelings for the name, definitely open to comments and suggestions.

2 Likes

Hey ! I was in for the experimental.aragonpm.eth name but didn’t thought about the experimental flag …

My main rationale was that users probably care less about how did published the app than knowing what it’s status, maintenance, etc. I also thought that at some point quality apps incoming from Nest and not audited and open to breaking changes yet could end up in that repo [for instance the predictive market one …]

So I think I would still go with the experimental namespace through i’m pretty open to the flock one :slight_smile:

2 Likes

I think:

  • We shouldn’t do flock: we should keep open to the possibility of this being a sub-registry for Nest funded apps.
  • We shouldn’t do experimental: is there a guarantee that all apps will eventually make it aragonpm.eth parent domain? I like the arapp.json status flag better.

how about something more generic like:

  • flight.aragonpm.eth
  • hatch.aragonpm.eth
  • community.aragonpm.eth

…?

1 Like

That’s a great point about Nest teams, I think we should do this.

I don’t think this will be the case for all apps that get published here. I think that Flock teams should be able to use this sub-registry liberally for anything they need published to be used on Rinkeby or Mainnet.

Those are all great points and I think that going for a more general term makes sense. hatch.aragonpm.eth sounds great to be and pretty aligned with the Nest/Flock terminology.

2 Likes

Don’t have super strong feelings on this… My main concern with something like hatch is that it is not immediately obvious what the implication is, versus something like experimental which clearly indicates that there is a different level of support related to the release.

Possibly slightly tangential, but as I user I would personally prefer something like “experimental”, “alpha”, and “supported”. Things in “experimental” would be essentially equivalent to “open” and maybe we could just use that but idea would be that apps that are deployed there carry no assumption that things will work perfectly, or that they will be supported in the future.

Things in “alpha” would be only for packages we intend to support long term but available as pre-releases which may not be audited. Deployments would be mirrored between alpha and supported, but supported would only have a subset of releases which have been audited or otherwise meet some standard for long-term support / stability.

1 Like