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