Interchain Name System
Taking inspiration from DNS to create human readable names for the Interchain.
There are many nameservices in the Interchain, and as more chains join, this number will only proliferate.
While there has been much debate about which nameservice should be the one true Interchain nameservice. The reality is that there are already many and will inevitably be more as the Interchain grows.
So how do we move forward? How do we create an Interchain nameservice that best aligns with the vision of the Internet of Blockchains? This post tries to explore a path forward, taking inspiration from the Domain Name System (DNS).
Fragmentation is not good UX
Before we get into the proposal, itâs important to outline whatâs at stake, and why if we donât act, the UX of the Interchain will suffer enormously.
Current âInterchainâ nameservices allow users to mint names for all the other chains in the Interchain. While this has been done in the name of âgood UXâ, it ultimately leads to fragmentation and confusion. If someone mints jake.stars
on Starname, and another mints jake.stars
on Osmosisâs ICNS, and another mints jake.stars
on Stargaze Names, etc⌠which is the real jake.stars
?
The answer is whatever the integrators choose to implement. But this leads to fragmentation and anarchy. Keplr wallet chooses ICNS, Station wallet goes with a Terra nameservice, Cosmostation creates their own, Metamask support is finally added and they choose ENS, apps launch with their own nameservice⌠chaos.
Imagine trying to pay someone in such a world? The names become meaningless and worth less. The current implementation of âInterchainâ nameservices donât feel very Internet-like at all.
Imagine if to look up google.com
a user had to choose which domain servers to use? Picture a world in your mind where different browsers and phones all used different nameservices, where google.com
would point to different things based on which browser you used. What would the Internet be like if it wasnât for DNS?!
The reality of the Interchain is that itâs decentralized. There will be many more nameservices, how do we prevent user confusion?
DNS but for the Interchain
From the Wikipedia article on DNS:
The Domain Name System delegates the responsibility of assigning domain names and mapping those names to Internet resources by designating authoritative name servers for each domain. Network administrators may delegate authority over sub-domains of their allocated name space to other name servers. This mechanism provides distributed and fault-tolerant service and was designed to avoid a single large central database.
There is much we can learn from the Domain Name System. The concept of top-level domains is especially relevant. At a high level, a top-level domain (i.e. .com
, .org
, .zone
, etc.) tells a browser which nameservice to use to look up a website server. Many of the top-level domains are governed by separate entities, and new ones can be added.
We can use such a system for the Interchain! .stars
, .osmo
, .juno
, .cosmos
, .evmos
, .secret
, .ens
, and others could all resolve on their respective chain or service. .stars
would resolve on Stargaze, .osmo
on Osmosis, etc.
In many ways, such a system is more similar to what users are already used to with the Internet. There is only one jake.stars
, just like there is only one google.com
. The mental overload is greatly reduced, no need to think about which nameservice is used or which chain you are trying to get an address for.
Implementation
Itâs not hard to implement such a system. The Cosmology GitHub repository already has an implementation with a proof of concept. From an integratorâs perspective, such as wallets or dapp developers, resolving names could be made truly easy to implement with Open Source libraries.
Some JavaScript code for resolving names in the Interchain might soon look like this:
import { nameResolver } from '@cosmos/ins';
// Interchain name resolver looks up dan.stars on the Stargaze chain
nameResolver('dan.stars'); // => stars1lkjsadfljsdflkjsdflkjsdf
// This uses the Stargaze name service to get an osmosis address
nameResolver('dan.stars', 'osmosis'); // => osmo1alskjflkjsdflkjsdfkjsdf
Importantly, an osmo
or juno
address could be resolved from jake.stars
. Crypto is complicated enough, why add to the mental overhead? With good UX we can abstract away the complexities of IBC so that users donât have to think of which name to use with which chains, instead dapp developers provide sensible and intuitive defaults.
Such a system may require slight changes to some of the current nameservice smart contracts, but these are minor and relatively trivial. In the meantime, such a system can be implemented entirely in Open Source frontend libraries.
Great, but how do we control who gets what âtop-level domainâ? For example, there are many nameservices on Juno Network already, which gets .juno
?
Interchain TLD Governance
Well there is no need to reinvent the wheel too much here. There is already SLIP-0173, a registry of human readable parts for wallet addresses. Cosmos chains already use this, and itâs to ensure there isnât confusion around account addresses (there is only one chain allowed to use the bc
prefix, and thatâs Bitcoin). All Cosmos chains submit their name to this registry when they launch.
This seems like a natural place to start. .stars
home of the $STARS token resolves on the Stargaze blockchain, and so on. On permissionless chains with multiple nameservices such as Juno, on chain governance could signal which nameservice should be used for the chain (the others would have to apply for different TLDs).
There is already the Cosmos Chain Registry, which contains a bunch of standardized information about all of the Interchain. There has been widespread agreement amongst ecosystem players to use this repository as a central point of collaboration, and it seems like a natural initial home for mapping out nameservices and TLDs.
Perhaps we could even coordinate it with an Interchain DAO that would do for the Interchain Name System similarly to what ICANN has done for the Domain Name System?
As disciples of decentralization, we shouldnât stop with GitHub repository or even a DAO. As technologies like Mesh Protocols and IBC Applications evolve there are possibilities to govern such an important part of the Interchain as coalitions of sovereign chains. Perhaps a tokenless chain run entirely by a mesh of participants?
That said, we have to start somewhere. The V1 of an Interchain Name System could simply be:
Chains use the SLIP-0173 to register their token and name (which they already do).
Chain decide if they want their own nameservice or delegate to another.
A list of nameservices is maintained in the Cosmos Chain Registry which already contains a bunch of useful cross-chain info.
Open Source JavaScript libraries are published to make it easy for integrators like wallets to support the emerging INS, including widely used packages such as CosmJS.
Repository governance is used to make decisions and enforce norms (i.e. no one but the Cosmos Hub should be able to create a
.cosmos
nameservice as they have the SLIP-0173).Work can begin on how to make this even more decentralized and robust.
Conclusion: Better for the Ecosystem
The current implementations of âInterchainâ nameservices are in reality single chain nameservices. Going down the present path of projects competing to be the one nameservice to rule them all will ultimately lead to fragmentation and poor user experience. Moreover, the existing nameservices donât live up to Cosmos values in the sense that they donât honor the sovereignty of other chains to create their own namespaces. A world with different wallets and dapps all using different names will be confusing to end users, make us the laughing stock of investors, and allow for critics to rightly criticize how the âInternet of Blockchainsâ isnât much like the Internet at all.
Luckily, itâs early. This fate is easily avoidable if as an ecosystem we can learn from Web 1.0 and create a true Interchain Name System.
Indeed, I would argue this will increase the value of the different nameservices. Similarly to domains, projects will want to grab their name on every nameservice they care about. For example, DAO DAO will want to grab daodao.stars
, daodao.osmo
, daodao.juno
, etc. just to make sure no one squats them.
How can we get wallets to agree to use the same standard? Here, the technical implementation is simple compared to the politics. There are many discussions that need to happen to get this moving, but Iâm optimistic about the outcome. While we may have our sovereign chains and communities, weâre all tied together by IBC. What is good for the Interchain is good for all of us. If enough projects and users raise their voices, I have no doubt that weâll make something powerful and lasting.
Special thanks to Dan Lynch (@pyramation) for pushing me to write this.
If you enjoyed this article and agree with the general direction, please join me in advocating for an Interchain Name System that lives up to the values of the Cosmos and the idea of the âInterchainâ.
I really like this idea, and I think you touched a very important topic.
Like it or not, Web2 is highly optimized for UX, we need to push much harder towards a better UX, part of the reason why not everyone is using web3 yet is because it is hard to use/start using.