- Aragon Package Manager
- Constraints on Repos?
- Currently only one contract address and one content URI available per version in a Repo
- Changing the contract address is more dangerous than a content URI change, so it's only possible to change it via major versions (checked on chain)
- Currently only one contract address and one content URI available per version in a Repo
- Number of deployed repos?
- 10 < x < 100
- Does aragonOS use the package manager?
- Not directly on chain; our upgradability architecture is based on the organization installing their preferred versions vs. relying on the package manager
- Used lightly in the DAO factories to get apps
- Roadmap: our use cases are covered well with the current version, but we'd like to improve it more to make it more useful for others
- Upgrading the deployed package manager
- Current version is upgradable, but depends on how much we'll be changing the contracts
- Current version holds Aragon's live app
- Constraints on Repos?
- Supporting more than one contract address in a Repo
- Need spec for structuring the data; how does someone know what contracts are available in a Repo?
- ZeppelinOS: libraries (base contracts) need to follow the upgradability architecture to be updated later
- aragonOS will start using unstructured storage as well to make upgrading more seamless for users
- EthPM v2 spec:
- No strong opinions, would like to work on being able to support it
- Original Aragon Package Manager and EthPM goals were fairly orthogonal
- APM: where live contracts were stored on chain
- EthPM: versioning static source text (code) files
- IPFS
- Mostly difficulties around keeping files available (we run pinning servers); uploading itself is pretty trivial
- Sync up over the next month, discuss roadmap, look for opportunities to collaborate
- Meet at ETHBerlin