It does not however have a tokenURI function, which is often used to store the json file that will have the image representing the NFT. Where does that data live? Of course the images of your profile are pulled from other NFTs or links, but the image composite, including the name and logo, is stored somewhere too. Where?
That is a centralized service obviously, so the ENS name “NFT image” is dependent on some running server. The metadata service also in turn is dependent on Infura, which is known to run into problems from time to time.
That same metadata service can be used to retrieve the avatar image too (without the ENS overlay). Example: https://metadata.ens.domains/mainnet/avatar/matoken.eth
Another “gotcha” that client/dapp developers run into is that in many cases they can’t just resolve the avatar record and use it. If it’s an IPFS URL, that will usually not render inside of a browser <img> tag. And if it’s that special NFT string, obviously that won’t work directly either.
The metadata service detects when the avatar record is a reference to an NFT, then invokes tokenURI on that NFT contract via Infura and gets the actual image. It’s more complex than it seems too, because unfortunately contracts have a wide variety of ways in which they “support” the tokenURI metadata, and in many cases the format they use isn’t technically correct. The image might also not be just a regular HTTP/IPFS URL, it might be an on-chain data: URL too, which may or may not further be Base64 encoded, etc. If the final URL is IPFS/IPNS, it’s also prefixed with the ipfs.io gateway service so that it’ll actually be able to render in browsers. I could go on with other special cases…
Anyway the metadata service tries to iron out edge cases like that and make it simple for clients to retrieve the avatar / NFT image.
@serenae That’s because metadata handles expired names with generic non-registered name template, but it should definitely be more user friendly. I am working for an update right now.
