ENS support in address field

[ligi]

Great suggestion on twitter: https://twitter.com/gh1dra/status/1239962423341322241

_{View in Huly HI-427}

[corydickson]

Give me a few days and I'll pick this up

[corydickson]

Strange times ahead :)

[corydickson]

As a user I would like to be able to enter an ENS address and it will resolve the associated on-chain ethereum address with its source code and metadata. If such an entry already exists in the repository notify the user, otherwise prompt the user to upload said files to IPFS and verify.

To achieve this we will need to interact with the ENS resolver contract on a given chain. This mapping could be maintained in the front-end. Once we have the address, check it's runtime bytecode against entries in the address-db, if the value at a given key match then it already exists inside the repository.

A consideration is that this will only work for TLD if my understanding is correct? Furthermore is it necessary to have the user upload these files, or would a better approach is to leverage this EIP, ensuring that the retrieved ABI hash is already pinned to IPFS. I believe the source code would still need to be provided though...

I'll get started mocking up the UI, hopefully I'm thinking about this the right way

[ligi]

ah good that we talked about it ;-)
I understood your idea differently. With ENS support I thought you mean instead of entering an hex address in the form you would enter the ENS address of the contract.
Actually I was not even aware of EIP-205. But before going this route I would actually check if there are contracts out there that leverage this EIP - have the gut feeling that it is not.
I think we should split these issues a bit and keep this issue around "ENS support in address field" - meaning if the user enters something that does not start with 0x we will try to resolve it via ENS instead of telling the user that it is not an valid address.
But feel free to open issues with your follow up ideas. But I think we should start with the low hanging fruit of what I just outlined. What do you think?

[corydickson]

I think we are speaking of similar things for the ENS resolution, and agree that's the best place to start. Do you think that verifying the on-chain bytecode against what is already inside the database to be a fruitful check? The reasoning behind this was so that we could prevent duplicate contracts being added to the database i.e two of the same runtime bytecodes would map to a 0x address and ENS name and would be treated as separate entities

[ligi]

AFAIK duplication cannot happen for exact matches which we only support currently. It might become an issue when partial matches are supported