If I understand this correctly — this is an ExtendedResolver where queries are translated to URLs for assets on IPFS which likely? are stored as pre-signed abi-encoded CCIP responses. The contract has a registry for (node → contenthash) rather than relying on a contract-level CCIP backend.
This is interesting! I like that it works with existing CCIP tech but I’m not sure I understand the "...json?t={data}&format=dag-json" use-case (unless this is being used for something I’m unaware of) — wouldn’t any endpoint that can (dynamically) respond to this, be better served by their own trusted CCIP setup? It seems like the static case (eg. pre-signed response data for text or addr record) is the primary use-case for this technique. However, assuming static data, couldn’t the contenthash requirement be relaxed to an arbitrary URL prefix? With the only requirement being wildcard CORS?
I like this idea. This is related to NFTResolver.. Even something like text("eth.balance.raffy.svgpfp.eth", "avatar") → data:...<svg>0.1 eth</svg> would be cool (although there’s no specification for liveliness and many social applications that show avatars have caching mechanisms.)
I still think there’s value in having an On-chain resolver with individual records that can be stored Off-chain, compared to an Off-chain resolver with decentralized storage. For example, once you have external references, using IPFS becomes a personal choice.
One way of thinking of this, is as a generalization of the avatar string spec.
The issue with this approach is that you need some new standard (decentralized fetch + optional integrity/validation check) and you need an efficient way to encode resource identifiers.
For example, if a text("name.eth", "description") returned myipfs:story — why couldn’t that invoke fetch("https://name.eth.limo/story") client-side? Or mycontent:avatar.json → where contenthash is used instead of ens + dweb gateway?
For signing, I think all you need is a single bit in the reference, like myipfs:story?x, to indicate that the response should be interpreted as a signature + blob, which must validate against the records owner. Alternative checks might be integrity via hash, or checking a different signer, eg. NFT data signed by the EIP-173 owner().
My post above was one idea for compacting these references. Alternatively, since ENS is literally a system for naming things, I’d imagine ENS names themselves are a solution to this problem! Do we need ipfs://Qmumbojumbo if we have "abc.eth" + decentralized fetch?