In this article series, we present different use case scenarios, aiming to show our developer community examples and ideas on how you can solve typical problems using the Radix platform.
In this first article of the series, we explain a simple “Alias system” use case and how you can use the Radix platform to store information as if it was a regular database. Here you’ll learn the basic concepts to build the required methods such as “register an alias” or “resolve an alias” in your own application. You’ll also learn how you can leverage the features of the Radix ledger to implement a simple decentralized Alias system for your app, without having a central server to manage the database index or store the data.
An alias is an alternate name for someone or something. For instance, Bruce Wayne is known by his pseudonym, Batman. In computer science, an alias is an alternative name for a computer, object, file, device, person, group, or user. Usually, an alias is used to replace long strings with human-readable names. For example, website domain names and usernames are aliases. This allows users to memorize simple URL addresses like “Google.com” as opposed to a complex, non-intuitive list of Google servers IP addresses.
In distributed ledger technology platforms, each member (node or wallet) of the network is identified by its unique public key. It is very difficult to remember this long key you are messaging or sending tokens to. This creates friction for user experience. It is much easier to remember or store human-readable names like usernames and domain names.
Therefore we could say that the primary goal of aliases for distributed ledgers is to resolve human-readable names, like ‘@name’ or [email protected], into machine-readable identifiers, including Radix wallet addresses, nodes, and even content hashes, and/or other identifiers.
As we stated earlier, we want to build a decentralized Alias system for our application, without the need to have a dedicated server to manage the database index. Now let’s see how simple it is to achieve our goal, by interacting with the Radix ledger.
Assume our application wants to provide users with an alias system that supports simple alias (in the form of @name) and namespace alias (in the form of [email protected]). The implemented alias logic has to be part of the app client code, so all the wallets can interpret it in a consistent way.
First, in our application, we define an Account that will be our Namespace index and another Account that will represent our Root index. In the Namespace index, we add a record that points to the Root index, so we can handle any simple alias.
The elements of the system shown in the figure:
In our application, when a user wants to register a simple alias, we only have to read from the Namespace index account, verify that there is no namespace already registered with that alias, find the reference to the Root index account, and add a record in the Root for the requested user alias.
That alias record will point to a new Account used as a pointer reference, where we store the Alias owner, their current address, and any other relevant information. Note that the pointer account can be later updated only by the Alias owner, in case he needs to change any information.
As you might wonder, there’s no actual need to check for availability or duplicates, as alias is assigned in a first-come-first-served basis, and even if someone tries to register a name twice, the immutable ledger allows us to know who has the first valid registration.
In a similar way, when a user wants to register a namespace alias such as “[email protected]”, we have to read from the Namespace index account, find the reference to the requested namespace index Account, and then add a record in the “myapp” index for the requested user alias.
Depending on your application-specific needs, a namespace alias could be modified by the owner of the namespace (like email domains) or only by the alias owner (like a simple alias).
Let’s review how we can resolve aliases, so we can have a complete alias system in our application.
When we want to resolve an alias, we start by reading the Namespace index records, to find the right index for the alias. For a simple alias that would be the Root index, and for a namespace alias would be the defined namespace index. In case it’s a simple alias, next we start reading the Root index records, and we take the first match we find, to access the alias Pointer account.
We continue by reading the first record of the alias pointer to find the alias owner and keep reading any other record in the Pointer account to see if the alias had any additional update by the alias owner. Once we reach the end of the pointer data, we have the latest Account address for the simple alias. Instead, if it’s a namespace alias, next we start reading the defined namespace index records, and we take the first match we find.
In this scenario, the process is simplified, and the first match we find in the private namespace index is the Account address for the alias.
As seen, you can easily implement an alias system for any appwilication , without the need for a centralized database using the Radix decentralized ledger.
Radix is a new platform, like Bitcoin or Ethereum, but scalable and easy to build on. Instead of using blockchain, we started from scratch with a completely new design so that every person and device in the world could use the Radix ledger without centralization or compromise. We created building blocks for developers, making applications, tokens, and coins as easy to deploy as possible. It’s fast, it works and our test net is already live.
Visit the Radix knowledge base to learn more and find in-depth tutorials on building your next BIG thing on a fast and secure decentralized database.