# A Tale of Two Name Services

## Problem

The name `alice` can exist on multiple chains, owned by different accounts.

For example, `alice.stars` can point to a stars address that is associated with a different key than `alice.stars` on ICNS.

## Solution 1: Merge ICNS and Stargaze Names

Merging both services is difficult because the Twitter name `alice` may have been bought by a different account that bought `alice` on Stargaze. One of the accounts will have to give up their name in a merge.

However, if there is an attempt to merge, Stargaze is opposed to the Twitter namespace hard spoon, even if temporary. Stargaze received a lot of negative feedback when experimenting with a similar approach in an early beta.

If a solution to merge conflicts can be found, Stargaze Names is not opposed to merging with ICNS. However, a long-term solution that respects chain sovereignity is probably best for the Interchain.

## Solution 2: DNS-like Resolution

### Option A: Each chain maintains and resolves their own namespace

**Advantages**: No name conflicts.
**Disadvantages**: Running a name service may not be the domain expertise of every chain. Wallets will have to integrate with every name service for every chain.

### Option B: Each chain opts-in to a single canonical name service

**Advantages**: No name conflicts.
**Disadvantages**: Requires explicit action from each chain. Possible to not have coverage across Cosmos. Wallets will have to integrate with multiple name services.

Currently both ICNS and Stargaze Names are opt-out. This results in name conflicts. This approach requires both ICNS and Stargaze Names to switch to opt-in. Opt-in status can be managed by a DAO on a neutral chain. The best place for this is Cosmos Hub. There’s a few ways to do this:

#### x/names module

This will act like a root server. It will maintain the association between each chain and its name service.

JSON storage example:

{
    "chain": 
    {
        "prefix": "stars",
        "resolver": "sns-1.0"
    }, 
    {
        "prefix": "osmo",
        "resolver": "icns-1.0"
    }, 
}

Cross-chain queries with [ICS-31](https://github.com/cosmos/ibc/tree/main/spec/app/ics-031-crosschain-queries) can be used by x/names to resolve names for all chains. However, the more common client of names will be wallets, block explorers, and other app UIs. These can use APIs that consume x/names.

This module can include a custom governance proposal for chains to opt-in to a name service.

The Stargaze Core Team volunteers to build this module for Cosmos Hub if this approach is chosen by the community.

#### Cosmos Chain Registry

Name service mappings can also be added to the [Cosmos Chain Registry](https://github.com/cosmos/chain-registry).

For example, a new field can be added to `chain.json`:

"name_resolver": "sns-1.0"

This can be a very fast and light-weight approach to solve this problem, and act as a stop-gap solution until an on-chain solution is built.

#### Cosmos Hub Governance

Cosmos Hub Governance can also be used for chains to opt-in. For example a text proposal can be submitted for each chain that suggests which name service to use. Although not automated, wallets and block explorers have a single source of truth for name service mappings.

### Option C: Each chain opts-out of all the name services *except* one

**Advantages**: Doesn’t require explicit action from each chain. Cosmos-wide coverage.
**Disadvantages**: Wallets will have to integrate with multiple name services. If a chain doesn’t opt-out of both ICNS and Stargaze Names, there will be conflicts.

### Option D: Fully-qualified name (Recommended)

**Advantages**: Doesn’t require any governance. Same format as an email address.
**Disadvantages**: Wallets will have to integrate with multiple name services. Has an extra component compared to ENS names.

This approach includes the name service resolver in the name itself, so resolution is built into the name.

[name]@[chain_prefix].[resolver]

This format reads just like an email address, making it less of a UX burden despite having three components. The `chain_prefix` is the human readable part from [SLIP-0173](https://github.com/satoshilabs/slips/blob/master/slip-0173.md).

#### Examples

Alice's Stargaze address as resolved by Stargaze Names:
`[e-mail]`

Alice's Osmosis address as resolved by Stargaze Names:
`[e-mail]`

Alice's Stargaze address as resolved by ICNS:
`[e-mail]`

Alice's Cosmos Hub address as resolved by ICNS:
`[e-mail]`

This approach also works on chains with multiple name services. For example:
`[e-mail]` -> Juno address as resolved by dens
`[e-mail]` -> Stargaze address as resolved by IBC Names
`[e-mail]` -> Osmosis address as resolved by IBC Names

Stargaze Names will rebrand to Stargaze Name Service (SNS) if this approach is implemented.

#### UX/UI Considerations

Since fully-qualified names (FQNs) are longer than typical usernames, some considerations have to made for the UI layer. This is a problem that has already been solved by email clients, so we can look to them for solutions.

Apps that predominantly use one name service can drop the components after the `@` in the UI, and only show it upon hover or copy. For example, on Stargaze Marketplace, it's enough to just show the first componet of the FQN. So `[e-mail]` can be shown just as `alice`.

Wallets can make use of drop-downs or auto-complete to aid users in inputting names. For example after inputting an `@`, a selection box with `osmo.sns` and `osmo.icns` can be shown if the user is connected to Osmosis. Wallets can also save frequently used FQNs and auto-complete them, similar to Gmail.

## Conclusion

**Solution 2, Option D is the most straight-forward solution**. It doesn't require merging name services, and doesn't require any governance overhead. It will be up to wallets and block explorers to integrate new name services.

Solution 2, Option B is the next best. It provides better UX due to shorter names, but requires a central authority (like the Hub) to manage opt-in status.

## Miscellaneous

### IBC Support

Stargaze Names plans to launch Names outposts on CosmWasm chains that opt-in to using it. ICA and ICQ support will be added for non-CosmWasm chains to integrate.

### DID Support

DID support can always be added later to name services. It should probably be implemented at the account-level, not only in names. However, implementing support now is probably a premature optimization.

Note that DID documents for most names serivces can already be added via text records.

## Credits

The ideas in this document came from discussions and feedback from Michael Scotto, Fabien Penso, Rick Dudley, Sam Hart, larry0x, Jake Hartnell, Dan Lynch, and Aleks Bez.