mirror of
https://github.com/status-im/EIPs.git
synced 2025-01-27 07:05:47 +00:00
Added initial draft for an EIP regarding ENS text records. (#634)
* Added initial draft for an EIP regarding ENS text records. * Changed extended to vendor specific and added some keys. * Updated to new preamble header. * Initial Merkle-Airdrop EIP draft. * Added author Nick Johnsom and fixed typo. * Fixed typo. * Update and rename eip-draft-ens-text-data.md to eip-634.md * Removed draft for merkle air-drops.
This commit is contained in:
parent
8f1ecd1c14
commit
2b8c3e4690
71
EIPS/eip-634.md
Normal file
71
EIPS/eip-634.md
Normal file
@ -0,0 +1,71 @@
|
||||
---
|
||||
eip: 634
|
||||
title: Storage of text records in ENS
|
||||
author: Richard Moore <me@ricmoo.com>
|
||||
type: Standards Track
|
||||
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.
|
||||
|
||||
|
||||
### Initial Recommended Keys
|
||||
|
||||
Keys must be made up of lowercase letters, numbers and the hyphen (-). Vendor specific
|
||||
services must be prefixed with `vnd.`.
|
||||
|
||||
- **email** - an e-mail address
|
||||
- **url** - a URL
|
||||
- **avatar** - a URL to an image used as an avatar or logo
|
||||
- **description** - A description of the name
|
||||
- **notice** - A notice regarding this name;
|
||||
- **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
|
||||
- **vnd.twitter** - a twitter username (should it be prefixed with an @?)
|
||||
- **vnd.github** - a GitHub username
|
||||
|
||||
|
||||
## 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/).
|
Loading…
x
Reference in New Issue
Block a user