Open facuspagnuolo opened 5 years ago
Looks great @facuspagnuolo! I've yet to understand better the standards around ENS to comment in-depth about the PR, but the architecture looks good. I like having a base registrar, with different "interfaces" depending on the access control for zOS or aOS (though maybe we could switch from Ownable to RBAC down the road).
I have one question pending regarding ENS: can we be sure that, under the new registrar to be deployed next year, there is no way for the domain backing the package registry to be lost? For instance, if we register thebestpackageregistry.eth
, and we lose it a year after due to a higher bid, or someone forgetting to pay for the renewal, we are dealing with quite a single point of failure. From what I understand though, domain name assignments are to be permanent, but I wanted to check.
Moving on to a different subject, which is the Registry
contract. I different ways of working here:
1- We have an APMRegistry and a ZOSRegistry, both entirely different contracts, but they are both backed by the same Registrar, tied to the same domain. This would allow both organizations, at first, to share the domain where packages are registered, and then move forward by integrating the subsequent contracts.
2- We aim at a single Registry contract that covers the use cases for both. We can extend the APMRegistry contract to have registerRepo
methods, that will allow any kind of contract to be registered, including zOS Package
s. This would remove the need for having two different contracts writing to the same Registrar, and we could actually upgrade the APMRegistry to this SharedRegistry contract.
Either way, this opens the door for arbitrary contracts to be registered in the registry, not just valid Repo
s or Package
s. We should keep a centralised control to remove malicious registry entries during the beta phase.
Another topic is the Repo
itself, which tracks different versions of a lib, and is the aOS equivalent of zOS' Package
. Regardless of its validations, its heavily tied to semver, and we should decide whether we want zOS Package
to adopt that naming scheme as well.
1- If we modify Package
to work only under semver (which I'd not recommend to do now, but later down the road), then we could have a similar public interface to Repo
, even if we don't enforce the same validations.
2- Otherwise, we accept the fact that, during the initial beta period, there will be two different kind of animals registered in the same registry, which have different interfaces.
Note that (2) means that a lib developer who wants to develop for both aOS and zOS would need to register two different packages under two different names, at least during this beta phase. On the other hand, even if we do implement a shared interface, then the expected contractAddress
linked for a version
of the Repo/Package would also need to be different, as it'd be an ImplementationProvider for zOS, and an AragonApp for aOS, until we figure out a common interface at that level for both OSs (which is not that far-fetched, actually).
Nice work @facuspagnuolo! I like the simplification work you have done.
I have a question: where is the Registry contract? I guess it is still on the works, but right now there would be no way to push new Repos/Packages to the registry. I see a mention of ZOSRegistry
but didn't find it anywhere.
Other points I wanted to touch upon:
I see most of the logic has been taken from APM, but without the auth
modifiers for newVersion
and newRepo
. I think it is important to have rich governance built in into the package manager, and that's why we made APM a DAO from the start. A decentralized package manager run by a single entity doesn't make sense, since that'd be centralized and there are already plenty of centralized package managers out there.
I think the package manager being a DAO is key for rich governance, since it makes it dead easy.
For example, in Zeppelin's case, if the package manager was a DAO, you could deploy a registry controlled by ZEP holders very easily in X steps:
newVersion
and newRepo
With just those 3 steps, we give ZEP token holders right to vote on new versions and repos inside the registry. You could get fancier and create new Token Manager instances for different groups of stakeholders, different Voting apps with different consensus thresholds for different repos, etc. This wouldn't be possible if the package manager wasn't a DAO. We recently wrote a blog post about this.
Right now, the contracts for the repo and the registry are not upgradeable, right? I think they should be (no need to argue why upgradeability is important between us haha). Also one of the cool things you get for free if the package manager is a DAO is that you can upgrade all repos in a registry. Otherwise, you'd need to upgrade each one individually. But if it's a DAO, you can just upgrade the reference to the Repo
app in the kernel, and all repos in a registry are automatically upgraded.
Repo
vs Package
namingAlthough Package
is more intuitive (you push new versions of a package) the technically correct term would be Repo
(you push a package to a repo). I guess that calling it Package
means that you push new versions to a package, but the new versions pushed packages themselves, so you cannot push a package to a package. That's why I think that, although not as sexy, Repo
is the most accurate term. It's also used by package managers in Linux, etc. That being said Package
feels more friendly, so I don't have hard feelings, but wanted to point out that question about naming.
That's it! Solid work on this, looking forward to your thoughts.
Hey @luisivan! thanks a lot for your feedback! 😄
Regarding the Registry
contract, it would be simple to have some similar contract to the ENSRegistry
that acts as a registry for us. But that would mean that either you guys duplicate the effort of publishing Repo
s in this new Registry
given that you're already using ENS, or that you stop using ENS to register Repo
s and start using the new Registry
. Based on what I spoke with @izqui you guys are interested in keeping the ENS integration, so we decided to focus simply on what will be the common interface of Package
/Repo
s that fit for both projects.
I really like the idea of decentrilizing the governance of the Package
/Repo
s, do you think it should be part of the minimum interface?
AFAIK, given that a Aragon's Repo
are an AragonApp
I think those are upgradeable. Regarding Zeppelin's Package
I haven't tested that in this PoC, but it is on our plans. I do think both should be upgradeable, but I think it shouldn't be part of the standard, do you agree?
Repo
vs Package
namingI like your thoughts on this topic :) I'll discuss this with the rest of the team and let you guys know
Got it, makes sense, thanks for the clarification @facuspagnuolo!
Regarding governance and upgradeability, I think it doesn't need to be a part of the interface, but a part of any of the implementations.
The minimum viable path is to work on a common interface and spec, which I think we are doing a good job at. But ideally we would also work on a canonical implementation that we can all use and build upon. For the spec and interface, we don't need to get into governance or upgradeability, but for the implementation, I think it's very necessary.
Fixes https://github.com/zeppelinos/labs/issues/132