The topic for this call for feedback is a flexible and narrowly-defined interface standard for generalized “Name Services” on Radix.

Introduction

Systems like Ethereum’s “ENS” (Ethereum Name Service) have shown that it is useful and desirable to have a standardized way for blockchain accounts to have human-readable names assigned to them that can be used in place of unwieldy addresses.

The most flexible and open way to support such services is to agree on a standard interface on Radix that will allow both component logic and clients – notably the Radix Wallet – to use any “name service” the user desires to automatically look up and discover names assigned to accounts, without special app-specific integrations.

This is a proposal for a flexible and narrowly-defined interface standard for generalized “Name Services” on Radix. The proposed standard does not seek to constrain the internal functioning of such services, nor constrain the specific features that they may offer. For example, this interface proposal is agnostic to things like namespacing, and methods of name ownership and management.

The intention is to seek community feedback toward swift agreement on a standard that would enable the Radix Wallet, and other clients and libraries, to implement it. This would allow developers to create a wide variety of name/alias/domain services that comply with this standard and have instant discovery and lookup support in the Radix Wallet, letting users conveniently make use of names in place of complex account addresses.

Thanks to the XRD.Domains team, who provided much practical and helpful product requirement input that went into this proposal.

‍

Goals for the Name Service Interface Standard

• Allow both client software and on-ledger components to “know” how to do name lookups on any Name Service, given only an address for a Name Service Provider component that implements the interface standard.
• Allow association of arbitrary name strings to account addresses.some text
  • Each name can only point to one account, so a given name may be used directly in place of an account address without disambiguation.
  • Multiple names can point to one account.
  • Names offered by different Name Services can point to one account.
  • The standard should be extensible to later support other kinds of entity lookups beyond accounts.
• Allow an account to claim its preferred name (within a specified Name Service) for reverse lookups.some text
  • That claim should be verifiable from the Name Service.
• Allow both on and off-ledger lookups of a name, returning its associated account address.
• Have all necessary name registration information stored on-ledger for full decentralization.some text
  • No required app-specific off-ledger API calls.
• Allow the operator of a Name Service to charge royalties for on-ledger name lookups or selectively authorize on-ledger lookups by badge.
• Allow the operator of a Name Service full flexibility to define how their system enables registration and management of name associations and how the rights to manage names are controlled.some text
  • This includes the desired possibility of having control of a name linked to ownership of an NFT created by the system.
• Allow a Name Service to be associable with a dApp Definition using standard 2-way metadata linking.

‍

Goals for Radix Wallet Adoption of the Standard

• Allow users to easily specify a desired Name Service to use, via an on-ledger component address alone.
• Identify and describe the Name Service to the user by the metadata set on a linked dApp Definition.
• Allow users to enter a name string in place of a Radix account address and have it automatically resolved to an address returned by their preferred Name Service.
• Display a name in place of a Radix account address – where the account has claimed a name to use, and that name’s association can be confirmed with a Name Service the wallet user has added.

‍

Proposed Interface Standard

The proposed standard is as simple as possible, staying away from implementation details and differentiating features, and focusing only on the minimum method interface and metadata standards required to meet the goals above in a common way.

The concept of the standard is simply to standardize the lookup of name strings that each point to an account address. All else is implementation detail that need not be standardized. For example, a dApp may be expected to have its own unique systems to namespace their names and control the rights to add and modify names.

The proposed compliant Name Service system only includes two required parts:

• A Name Service Provider component - Each Name Service deploys its own Name Service Provider component that implements a method and metadata standard and offers lookups against its own name records.
• Account components – The owners of various accounts may wish to declare a discoverable name to use for that account, provided by a preferred Name Service Provider.

The standards for these components are proposed as follows:

Name Service Provider Component

Metadata

To be compliant, a Name Service Provider component MUST apply the following metadata to self-identify as compliant:

To provide the best user experience, a Name Service Provider component optionally MAY set metadata to associate itself to a dApp Definition in the standard way as for any other component. The Radix Wallet will use the dApp Definition to describe the Name Service, and it may similarly be useful to other off-ledger clients.

Method

To be compliant, a Name Service Provider component MUST implement the following method interface for lookups:

