I was doing final tests for our *.ipfs2.eth gateway resolver,
ethers.js(v6) works ok (code below) but ens app is showing No Content Hash, * we only support ipfs/ipns hash as <subdomain>.ipfs2.eth to ens contenthash decoding in this service resolver.
let wallet = new ethers.InfuraProvider("goerli");// goerli testnet
let resolver = await wallet.getResolver("bafybeiee2lzvemjxesych64jw75cypjvce7nzvcyznbl3ogrztrmz2vnii.ipfs2.eth");
let content = await resolver.getContentHash();
Return value is proper `abi.encode(contenthash). Ethers.js v5 was unable to handle direct return value from resolve function, but it’s all working in ethers.js v6 & I was jus looking how it’s displayed on ens app.
I’ve no time to catch up with full universal resolver codes (23 files) tonight, but I GUESS it’s missing ( bytes4(error[:4]) == Resolver.OffchainLookup.selector) check somewhere in batched multicall from App, if resolve function reverts something else instead of revert OffchainLookup(…).
Yep that’d be prudent to do specifically for the ETH address and many other addresses. Technically speaking, the addr methods return just an arbitrary amount of bytes, though I don’t know if any coin types actually have encoded addresses that are >32 bytes. Similar thing for the contenthash, technically it just returns bytes and it’s supposed to support any valid multicodec value.
And if it’s a string (like all the text records), then I don’t think there would be any way of knowing. It’d be indistinguishable from just setting a text record value to Not Supported.