We are proposing Alias - a semantic standard for identifying on-chain resources by human-readable qualifiers, supporting any type of data.
The dType Alias is a system for providing human-readable resource identifiers to on-chain content. A resource identifier is based on the type of data (identifier provided by dType, EIP-1900) and the data content (identifier provided by a dType Storage Contract, EIP-2157). It is a universal way of addressing content, supporting any type of data.
There are standards that currently address the need for attaching human-readable identifiers to Ethereum accounts, such as EIP-137. These standards are an attempt to bring domain names to Ethereum, following the same format as DNS: subdomain.domain.tld. This leaf -> root format is unintuitive and contradicts the semantic meaning that . has in programming languages, which is a root -> leaf connection (e.g. in OOP, when accessing an object's property). A more intuitive and widely used approach is a root->leaf format, used in file browsers, hierarchical menus, and even in other decentralized systems, which give unique identifiers to resources (e.g. 0x56.Currency.TCoin in Libra.
Moreover, EIP-137 is not flexible enough to address smart contract content, which can contain heterogeneous data that belongs to various accounts. For example, a PaymentChannel smart contract can have an domain name. However, the Alice-Bob channel data from inside the smart contract, cannot have a subdomain name. Having uniquely identified, granular resources opens the way to creating both human and machine-readable protocols on top of Ethereum. It also provides a basis for protocols based on functional programming.
This ERC proposes a set of separators which maintain their semantic meaning and provides a way to address any type of resource - from Ethereum addresses, to individual struct instances inside smart contracts.
Imagine the following dType types: SocialNetwork and Profile, with related storage data about user profiles. One could access such a profile using an alias for the data content: alice@socialnetwork.profile. For a PaymentChannel type, Alice can refer to her channel with Bob with alice-bob.paymentchannel.
This alias system can be used off-chain, to replace the old DNS system with a deterministic and machine-readable way of displaying content, based on the dType type's metadata.
The dType registry will provide domain and subdomain names for the resource type. Subdomains can be attributed recursively, to dType types which contain other complex types in their composition.
We define an Alias registry contract, that keeps track of the human-readable identifiers for data resources, which exist in dType storage contracts.
Anyone can set an alias in the Alias registry, as long as the Ethereum address that signs the alias data has ownership on the resource, in the dType storage contract. Storage contract data ownership will be detailed in EIP-2157. An owner can update or delete an alias at any time.
dtypeIdentifier: Type identifier from the dType registry, needed to ensure uniqueness of name for a dType type. dtypeIdentifier is checked to see if it exists in the dType registry. The dType registry also links the type's data storage contract, where the existence and ownership of the identifier is checked.name: user-defined human-readable name for the resource referenced by identifierseparator: Character acting as a separator between the name and the rest of the alias. Allowed values:
.: general domain separation, using root->leaf semantics. E.g. domain.subdomain.leafsubdomain.resource@: identifying actor-related data, such as user profiles, using leaf->root semantics. E.g. alice@socialnetwork.profile or alice@dao@eth#: identifying concepts, using root->leaf semantics. E.g. topicX#postY/: general resource path definition, using root->leaf semantics. E.g. resourceRoot/resourceidentifier: Resource identifier from a smart contract linked with dTypesignature: Alias owner signature on dtypeIdentifier, identifier, name, separator, nonce, aliasAddress, chainId.
nonce: monotonically increasing counter, used to prevent replay attacksaliasAddress: Ethereum address of Alias contractchainId: chain on which the Alias contract is deployed, as detailed in EIP-155, used to prevent replay attacks when updating the identifier for an alias.Content addressability can be done:
bytes32 identifiers directly, e.g. 0x0b5e76559822448f6243a6f76ac7864eba89c810084471bdee2a63429c92d2e7@0x9dbb9abe0c47484c5707699b3ceea23b1c2cca2ac72681256ab42ae01bd347daalice@socialnetworkBoth of the above examples will resolve to the same content.
Current attempts to solve content addressability, such as EIP-137, only target Ethereum accounts. These are based on inherited concepts from HTTP and DNS, which are not machine friendly.
With EIP-1900 and EIP-2157, general content addressability can be achieved. dType provides type information and a reference to the smart contract where the type instances are stored. Additionally, Alias uses the semantic meaning of subdomain separators to have a intuitive order rule.
Multiple aliases can be assigned to a single resource. Either by using a different name or by using a different separator. Each separator can have a specific standard for displaying and processing data, based on its semantic meaning.
Will be added.
Will be added.
An in-work implementation can be found at https://github.com/pipeos-one/dType/blob/master/contracts/contracts/Alias.sol. This proposal will be updated with an appropriate implementation when consensus is reached on the specifications.
Copyright and related rights waived via CC0.