Architecture
Last updated
Was this helpful?
Last updated
Was this helpful?
As a DAO, each aragonPM registry includes a number of installed applications, including one APMRegistry, one ENSSubdomainRegistrar, and many Repo instances.
We envision that many aragonPM registries will be created for different purposes and types of packages. For Aragon, we use the aragonpm.eth registry to host our core components. We also have the open.aragonpm.eth registry for community developed packages, where anyone can create repos.
A repo keeps a versioned history of content and smart contract code tuples. The content is an on-chain reference to a blob of data that lives off-chain (we currently support IPFS or HTTP addressing). By using IPFS we have the assurance of the integrity of the data and that it hasn't changed since it was published. We recommend always publishing using a content-addressed network, like IPFS, but having HTTP is useful for testing or less critical code.
aragonPM gives users complete transparency over all deployments and traceability of what the process of publishing a new version entailed.
It is important to point out that aragonPM acts as the reference to what the last version of a repo is but all upgrades are opt-in and users of the repo, such as Aragon organizations, need to decide to upgrade or keep using an old version through their own governance mechanisms. Automatically upgrading all users of a repo is extremely dangerous regardless of the upgrade governance mechanism. That's why all upgrades are opt-in and must be started by the user. Someone could, however, build an auto-update contract that users could allow to automatically update their dependencies.
The aragonPM registry controls a (ENS) domain through its ENSSubdomainRegistrar, allowing each new created Repo to be assigned its own subdomain. This gives users the ability to find repos with human-readable names, such as voting.aragonpm.eth.
At the repo level, each repo can have its own rules that govern how new versions can be published using the from aragonOS. This allows for setting up different types of processes depending on the importance of the repo or the nature of the upgrade (major, minor or patch).
The smart contract code only applies to packages that have an on-chain contract component associated with a particular version. It can be the implementation code for or a smart contract that can be directly used. By having these code addresses stored on-chain, smart contracts can use aragonPM directly to get the latest version of the code for a repo.
In order to interact with aragonPM registries, we have built as a standalone JS library to inspect aragonPM repos, get their different versions, and fetch the referenced content. The library also allows interaction with aragonPM contracts for creating new repos or versions.
The also uses apm.js to provide a great developer experience for creating and publishing new versions of Aragon apps as aragonPM repos. The CLI's aragonPM commands, accessible through aragon apm, are the easiest way to manage aragonPM repos.
