Let’s dive into what a domain is from a more technical perspective and go through the design of the name service.
What is a domain?
So what are the keys and data of a domain? Let’s start with the data.
The data inside a domain account represents an “object” called the Name Registry. The Name Registry is made up of two elements:
- The header: A fixed-length data structure (96 bytes) that contains three public keys
- The data/payload: A variable-length data array that can be used to attach arbitrary information to a domain
The name registry header
The name registry header is made up of 3 public keys:
- Parent name: Domain names are hierarchical. The parent name field contains the account address of the parent name, or the default zero public key (i.e 11111111111111111111111111111111) if no parent exists
- Owner: The owner of this name
- Class: The class of data this account represents. If set to the default public key the data class is unspecified
How can this be helpful? For certain use-cases, it might be interesting to associate data to a user-controlled domain which is verified by a third-party. One example of this could be a badge system : as an organization, we grant a badge to a user’s domain which they can claim. This badge is represented by a child domain the class of which we control. It contains details about the nature of the user’s achievements on our platform. This is great for discoverability since all we have to do to get a list of a user’s badges across different applications is to fetch the children of their domain.\
The data
The data section of the domain account can hold arbitrary binary data. Its length is not fixed and is set at domain registration. The owner of the domain can decide to store anything in this section.
How does it apply to .sol?
Let’s have a look at a real life example: .sol domain names.
The hierarchy of the Solana name service starts with the Root domain. This domain does not have a parent and does not have a class either. The Root domain is parent to the .sol TLD. The .sol TLD is a domain itself, and all .sol domain names (e.g bonfida.sol) are “children” (or subdomains) of the .sol TLD.
Similarly, dex.bonfida.sol is a “child” (or subdomain) of bonfida.sol. Strictly speaking, the entire URL for this domain would be: dex.bonfida.sol. (the root domain’s name is conventionally an empty string). However, by common convention, the last . in a URL is omitted.
How does it apply to Twitter handles
The Twitter TLD is also a domain held by the Root domain. And registered Twitter handles are children of the Twitter TLD. Therefore, @bonfida can be interpreted as the following domain bonfida.twitter.
What else can we do with this?
As previously said, domains are hierarchical and can be used to represent anything that has a parent/child relationship. Coincidentally, SNS Optics categories also have this parent/children design:
In order to push SNS Optics categories on-chain, we have decided to use the name service and use domain names to represent the belonging of a .sol domain to a particular category.
- 00.99-club.categories.
- 00.2-digit-palindromes.categories.