ENS Support #153
Description
I mentioned this idea to @ajsantander @nventuro in Zepcon0, we were talking a bit about it. I think there is a lot of potential and use cases for ENS in zeppelinos, and I started this issue to discuss about how an integration of ENS in zOS will look like and what can be done with them.
From https://docs.ens.domains/en/latest/introduction.html
The primary goal of ENS is to resolve human-readable names, like ‘myname.eth’, into machine-readable identifiers, including Ethereum addresses, Swarm and IPFS content hashes, and other identifiers. A secondary purpose is to provide metadata about names, such as ABIs for contracts, and whois information for users.
Amazing ^
A few ideas:
- Resolve package addresses with
1-2-0.zeppelinos.eth. This will resolve the address of the zos@1.2.0 package - Resolve specific contracts implementations with
erc721.1-2-0.zeppelinos.eth. This will resolve the implementation of ERC721 in the zos@1.2.0 package. - Lets say that every contract has the the verified source code in etherscan, anyone will be able to view the source code by looking for ENS in etherscan or any other blockexplorer that provides this service. Maybe later have an "osexplorer" or something to display the verified source code on the browser, and have features like compare different implementations showing the diff between them, etc.
I think we can start by developing an ENS Library on zeppelin-solidity, something like ens.getAddress("windingtree.eth"). Also verify messages from ens owners! 🤓 ens.verify(message, signature, "zeppelin.os").
Then this library can be used in zos-lib and zos-kernel or maybe even the governance platform to interact with ENS.
Something that zos should keep in mind is the governance of this ens domains. But I guess the ownership can be delegated to the organization that is ruling the os.