Registering *.eth from L2 is hard problem to solveā¦ itās easy for sub/domain.eth and CCIP resolver on L1 with domain.eth pointing to L2 data resolver contract, people are already using thatā¦ Iād recommend not to introduce any breaking changes against stuffs thatās already working & if possible donāt add in extra complexity. ENS is already 3 levels deep with name registry, erc721 & erc1155 wrappers.
As weāre verifying manager/approved signature stored on L2/offchain, at worst case scenarios BAD L2 RPC/gateways can only send stale recordsā¦ we could narrow down with extra ttl/validity timestamp but thatāll require manager/signer to update their records more frequently on L2/offchain.
In bad dapp/client scenarios they can resolve to anything even for non-ccip lookupsā¦ For current web2 gateway with signers, any BAD/compromised gateway signer can easily sign and send anythingā¦ Domainās manager/approval sig is more trustless than web2 gateway signer.
Thereās same old privacy risk with web2 ccip gateways. L2 RPC endpoints are still web2 but itās less risky than random web2 gateways used by every domain.eth. Using CAIP22 like format can leverage L2/light clients if underlying dapps/wallet clients have light clients support in future.
āif clients are not following ENS specs theyāre not ENS compliantā¦ā, Paraphrasing @nick.ethās reply from 2020 back when I asked "what if bad scam clients skip normalization, or resolve their addr when I send $eth to ādomain.ethā from their dapps/wallet.
For batch resolving I kinda preferred using @serenaeās draft specs [Draft] ENSIP-##: Off-chain Name Meta-Resolution
[Draft] ENSIP-##: Off-chain Name Meta-Resolution compared to current ENSIP-16: Offchain metadata
with extra āgraphqlUrlāā¦
sorry Iām bit lagginā¦ back to work!