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.
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.
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.
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:
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 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.
Name service mappings can also be added to the 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 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.
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.
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.
Alice's Stargaze address as resolved by Stargaze Names:
[email protected]
Alice's Osmosis address as resolved by Stargaze Names:
[email protected]
Alice's Stargaze address as resolved by ICNS:
[email protected]
Alice's Cosmos Hub address as resolved by ICNS:
[email protected]
This approach also works on chains with multiple name services. For example:
[email protected] -> Juno address as resolved by dens
[email protected] -> Stargaze address as resolved by IBC Names
[email protected] -> Osmosis address as resolved by IBC Names
Stargaze Names will rebrand to Stargaze Name Service (SNS) if this approach is implemented.
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 [email protected] 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.
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.
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 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.
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.