AlertSourceDiscuss
Skip to content

ERC-634: Storage of text records in ENS

Profiles for ENS resolvers to store arbitrary text key/value pairs.

🚧 StagnantERC

Stagnant

This EIP has had no recent activity for at least 6 months, and has automatically been marked as stagnant. This EIP should not be used in production.

If you are interested in helping move this EIP to final, create a PR to move this EIP back to Draft and add yourself as an author, and an EIP editor will help guide you through the process. Thank you!

AuthorsRichard Moore (@ricmoo)
Created2017-05-17

Abstract ​

This EIP defines a resolver profile for ENS that permits the lookup of arbitrary key-value text data. This allows ENS name holders to associate e-mail addresses, URLs and other informational data with a ENS name.

Motivation ​

There is often a desire for human-readable metadata to be associated with otherwise machine-driven data; used for debugging, maintenance, reporting and general information.

In this EIP we define a simple resolver profile for ENS that permits ENS names to associate arbitrary key-value text.

Specification ​

Resolver Profile ​

A new resolver interface is defined, consisting of the following method:

solidity
interface IERC634 {
  /// @notice Returns the text data associated with a key for an ENS name
  /// @param node A nodehash for an ENS name
  /// @param key A key to lookup text data for
  /// @return The text data
  function text(bytes32 node, string key) view returns (string text);
}

The EIP-165 interface ID of this interface is 0x59d1d43c.

The text data may be any arbitrary UTF-8 string. If the key is not present, the empty string must be returned.

Global Keys ​

Global Keys must be made up of lowercase letters, numbers and the hyphen (-).

  • avatar - a URL to an image used as an avatar or logo
  • description - A description of the name
  • display - a canonical display name for the ENS name; this MUST match the ENS name when its case is folded, and clients should ignore this value if it does not (e.g. "ricmoo.eth" could set this to "RicMoo.eth")
  • email - an e-mail address
  • keywords - A list of comma-separated keywords, ordered by most significant first; clients that interpresent this field may choose a threshold beyond which to ignore
  • mail - A physical mailing address
  • notice - A notice regarding this name
  • location - A generic location (e.g. "Toronto, Canada")
  • phone - A phone number as an E.164 string
  • url - a website URL

Service Keys ​

Service Keys must be made up of a reverse dot notation for a namespace which the service owns, for example, DNS names (e.g. .com, .io, etc) or ENS name (i.e. .eth). Service Keys must contain at least one dot.

This allows new services to start using their own keys without worrying about colliding with existing services and also means new services do not need to update this document.

The following services are common, which is why recommendations are provided here, but ideally a service would declare its own key.

  • com.github - a GitHub username
  • com.peepeth - a Peepeth username
  • com.linkedin - a LinkedIn username
  • com.twitter - a Twitter username
  • io.keybase - a Keybase username
  • org.telegram - a Telegram username

This technique also allows for a service owner to specify a hierarchy for their keys, such as:

  • com.example.users
  • com.example.groups
  • com.example.groups.public
  • com.example.groups.private

Legacy Keys ​

The following keys were specified in earlier versions of this EIP, which is still in draft.

Their use is not likely very wide, but applications attempting maximal compatibility may wish to query these keys as a fallback if the above replacement keys fail.

  • vnd.github - a GitHub username (renamed to com.github)
  • vnd.peepeth - a peepeth username (renamced to com.peepeth)
  • vnd.twitter - a twitter username (renamed to com.twitter)

Rationale ​

Application-specific vs general-purpose record types ​

Rather than define a large number of specific record types (each for generally human-readable data) such as url and email, we follow an adapted model of DNS's TXT records, which allow for a general keys and values, allowing future extension without adjusting the resolver, while allowing applications to use custom keys for their own purposes.

Backwards Compatibility ​

Not applicable.

Security Considerations ​

None.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Richard Moore, "ERC-634: Storage of text records in ENS[DRAFT]," Ethereum Improvement Proposals, no. 634, 2017. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-634.