‍

A note on extensibility of this interface:

If it becomes desirable for Name Service Providers to offer lookups of entities other than account address, it is envisioned that the standard could be expanded in a couple of ways:

• Adding specific lookup methods for certain standard types of entity, eg. perhaps get_validator_from_name.
• Adding a general-purpose lookup method able to return any type of return (but requiring a more complex process of implementing the interface and interpreting the result.)

Such extensions can be considered as the use cases, and integrations of them in clients like the Radix Wallet, become more clear.

Account Component (as pointed to by a name)

A Radix account that a name service points to optionally MAY include the following if it wishes to have a single claimed discoverable name:

Metadata

‍

Example System Diagram

‍

Example User Journeys

Adding compliant Name Service options to use in the Radix Wallet

• User goes to the Radix Wallet’s preferences and chooses the “Add Name Service” option.
• The user is given a field to enter a component address. The user chooses the option to use a QR code and scans a QR code provided by the Name Service website. (They could of course alternatively simply copy the component address from the relevant website, if it is already on their mobile phone.)
• The wallet looks up this component address and verifies that it has the component_type metadata field set to "name service provider."
• The wallet sees that the component has a correctly confirmed link to a dApp Definition in its metadata, to a dApp called EZName.
• The wallet lists EZName as a Name Service option and, because it is the first added, automatically sets it as the default to use when entering a name to lookup.
• (User can add additional Name Services in the same way, but one must always be selected as the default. Others will only be used as trusted Name Services for reverse lookups - more on this below.)

‍

Using a name to send money to an account in the Radix Wallet

• User has previously configured EZName as their preferred Name Service.
• User arrives at the Radix Wallet’s “transfer” screen and taps to choose a recipient account.
• In the account address field, user types “bob dobolina.”
• The wallet calls EZName’s get_account_from_name method with "bob dobolina" as the name, and receives a return of acco...d85md2 (full address.)
• The wallet shows that the name has been found and the user can proceed.
• The name of the receiving account is shown as “bob dobolina”, and the address for that account is shown as acco...d83md2.
• The transaction can be completed as normal, using that address.

‍

Showing an account by its preferred name in the Radix Wallet

(Note: this feature may be incomplete or not present in the initial Radix Wallet implementation.)

• User has previously configured EZName as their preferred Name Service (see above.)
• User arrives at the Radix Wallet’s “transfer” screen and taps to choose a recipient account.
• User pastes in the address acco...d85md2.
• The wallet checks this account and sees that it has correctly set both claimed_name (set to "bob dobolina") and claimed_name_service_provider metadata fields.
• The wallet calls the indicated Name Service Provider component’s get_account_from_name with "bob. dobolina" and receives the response acco...d85md2 - a match for the address that claimed the name.
• In the transfer summary, the wallet shows the name of the account as bob dobolina.

‍

Setting a preferred name for one’s own account

• User owns the name "funky.homosapien" on EZName (where EZName defines what exactly that ownership means.)
• User logins in to the EZName dApp website; the website knows (however it defines it) that this is the user that owns "funky.homosapien".
• User goes to an EZName page called “Claim Discoverable Name”, sharing their account acco...020nz3 with proof they own it.
• User clicks on the website to request that "funky.homosapien" be set as the discoverable name for their account.
• EZName website builds a transaction that sets the claimed_name metadata field on acco...020nz3 with "funky.homosapien" and sets the claimed_name_service_provider metadata field to the component address of the EZName name service provider.
• User signs and submits the transaction in their Radix Wallet as normal.

‍

Respond to the Call

The RDX Works team is looking for general feedback from a developer audience on how this standard is defined before it is settled and Radix Wallet functionality is built around it. Perhaps you are considering building a name service yourself, or are building an app that would want to easily consume a variety of name services.

The forum for feedback and community discussion on this request for feedback is a Discord thread that has been created for this topic. Head over there, post your thoughts, and members of the RDX Works team will be there to discuss.

The RDX Works team is aware of the strong community desire for this sort of functionality in the Radix Wallet, so will be looking to come to conclusions on this standard in the coming weeks. This can then be used as a guiding specification to concretely put the feature on the wallet development roadmap for the near future.

‍