# Interchain Name System

There are many name services 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](https://en.wikipedia.org/wiki/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](https://www.starname.me/), and another mints `jake.stars` on Osmosis's [ICNS](https://www.icns.xyz/), and another mints `jake.stars` on [Stargaze Names](https://www.stargaze.zone/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]((https://en.wikipedia.org/wiki/Domain_Name_System)):

> 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 it makes much more sense 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](https://cosmology.tech/) already has an [implementation](https://github.com/cosmology-tech/cosmos-kit/blob/c5cab5a473cf6c2f5024a4055de65f3639cb2442/packages/core/src/config.ts) 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](https://www.junonetwork.io/) already, which gets `.juno`?

## Interchain TLD Governance
Well there is no need to reinvent the wheel too much here. There is already [SLIP-0173](https://github.com/satoshilabs/slips/blob/master/slip-0173.md#slip-0173--registered-human-readable-parts-for-bip-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](https://github.com/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](https://daodao.zone) that would do for the Interchain Name System similarly to what [ICANN](https://en.wikipedia.org/wiki/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](https://github.com/satoshilabs/slips/blob/master/slip-0173.md#slip-0173--registered-human-readable-parts-for-bip-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](https://github.com/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](https://github.com/cosmos/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](https://daodao.zone) 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](https://twitter.com/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".*