DomainsIP-11: Avatar Text Records
A standard for storage of the avatar text record in Domains.
Abstract
This DomainsIP defines a process for retrieving avatar URIs from Domains, several URI schemes for the Domains 'avatar' text field, and how they should be interpreted by clients wishing to display a user's avatar image.
Motivation
Domains primary name (formerly known as reverse record) has been widely integrated as a de facto web3 user name across many Ethereum-based applications. As multiple apps started specifying avatar profile images as well as let users pick NFT as pfp (profile image), it became obvious to store such information within Domains so that the avatar information can be shared across different applications.
This specification standardises a way to store and retrieve this information using DomainsIP-5: Avatar Text Records
Specification
Retrieving the avatar URI
The process for retrieving the avatar URI depends on whether the client has an Ethereum address or an Domains name to start with. Domains Name
To determine the avatar URI for an Domains name, the client MUST first look up the resolver for the name and call .text(namehash(name), 'avatar') on it to retrieve the avatar URI for the name.
The client MUST treat the absence of a resolver, an revert when calling the addr method on the resolver, or an empty string returned by the resolver identically, as a failure to find a valid avatar URI.
General Format
The 'avatar' text field MUST be formatted as a URI. Clients MUST ignore URI types they do not recognise, treating them the same as if no value was set for the field.
Image Types
Clients MUST support images with mime types of image/jpeg, image/png, and image/svg+xml. Clients MAY support additional image types.
URI Types
All clients SHOULD support the URI schemes defined below. They MAY implement additional schemes not defined in this specification.
If an https URI is provided, it MUST resolve to an avatar image directly. https URLs MUST NOT resolve to HTML pages, metadata, or other content containing the avatar image.
If an ipfs URI is provided, it MUST resolve to an avatar image directly. Clients without built-in IPFS support MAY rewrite the URI to an https URL referencing an IPFS gateway as described in this document before resolving it as an https URL.
If a data URL is provided, it MUST resolve to an avatar image directly.
NFTs
A reference to an NFT may be used as an avatar URI, following the standards defined in CAIP-22 and CAIP-29.
Clients MUST support at least ERC721 and ERC1155 type NFTs, and MAY support additional types of NFT.
To resolve an NFT URI, a client follows this process:
Retrieve the metadata URI for the token specified in the avatar field URI.
Resolve the metadata URI, fetching the ERC721 or ERC1155 metadata.
Extract the image URL specified in the NFT metadata.
Resolve the image URL and use it as the avatar.
Clients MUST support at least https and ipfs URIs for resolving the metadata URI and the avatar image, and MAY support additional schemes. Clients MAY implement ifps scheme support by rewriting the URI to an HTTPS URL referencing an IPFS gateway as described above.
Clients SHOULD additionally take the following verification steps:
Where the avatar URI was retrieved via forward resolution (starting from an domain name), call the
addrfunction on the same resolver and for the same name to retrieve the Ethereum address to which the name resolves. Otherwise, if the avatar URI was retrieved via reverse resolution, use that address.Verify that the address from step 1 is the owner of the NFT specified in the URI. If it is not, the client MUST treat the URI as invalid and behave in the same manner as they would if no avatar URI was specified.
Clients MAY support NFT URIs by rewriting them to https URIs for a service that provides NFT avatar image resolution support.
Examples
The following examples all resolve to the same avatar image:
Last updated