Is it time to tie everything to ENS?

[VoR0220]

I'm currently relooking at these problems with a fresh pair of eyes and I'm starting to realize that a lot of our problems can be resolved if we just use ENS + proper resolution results within the ENS resolved to name. Upgradeability seems very achievable using ENS. Is there any pushback to this radical refactoring concept here?

[fubuloubu]

Could you give an example? I'm having a hard time understanding your specific proposal.

[VoR0220]

So for example, lets say I reserve the domain "owned.openzeppelin.eth" in ENS. From there I resolve to a JSON file that contains the following:

• An IPFS link
• A github link
• A bitbucket link
• A swarm link
• A git hash checksum
• the address of the actual contract
• an upgradeability mechanism for upgrading all of these different links accordingly by various entities to be signed off by the author

This makes it easier to manage because one need only assume that an ENS instance is on the EVM compatible chain (and this seems kind of obvious to me to do especially in a testnet case). If I want to upgrade, I set the upgradeable to an owner of some kind (can be a single owner scheme or a multisig) and from there push up any changes via in a continuous integration solution linking to a specific address. This just seems like it would be smart standard practice to utilize what is essentially a first layer solution for easy upgradeability and ease of resolution.

[VoR0220]

Let me know if that helps.

[pipermerriam]

Using ENS within the spec (as in part of the JSON file which represents a package) gets a strong 👎 from me since the value that an ENS name maps to is inherently mutable and thus would result in non-deterministic builds.

Now that doesn't mean that someone couldn't use a ENS URI which contained a hash of the content as part of the URI, but that is already possible with #66

[VoR0220]

It's inherently mutable but it is trackable across history...so while it is mutable, it is deterministic still. I don't think it would be hard to grab an event log by resyncing the chain to get what is needed over previous history. This is just my thoughts to simplify this process down. I'm just offering this as a means of standardization. If someone isn't doing this already then I'm going to do it myself because I think we're all tired of hard to upgrade contracts. :)

[fubuloubu]

Mutable means non-deterministic for builds by definition.

[fubuloubu]

Also, can you link an ENS lookup to a JSON file?

[VoR0220]

@fubuloubu for builds yes, I agree, but as a resource identifier...idk...seems like a smart way of going about it. As for ENS lookup, pretty sure you can in one way or another. Whether that comes in the form of a bytes string thats to be formatted locally or in an ABI formatted series of arguments construed by the ABI is another matter...either way I think this probably ought to be an example contract at the very least. Think I'll try crafting one up.