EIPs/EIPS/eip-634.md

122 lines
4.0 KiB
Markdown
Raw Normal View History

---
eip: 634
Switch validator to eipv (#2860) * switch to eipv * fix * fix * 1153 remove trailing whitespace * remove file name checks * 615 remo whitespace before comma * 884 remove extra single-quotes * 1337 remove whitespace before comma * 1057 remove extra spaces after comma * 2470 update created date to Y/M/D format * 1078 update required eips to be in ascending order * 2477 update required eips to be in ascending order * 1271 remove extra whitespace * 2767 required eipupdated to be in ascending order * 2525 update created date to Y/M/D format * 2458 remove trailing whitespace * 1884 remove trailing whitespace * 712 authors should be on a single line * 601 remove extra whitespace * 1485 remove unneeded parentheses * 634 remove trailing whitespace * 2657 update discussions-to to correct spelling * 2009 remove trailing whitespace * 998 required eips updated to be in ascending order * 1186 remove trailing whitespace * 1470 remove extra whitespace * 1895 update created date to Y/M/D format * 2747 remove extra whitespace * 1613 remove leading whitespace * 1571 can'have both handle and email in author field * 1191 remove trailing whitespace * 1973 remove trailing whitespace * 196 don't wrap title field * 1679 required eips must be in ascending order * 1620 author can't have both handle and email * 197 don't line wrap title field * 2378 remove extra newline * 1355 author can't have both handle and email * 698 update created date to Y/M/D format * 2193 required eips must be in ascending order * 214 remove extra info after author email * use v0.0.3 of eipv * 1 remove malformed field * bump eipv to v0.0.4 * cache eipv build * 1485 remove extra author info * 2771 removing extra whitespaces
2020-08-10 10:18:25 -06:00
title: Storage of text records in ENS
author: Richard Moore (@ricmoo)
type: Standards Track
discussions-to: https://github.com/ethereum/EIPs/issues/2439
category: ERC
status: Draft
created: 2017-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:
function text(bytes32 node, string key) constant returns (string text);
The 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](https://en.wikipedia.org/wiki/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.
## Test Cases
TBD
## Implementation
None yet.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).