Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPS-0008? | Domain Name Resolution #605

Merged
merged 12 commits into from
Aug 20, 2024
99 changes: 99 additions & 0 deletions CIP-?/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
---
CIP: [To be assigned]
HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved
Title: Domain Address Resolving Standard
Status: Proposed
Category: Wallets
Authors:
- Hinson Wong <hinson@cns.space>
Implementors: []
Discussions: https://github.com/cns-space/CIPs
HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved
Solution-To: N/A
HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved
Created: 2023-10-14
License: CC-BY-4.0
---

## Abstract

This proposal suggests a method for Cardano wallets to account for naming conflicts that arise when multiple projects use the same prefix or suffix, such as `$` and `.ada,` for domain names. The proposed solution allows users to choose their desired project when resolving names with colliding prefixes or suffixes.

## Motivation: why is this CIP necessary?

As different domain projects emerge, the same prefix or suffix may be employed by different projects, leading to potential naming conflicts. One of the key features of blockchain domain service is to resolve a holder's address. Conflicting names would lead to the wallet's integration ambiguity in resolving. To address this, a community-aligned mechanism should be in place to enable users to select their preferred project when resolving names. This ensures a seamless user experience.

## Specification

1. **Naming Conflict Detection:**

- When a user enters a domain name (e.g., `hinson.ada`) with the same prefix or suffix, the wallet should detect the potential conflict. Possibly by attempt to resolve all potential project's corresponding addresses.
- When a user enters a domain name (e.g., `hinson.ada`) with the same prefix or suffix, the wallet should detect the potential conflict by attempting to resolve all potential project's corresponding addresses.

2. **User Prompt:**

- If there is only one corresponding address resolved, the wallet could proceed with the only address for proceeding with the user transaction.
- If more than one corresponding address is detected, the wallet should display a prompt to the user, explaining the conflict, and providing options for resolution.

3. **Resolution Options:**

- The prompt should offer the user the following options:

- Resolve with Project A
- Resolve with Project B
- etc...
- Cancel

> Detail UX implementation to be decided by the wallet as long as users are not confused with their choice, so only showing the project name is the minimal information needed, e.g. one for Cardano Name Service and another for adadomain

4. **User Selection:**

- The user selects one of the options presented in the prompt. If they choose to resolve with Project A, the Project A's resolver is used; if they choose the other project, the respective resolver is used.

5. **Default Project:**

- Users may have the option to set a default project for names with a colliding suffix in their wallet settings. This default project will be used for resolution unless changed by the user during the resolution prompt.
- Without user specification, there should always be an option prompting to user in case of domain name conflict.

## Rationale: how does this CIP achieve its goals?

This proposal embraces the decentralization property of a blockchain where it welcomes multiple domain name service that exists in the market without user experience competition at the infrastructure level. It ensures a user-friendly experience and allows users to make informed decisions in case of naming conflicts. It accommodates multiple projects with the same suffix in wallets while avoiding disputes and confusion, fostering the integration process of wallet and domain service.

### Path to Active
HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved

#### Acceptance Criteria
HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved

- At least 3 of wallets listed below agree with the approach

- Begin <https://begin.is/>
HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved
- Eternl <https://eternl.io/>
- Flint <https://flint-wallet.com/>
- GeroWallet <https://www.gerowallet.io/>
- Lace <https://www.lace.io/>
- Nami <https://namiwallet.io/>
- NuFi <https://nu.fi/>
- RayWallet <https://raywallet.io/>
- Yoroi <https://yoroi-wallet.com/>

> Initial list of wallet adapted from CIP30, other wallet providers could to request to add to the list.

#### Implementation Plan
HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved

- Every participating Cardano domain service provider provides an address resolver SDK.
- Every participating Cardano domain service provider provides either a desired prefix or suffix.
- Wallet providers to execute and integrate with resolving address, domain service project to provide assistance.

#### Participating Cardano Domain Service
Copy link
Collaborator

@rphair rphair Oct 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One way or another this item should be removed, since it's not a standard part of Path to Active:

  • Based on the branch name I am assuming this is your homegrown solution: if so you can cite it as an implementation & it would address my original reservation (about not being specific enough) if you could talk in your Specification about how your own system works.
  • If you think your service is beyond the scope of your CIP, you might put it in Rationale to talk about how & why the CIP is designed to accommodate implementations like your own.
  • Regardless of how much detail you go into, it should instead be an item in your Implementation Plan since you appear to have a working model (or plan to have one).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I just need to remove the line #### Participating Cardano Domain Service right? I think the content of the session is necessary to stay for community to take reference (and also its part of the implementation).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just please make sure that whatever content remains fits into the section where it appears to be. If it's in either of the two Path to Active sections, it should fit that section as described here: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001#path-to-active


| Domain Service Project | Prefix | Suffix | Link to Resolver SDK Repo |
| -------------------------- | ------ | ------ | --------------------------------------------- |
| Cardano Name Service (CNS) | N/A | `.ada` | https://github.com/cns-space/cns-resolver-sdk |
| | | | |
| | | | |

## CIP Extendibility: Domain Information Resolving

This approach could be applied in resolving other information as well in case of conflict. When there is no other specific CIP covering the particular domain information resolving mechanism, the similar approach with this CIP would by default covering the particular scope.

HinsonSIDAN marked this conversation as resolved.
Show resolved Hide resolved
## Copyright

This CIP is licensed under [CC-BY-4.0].

[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode