Feat/bet 519 add metadata functions

[makoto]

Implements https://github.com/ensdomains/ensips/blob/master/ensips/16.md on ETHTLDResolver

[immunefi-magnus]

🛡️ Immunefi PR Reviews

This pull request is not eligible for a PR Reviews review. Please contact Immunefi support.

Reason: This PR can't be reviewed because no PR Reviews plan is configured for your organisation. Please ask your admin to set up a plan to enable reviews.

[Arachnid]

This seems to overlap with Raffy's IVerifiableResolver. Can you discuss with him?

[adraffy]

I'm of the opinion that these are different things.

IOffchainResolverMetadataProvider is the resolver profile for an offchain/crosschain registry of a name. When baseRegistry is null, I assume this means offchain? And otherwise, it links to a crosschain V2 IRegistry? This makes no claim on how the resolver itself works, just where its "continuation" is located.

IVerifiableResolver is the resolver profile for the verifier and gateways involved in the resolution of a name. verifier can be anything: IUnruggableVerifier, DNSSEC, etc. The gateways are equivalent parsing urls from OffchainLookup. The primary problem it solves is that the verifier might not be exposed and/or it requires parsing extraData which is resolver-specific. To trigger an OffchainLookup, it requires knowing what type of profile the resolver accepts, such that it will reliably revert OffchainLookup. Implementing this interface solves both of these problems and avoids having to circumvent automatic CCIP-Read client-side logic.

For example, we could have a common signature verifier contract for the 0x1900 offchain protocol, instead of every resolver implementing some weird copypasta of the same logic. And then all of those resolvers could implement IVerifiableResolver and then they would signal that they're secured by standard trusted signers. Additionally, I would want some interface to check if a signer is trusted signer (and/or standard events.)

---

They're both related in that they need a convention for wildcarding all names of the resolver? For which I think we said dnsEncode("") == 0x00 works, since if you interpret like a subdomain match, eg. isSubdomain("", "raffy.eth") == true (equivalently, "eth" and "raffy.eth" would also match.)

---

I kinda think IOffchainResolverMetadataProvider is two separate interfaces but I'm okay with single common interface.

1. There's the interface for an offchain server, which is not backed by an IRegistry with yet-to-be-defined API for (serverURLs).
2. There's the interface for a crosschain IRegistry with (rpcURLs, chainId, baseRegistry).

Is it true that either: chainId = 0 && baseRegistry = null or they're both defined?

[makoto]

Just took a look into https://github.com/ensdomains/ens-contracts/blob/289913d7e3923228675add09498d66920216fe9b/contracts/resolvers/profiles/IVerifiableResolver.sol#L13

which has this function

    function verifierMetadata(
        bytes memory name
    ) external view returns (address verifier, string[] memory gateways);

Do you mean to add the function into IOffchainResolverMetadataProvider or the combine verifierMetadata and metadata into one function? @Arachnid

[Arachnid]

Is this check necessary? If someone sets this contract as the provider for a name incorrectly, is any harm done to anyone other than the person who configured their name wrong?

[Arachnid]

These variables should probably be set in the constructor.