Current draft here: ENSIP-##: Off-chain Name Meta-Resolution
Problem:
There is no standard way today to retrieve the following information for off-chain names:
- List of existing subnames
- List of resolvable text record keys
- List of resolvable coin types
For on-chain names, clients query the above information from the ENS Subgraph, like:
domain {
subdomains {
labelName
}
resolver {
texts
coinTypes
}
}
This means that client apps/websites (including the official ENS Manager App) cannot display subnames, or know in advance which text records / coin types a name has set.
Of course, a client could just guess, like just multicall-resolve the most common coin types and text records. But if the goal is to resolve and display all currently set records, then that approach wonāt work, especially for arbitrary text records.
Proposal:
A new resolver profile (interface), and/or a standard text record, that resolvers can use to provide this āmeta-resolutionā information directly to clients:
- List of existing subnames
- List of resolvable text record keys
- List of resolvable coin types
- Other things? (Future-proofing?)
For example, an interface like this:
interface IMetaResolver {
// @notice Returns the list of labels of existing subnames for an ENS name
// @param node A nodehash for an ENS name
// @return The array of labels for existing subnames
function subLabels(bytes32 node) external view returns (string[] subLabels);
// @notice Returns the list of resolvable text record keys for an ENS name
// @param node A nodehash for an ENS name
// @return The array of text record keys
function texts(bytes32 node) external view returns (string[] texts);
// @notice Returns the list of resolvable coin types for an ENS name
// @param node A nodehash for an ENS name
// @return The array of coin types
function coinTypes(bytes32 node) external view returns (uint256[] coinTypes);
// @notice Returns the text meta-information associated with a key for an ENS name
// @param node A nodehash for an ENS name
// @return The text meta-information
function metaText(bytes32 node, string key) external view returns (string value);
}
Clients can then check whether a resolver supports that interface, and if so, call one or more of the above methods to query that data.
Example:
- I want to display all text records for
validator.nfty.eth - Call
texts(nodehash('validator.nfty.eth'))- Uses CCIP-read off-chain resolution
- Returns
dm,email,twitter, etcā¦
- Multicall the resolver to resolve those text records
Or:
- I want to display all
*.cb.idsubnames - Call
subLabels(nodehash('cb.id'))- Uses CCIP-read off-chain resolution
- Returns the list of subnames, like
validator,serenaefansubs, etc.
Rationale / Backwards Compatibility:
Another option is to use a particular text record for this, like eth.ens.meta. The value of which would be a JSON Object, conforming to a particular specification (in the draft here).
Currently, I have both the interface and the text record as options in the ENSIP. But this can certainly be simplified, if we think only one or the other would be better. The strongly-typed interface is nicer, but on the other hand a text record would allow even pre-existing resolvers to start using this standard.
The other bit Iām not sure on is the metaText (or additional properties in the JSON Object). The idea is to future-proof the standard, since we donāt know what additional pieces of āmeta-resolutionā information might be needed in the future. But this could be removed as well if we think it isnāt needed.
Anyway, feedback welcome, feel free to beat it up: ENSIP-##: Off-chain Name Meta-Resolution
Thanks to the Nftychat team for giving me the idea, as I was assisting with their *.nfty.eth off-chain names in a support ticket, and explaining why not all records (like their custom records) are showing up in the ENS Manager App.
