Diamond-wrapped CCIP2.eth

[sshmatrix]

Shall we diamond-wrap the resolver? If it takes off, we will save ourselves a lot of trouble during upgrades and be able to integrate new records with ease. It is relatively easy to do as well, our resolver is not that big code; not that many functions to diamond-wrap. I can do it if we agree on this. No need to write new tests for it either; proof of good diamond is if old tests keep working. Only downside is larger deployment size and hence more gas to deploy.

[sshmatrix]

On second thoughts, our resolver is practically a wildcard on record types, so it doesn't necessarily need diamond. But still, think about it...

[0xc0de4c0ffee]

I think it's better without diamond+resolver..

a) resolver is already too $big to deploy on mainnet so adding up fragmented eip2535 for possible future upgrade will cost more.

b) can't rug vs. won't rug, it's better without diamond in this resolver case, so we can't go rouge on diamond and map vitalik.eth to s**talik.eth :p

c) resolver doesn't handle ENS ownership so anything bad on resolver have no effect on actual ENS ownership.

d) any future big upgrades on ENS have to wait for next version of resolver deployment. we've basic function map features but more complex new function with extra input will require full resolver upgrade. & if we want those function/feature updates we can handle that as secondary helper contract, bit less complex than diamonds.

[0xc0de4c0ffee]

Adding helper contract for future upgrades. func mapping part is only thing to upgrade on resolver.

    if (bytes(funcToFile[func]).length > 0) {
        _jsonPath = funcToFile[func];
    } else if (func == iResolver.text.selector) {
        _jsonPath = abi.decode(data[36:], (string));
    } else if (func == iOverloadResolver.addr.selector) {
        _jsonPath = string.concat("_address/", uintToString(abi.decode(data[36:], (uint256))));
    } else if (func == iResolver.interfaceImplementer.selector) {
        _jsonPath =
            string.concat("_interface/0x", bytesToString(abi.encodePacked(abi.decode(data[36:], (bytes4))), 0));
    } else if (func == iResolver.ABI.selector) {
        _jsonPath = string.concat("_abi/", uintToString(abi.decode(data[36:], (uint256))));
    } else if (func == iResolver.dnsRecord.selector) {
        /// @dev : TODO, use latest ENS codes/ENSIP for DNS records
        (bytes32 _name, uint16 resource) = abi.decode(data[36:], (bytes32, uint16));
        _jsonPath =
            string.concat("_dns/0x", bytesToString(abi.encodePacked(_name), 0), "/", uintToString(resource));
    } else if(address(FeatureContract) != address(0)) {
        _jsonPath = FeatureContract.resolve(name, data); // revert there if func not in feature list
    } else {
        //revert ResolverFunctionNotImplemented(func);
    }

[0xc0de4c0ffee]

I too have 2nd thought :p

We should make a diamond contract for all-in-one utils functions only, upgrade & reuse that as "library" for all our contracts.
50% of our ENS related contracts have same utils functions redeployed again & again.. most logics in side big functions can fit in that diamond base as view functions.

[0xc0de4c0ffee]

e.g, if we need a new subdomain + nft contract we can deploy non-diamond base as standalone NFT contract but internal "non-ruggable" library functions in that contracts live in our centralized fully upgradable "utils" contract controlled by multi-sig 🤣 (@chrisblec's pfp pop'd in my head).. it's mostly encoders, decoders & utils functions that we can upgrade/optimize in future but it's 100% risk factor on our side, making everything "won't rug" = trust me bruh mode.

Or jus pay for our normal non-upgradable contract gas and stay decentralized, "immutable".. set admin to zero address once it's finalized. 🖖

[sshmatrix]

"won't rug" = trust me bruh mode

That's true. it's lowkey anti-agenda of immutability

We should make a diamond contract for all-in-one utils functions only, upgrade & reuse that as "library" for all our contracts.
50% of our ENS related contracts have same utils functions redeployed again & again.. most logics in side big functions can fit in that diamond base as view functions.

Like it. I'll put it up on to-do-but-not-urgent list 🥳