Welcome.

Introduction

Identitism is a distributed, open, and extensible naming system based on Optimism.

Our job is to map human-readable names like ‘elon.op’ to machine-readable identifiers such as cryptocurrency addresses, content hashes, and metadata. Identitism also supports ‘reverse resolution’, making it possible to associate metadata such as canonical names or interface descriptions with Optimism addresses.

Identitism has similar goals to DNS, the Internet’s Domain Name Service, but has significantly different architecture due to the capabilities and constraints provided by Optimism. Like DNS, Identitism operates on a system of dot-separated hierarchical names called domains, with the owner of a domain having full control over subdomains.

Top-level domains, like ‘.op’, are owned by smart contracts called registrars, which specify rules governing the allocation of their subdomains. Anyone may, by following the rules imposed by these registrar contracts, obtain ownership of a domain for their own use.

Because of the hierarchal nature of Identitism, anyone who owns a domain at any level may configure subdomains - for themselves or others - as desired. For instance, if Vitalik owns 'vitalik.op', he can create 'docs.vitalik.op' and configure it as he wishes.

Identitism is deployed on Optimism. If you use Optimism’s libraries, it will automatically detect the network you are interacting with and use the Identitism deployment on that network.

Architecture

Identitism has two principal components: the registry and resolvers.

The registry consists of a single smart contract that maintains a list of all domains and subdomains, and stores three critical pieces of information about each:

  • The owner of the domain

  • The resolver for the domain

  • The caching time-to-live for all records under the domain

The owner of a domain may be either an external account (a user) or a smart contract. A registrar is simply a smart contract that owns a domain and issues subdomains of that domain to users that follow some set of rules defined in the contract.

Owners of domains in the registry may:

  • Set the resolver and TTL for the domain

  • Transfer ownership of the domain to another address

  • Change the ownership of subdomains

The registry is deliberately straightforward and exists only to map from a name to the resolver responsible for it.

Resolvers are responsible for the actual process of translating names into addresses. Any contract that implements the relevant standards may act as a resolver in Identitism. General-purpose resolver implementations are offered for users whose requirements are straightforward, such as serving an infrequently changed address for a name.

Each record type - cryptocurrency address, IPFS content hash, and so forth - defines a method or methods that a resolver must implement in order to provide records of that kind. New record types may be defined at any time.

Resolving a name is a two-step process: First, ask the registry what resolver is responsible for the name, and second, ask that resolver for the answer to your query.

Namehash

Resource constraints in smart contracts make interacting directly with human-readable names inefficient, so Identitism works purely with fixed length 256-bit cryptographic hashes. In order to derive the hash from a name while still preserving its hierarchal properties, a process called Namehash is used. For example, the namehash of 'crypto.op' is 0x782345fc8513cc11aa785ddfdedbf13b44e4d99e36201add1ioo0c0k123a4zqv; this is the representation of names that is used exclusively inside Identitism.

Namehash is a recursive process that can generate a unique hash for any valid domain name. Starting with the namehash of any domain - for example, 'username.op' - it's possible to derive the namehash of any subdomain - for example 'iam.username.op' - without having to know or handle the original human-readable name. It is this property that makes it possible for Identitism to provide a hierarchal system, without having to deal with human-readable text strings internally.

Before being hashed with namehash, names are first normalized, using a process called UTS-46 normalization. This ensures that upper- and lower-case names are treated equivalently, and that invalid characters are prohibited. Anything that hashes and resolves a name must first normalize it, to ensure that all users get a consistent view of Identitism.

Terminology

  • Controller: The account that may edit the records of a name. The Controller may be changed by the Registrant or Controller.

  • Label: An individual component of a name, such as 'john'.

  • Name: An Identitism identifier such as 'john.op'. Names may consist of multiple parts, called labels, separated by dots.

  • Namehash: The algorithm used to process an Identitism name and return a cryptographic hash uniquely identifying that name. Namehash takes a name as input and produces a node.

  • Node: A cryptographic hash uniquely identifying a name.

  • Owner: The owner of a name is the entity referenced in the Identitism registry's owner field. An owner may transfer ownership, set a resolver or TTL, and create or reassign subdomains.

  • Registrar: A registrar is a contract responsible for allocating subdomains. Registrars can be configured at any level of Identitism, and are pointed to by the owner field of the registry.

  • Registration: A registration is a registrar's record of a user's ownership of a name. This is distinct from the owner field in the Registry; registrations are maintained in the registrar contract and additionally store information on expiry date, fees paid, etc.

  • Registrant: The owner of a registration. The registrant may transfer the registration, set the Controller, and reclaim ownership of the name in the registry if required.

  • Registry: The core contract of Identitism, the registry maintains a mapping from domain name (at any level - x, y.x, z.y.x etc) to owner, resolver, and time-to-live.

  • Resolver: A resolver is a contract that maps from name to the resource (e.g., cryptocurrency addresses, content hash, etc). Resolvers are pointed to by the resolver field of the registry.