From a1c3afd2d9faeb667c29d115e79317fe8e3f203f Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Sat, 14 Oct 2023 16:47:39 +0800 Subject: [PATCH 01/12] New proposed CIP - Domain Address Resolving Standard --- CIP-?/README.md | 99 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 CIP-?/README.md diff --git a/CIP-?/README.md b/CIP-?/README.md new file mode 100644 index 000000000..750cfd2b6 --- /dev/null +++ b/CIP-?/README.md @@ -0,0 +1,99 @@ +--- +CIP: [To be assigned] +Title: Domain Address Resolving Standard +Status: Proposed +Category: Wallets +Authors: + - Hinson Wong +Implementors: [] +Discussions: https://github.com/cns-space/CIPs +Solution-To: N/A +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 + +#### Acceptance Criteria + +- At least 3 of wallets listed below agree with the approach + + - Begin + - Eternl + - Flint + - GeroWallet + - Lace + - Nami + - NuFi + - RayWallet + - Yoroi + + > Initial list of wallet adapted from CIP30, other wallet providers could to request to add to the list. + +#### Implementation Plan + +- 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 + +| 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. + +## Copyright + +This CIP is licensed under [CC-BY-4.0]. + +[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode From 73d72d9618b8a059c30026a8c11ae97e9d82fca6 Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Sun, 15 Oct 2023 11:07:51 +0800 Subject: [PATCH 02/12] fix: fixing formats --- CIP-?/README.md | 33 +++++++++++++++------------------ 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/CIP-?/README.md b/CIP-?/README.md index 750cfd2b6..c81ad887f 100644 --- a/CIP-?/README.md +++ b/CIP-?/README.md @@ -1,5 +1,5 @@ --- -CIP: [To be assigned] +CIP: ? Title: Domain Address Resolving Standard Status: Proposed Category: Wallets @@ -7,7 +7,6 @@ Authors: - Hinson Wong Implementors: [] Discussions: https://github.com/cns-space/CIPs -Solution-To: N/A Created: 2023-10-14 License: CC-BY-4.0 --- @@ -56,25 +55,27 @@ As different domain projects emerge, the same prefix or suffix may be employed b 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 +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. + +## Path to Active -#### Acceptance Criteria +### Acceptance Criteria - At least 3 of wallets listed below agree with the approach - - Begin - - Eternl - - Flint - - GeroWallet - - Lace - - Nami - - NuFi - - RayWallet - - Yoroi + - [ ] Begin + - [ ] Eternl + - [ ] Flint + - [ ] GeroWallet + - [ ] Lace + - [ ] Nami + - [ ] NuFi + - [ ] RayWallet + - [ ] Yoroi > Initial list of wallet adapted from CIP30, other wallet providers could to request to add to the list. -#### Implementation Plan +### Implementation Plan - Every participating Cardano domain service provider provides an address resolver SDK. - Every participating Cardano domain service provider provides either a desired prefix or suffix. @@ -88,10 +89,6 @@ This proposal embraces the decentralization property of a blockchain where it we | | | | | | | | | | -## 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. - ## Copyright This CIP is licensed under [CC-BY-4.0]. From f5a6b32945f20293678cb49d413821f38cb43c07 Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Sun, 15 Oct 2023 11:19:04 +0800 Subject: [PATCH 03/12] fix: removing sub-title in implementation plan --- CIP-?/README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/CIP-?/README.md b/CIP-?/README.md index c81ad887f..06d7cdb79 100644 --- a/CIP-?/README.md +++ b/CIP-?/README.md @@ -81,8 +81,6 @@ This approach could be applied in resolving other information as well in case of - 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 - | 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 | From eed435554a397d3fe30b982b01d52f49cd0107bc Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Sun, 15 Oct 2023 12:26:07 +0800 Subject: [PATCH 04/12] feat: adding example in specification --- CIP-?/README.md | 97 ++++++++++++++++++++++++++++++++++--------------- 1 file changed, 68 insertions(+), 29 deletions(-) diff --git a/CIP-?/README.md b/CIP-?/README.md index 06d7cdb79..69f08595c 100644 --- a/CIP-?/README.md +++ b/CIP-?/README.md @@ -21,35 +21,74 @@ As different domain projects emerge, the same prefix or suffix may be employed b ## 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. +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. + > Specific example illustration + > + > - A user enter `hinson.ada` in any wallet's `recipient field` + > - Wallet try to resolve all domain projects' corresponding address using suffix `.ada` + > - Let's say there are 2 domain services (`Domain Service A` and `Domain Service B`) opt in using `.ada` as suffix, wallet would try to resolve address on both services. + - 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. + > Specific example illustration + > + > - `Resolve Case 1`: `Domain Service A` resolves `addr_a` and `Domain Service B` resolves `addr_b`, it is a conflict in resolution. + > - `Resolve Case 2`: `Domain Service A` resolves `addr_a` and `Domain Service B` resolves nothing, there is no conflict. + > - `Resolve Case 3`: `Domain Service A` resolves nothing and `Domain Service B` resolves `addr_a`, there is no conflict. + > - `Resolve Case 4`: `Domain Service A` and `Domain Service B` both resolves `addr_a`, there is no conflict. + > - `Resolve Case 5`: `Domain Service A` and `Domain Service B` both resolves nothing, there is no conflict. Since no address is resolved, transaction would not proceed. + +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. + > Specific example illustration + > + > - `Proceed Case 1`: For `Resolve Case 1`, `Resolve Case 3` and `Resolve Case 4`, there is only 1 address resolved. So an only address is identified from resolution and thus the transaction could proceed with `addr_a`. + - 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. + > Specific example illustration + > + > - `Proceed Case 2`: For `Resolve Case 2`, more than 1 address is identified. Wallet should display options of either choosing to resolve using `Domain Service A` or `Domain Service B` + > - If user chooses `Domain Service A`, `addr_a` is used for transaction + > - If user chooses `Domain Service B`, `addr_b` is used for transaction + +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 adadomains + > + > Specific example illustration + > + > - For `Resolve Case 2`, more than 1 address is identified. Wallet should display options of either choosing to resolve using `Domain Service A` or `Domain Service B`. There is also an option to `Cancel`. + +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. + > Specific example illustration + > + > - If user chooses `Domain Service A`, `addr_a` is used for transaction + > - If user chooses `Domain Service B`, `addr_b` is used for transaction + > - If user chooses `Cancel`, transaction is stopped and would not proceed. + +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. + > Specific example illustration + > + > - In the wallet's setting, there would be a page showing all conflicting domain suffix or prefix + > - Assumed apart from `Domain Service A` and `Domain Service B` conflict in choosing `.ada` as suffix, there are also `Domain Service C` and `Domain Service D` conflict choosing `$` as prefix, the list would show + > - Setting default `.ada` prefix domain service + > - `Domain Service A` + > - `Domain Service B` + > - Setting default `$` suffix domain service + > - `Domain Service C` + > - `Domain Service D` + > - For example, when user selected `Domain Service A` as default for `.ada`, even for `Resolve Case 2` as illustrated above, it would go with `Proceed Case 1` (to directly proceed with transaction) but not `Proceed Case 2` (to show user 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? From e20682004a450d885904c7ddcf459082f8a3ed30 Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Wed, 18 Oct 2023 00:40:32 +0800 Subject: [PATCH 05/12] changing to CPS formats --- CIP-?/README.md | 42 ++++++++++++++++-------------------------- 1 file changed, 16 insertions(+), 26 deletions(-) diff --git a/CIP-?/README.md b/CIP-?/README.md index 69f08595c..2dd6fd5ca 100644 --- a/CIP-?/README.md +++ b/CIP-?/README.md @@ -1,11 +1,11 @@ --- -CIP: ? +CPS: ? Title: Domain Address Resolving Standard Status: Proposed Category: Wallets Authors: - Hinson Wong -Implementors: [] +Proposed Solution: [] Discussions: https://github.com/cns-space/CIPs Created: 2023-10-14 License: CC-BY-4.0 @@ -13,13 +13,21 @@ 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. +As the ecosystem emerges, more and more domain service projects entering Cardano. Currently noticeably there are 3 domain projects: -## Motivation: why is this CIP necessary? +1. `ADA Handle` +2. `adadomains` +3. `Cardano Name Service` + +Both `adadomains` and `Cardano Name Service` has chosen `.ada` as domain suffix. When proceeding with wallet integration on address resolving, one common issue faced is the ambiguity in resolving approach, which could lead to potentially serious loss of fund in sending fund to undesired recipients. + +The CPS is written up accordingly to suggest possible solution and open for discussion. + +## Problem 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 +## Use cases 1. **Naming Conflict Detection:** @@ -90,32 +98,12 @@ As different domain projects emerge, the same prefix or suffix may be employed b > - For example, when user selected `Domain Service A` as default for `.ada`, even for `Resolve Case 2` as illustrated above, it would go with `Proceed Case 1` (to directly proceed with transaction) but not `Proceed Case 2` (to show user 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? +## 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. 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. -## Path to Active - -### Acceptance Criteria - -- At least 3 of wallets listed below agree with the approach - - - [ ] Begin - - [ ] Eternl - - [ ] Flint - - [ ] GeroWallet - - [ ] Lace - - [ ] Nami - - [ ] NuFi - - [ ] RayWallet - - [ ] Yoroi - - > Initial list of wallet adapted from CIP30, other wallet providers could to request to add to the list. - -### Implementation Plan - - 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. @@ -126,6 +114,8 @@ This approach could be applied in resolving other information as well in case of | | | | | | | | | | +## Open Questions + ## Copyright This CIP is licensed under [CC-BY-4.0]. From bb4252e8576db59a57d2420e1d555f5a957f7e31 Mon Sep 17 00:00:00 2001 From: "[SIDAN] Whatever" <90688504+SIDANWhatever@users.noreply.github.com> Date: Wed, 18 Oct 2023 08:28:40 +0800 Subject: [PATCH 06/12] Update CIP-?/README.md Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com> --- CIP-?/README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CIP-?/README.md b/CIP-?/README.md index 2dd6fd5ca..059b505b3 100644 --- a/CIP-?/README.md +++ b/CIP-?/README.md @@ -6,7 +6,9 @@ Category: Wallets Authors: - Hinson Wong Proposed Solution: [] -Discussions: https://github.com/cns-space/CIPs +Discussions: +- https://github.com/cns-space/CIPs +- https://github.com/cardano-foundation/CIPs/pull/605 Created: 2023-10-14 License: CC-BY-4.0 --- From f8d2f5b65b4ecf252db69c93f939430d25d7ac16 Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Thu, 26 Oct 2023 15:21:59 +0800 Subject: [PATCH 07/12] redrafting it into CPS --- CPS-?/README.md | 75 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 CPS-?/README.md diff --git a/CPS-?/README.md b/CPS-?/README.md new file mode 100644 index 000000000..e11219edf --- /dev/null +++ b/CPS-?/README.md @@ -0,0 +1,75 @@ +--- +CPS: ? +Title: Domain Information Resolving Standard +Status: Proposed +Category: Wallets +Authors: + - Hinson Wong +Proposed Solution: [] +Discussions: +- https://github.com/cns-space/CIPs +- https://github.com/cardano-foundation/CIPs/pull/605 +Created: 2023-10-14 +License: CC-BY-4.0 +--- + +## Abstract + +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 domain information. Conflicting names would lead to the 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. + +The CPS is written up accordingly to open for discussion on potential approaches to the above issue. + +## Problem + +As the ecosystem emerges, more and more domain service projects entering Cardano. Currently noticeably there are 3 domain projects: + +1. `ADA Handle` +2. `adadomains` +3. `Cardano Name Service (CNS)` + +Both `adadomains` and `CNS` has chosen `.ada` as domain suffix. When proceeding with resolving integration, one common issue faced is the ambiguity in resolving approach, which could lead to user confusion at the minimal impact. On some specific information resolving, it might even cause serious loss of fund when sending tokens with monetary value to unexpected recipients. + +## Use cases + +Let's illustrate the potential issues with a hypothetical example in wallet address resolving area. + +1. Assuming `Yoroi` wallet is going to integrate with `CNS` and `NuFi` wallet is going to integrate `adadomains`. (And both `CNS` and `adadomains` opt for `.ada` as the suffix) +2. Both protocol has their separate domain NFT called `hinson.ada` and there are separate holder of `hinson.ada` for 2 domain projects. +3. When the `hinson.ada` `CNS` holder requesting fund from others, there would be potential loss of fund when the user sending fund to `hinson.ada` through `NuFi` since the fund would be sent to `adadomains` domain holder instead. + +This is not a desirable outcome as funds are mistakenly sending to the incorrect recipient without users noticing it. + +## Goals + +The goal of this `CPS` is to invite community discussion on how to best approach this potential problem when the ecosystem evolves and having more and more domain projects entering the space. + +### Pro-decentralization Solution + +The solution should embrace the decentralization property of a blockchain where it welcomes multiple domain name services exist in the market without user experience competition at the infrastructure level. The solution should not be made customized for any specific domain service providers, ideally shifting domain service projects' focus to enhancing features rather than competing with each other by oligarchic alliance. + +### Clear User Experience Flow + +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 while avoiding disputes and confusion, fostering the integration process of wallet and domain service. + +## Open Questions + +### On Domain Service Providers + +1. Should there be any standard in domain service provider side to store user information? +2. Should there be standardization in domain metadata to assist with consistent integration? +3. Apart from address resolving, should there be any standardized way to resolve domain information? +4. Is there any threshold or minimum requirement on domain projects in order to be considered as applicable to apply the potential solution? +5. Following `question 4 on integration partners`, would it be the domain service providers' responsibility to ensure the integration is in compliance with the potential solution? + +### On Integration Partners (e.g. Wallets) + +1. Should the potential solution just provide a high level guideline on integration user experience flow? Or a detailed guideline would be preferred? +2. How to inform the community on whether which projects participated in the solution `CIP` so to alleviate users' concern when proceeding with integration partners? For example user could be confirmed that their fund would not be sent to unexpected recipients when using certain wallets participating in the `CIP`. +3. Should there be any kind of community verification to include integration partners on to the participation list? +4. If the potential solution `CIP` only serves as a soft guideline, how could we make it useful to community when projects integrating with domain services do bother to spend time and effort into this alignment? + +## Copyright + +This CPS is licensed under [CC-BY-4.0]. + +[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode From 98c09b77c13448423403eae1c4130260959f1e92 Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Thu, 26 Oct 2023 15:23:40 +0800 Subject: [PATCH 08/12] removing CIP --- CIP-?/README.md | 125 ------------------------------------------------ 1 file changed, 125 deletions(-) delete mode 100644 CIP-?/README.md diff --git a/CIP-?/README.md b/CIP-?/README.md deleted file mode 100644 index 059b505b3..000000000 --- a/CIP-?/README.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -CPS: ? -Title: Domain Address Resolving Standard -Status: Proposed -Category: Wallets -Authors: - - Hinson Wong -Proposed Solution: [] -Discussions: -- https://github.com/cns-space/CIPs -- https://github.com/cardano-foundation/CIPs/pull/605 -Created: 2023-10-14 -License: CC-BY-4.0 ---- - -## Abstract - -As the ecosystem emerges, more and more domain service projects entering Cardano. Currently noticeably there are 3 domain projects: - -1. `ADA Handle` -2. `adadomains` -3. `Cardano Name Service` - -Both `adadomains` and `Cardano Name Service` has chosen `.ada` as domain suffix. When proceeding with wallet integration on address resolving, one common issue faced is the ambiguity in resolving approach, which could lead to potentially serious loss of fund in sending fund to undesired recipients. - -The CPS is written up accordingly to suggest possible solution and open for discussion. - -## Problem - -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. - -## Use cases - -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. - > Specific example illustration - > - > - A user enter `hinson.ada` in any wallet's `recipient field` - > - Wallet try to resolve all domain projects' corresponding address using suffix `.ada` - > - Let's say there are 2 domain services (`Domain Service A` and `Domain Service B`) opt in using `.ada` as suffix, wallet would try to resolve address on both services. - - 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. - > Specific example illustration - > - > - `Resolve Case 1`: `Domain Service A` resolves `addr_a` and `Domain Service B` resolves `addr_b`, it is a conflict in resolution. - > - `Resolve Case 2`: `Domain Service A` resolves `addr_a` and `Domain Service B` resolves nothing, there is no conflict. - > - `Resolve Case 3`: `Domain Service A` resolves nothing and `Domain Service B` resolves `addr_a`, there is no conflict. - > - `Resolve Case 4`: `Domain Service A` and `Domain Service B` both resolves `addr_a`, there is no conflict. - > - `Resolve Case 5`: `Domain Service A` and `Domain Service B` both resolves nothing, there is no conflict. Since no address is resolved, transaction would not proceed. - -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. - > Specific example illustration - > - > - `Proceed Case 1`: For `Resolve Case 1`, `Resolve Case 3` and `Resolve Case 4`, there is only 1 address resolved. So an only address is identified from resolution and thus the transaction could proceed with `addr_a`. - - 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. - > Specific example illustration - > - > - `Proceed Case 2`: For `Resolve Case 2`, more than 1 address is identified. Wallet should display options of either choosing to resolve using `Domain Service A` or `Domain Service B` - > - If user chooses `Domain Service A`, `addr_a` is used for transaction - > - If user chooses `Domain Service B`, `addr_b` is used for transaction - -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 adadomains - > - > Specific example illustration - > - > - For `Resolve Case 2`, more than 1 address is identified. Wallet should display options of either choosing to resolve using `Domain Service A` or `Domain Service B`. There is also an option to `Cancel`. - -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. - > Specific example illustration - > - > - If user chooses `Domain Service A`, `addr_a` is used for transaction - > - If user chooses `Domain Service B`, `addr_b` is used for transaction - > - If user chooses `Cancel`, transaction is stopped and would not proceed. - -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. - > Specific example illustration - > - > - In the wallet's setting, there would be a page showing all conflicting domain suffix or prefix - > - Assumed apart from `Domain Service A` and `Domain Service B` conflict in choosing `.ada` as suffix, there are also `Domain Service C` and `Domain Service D` conflict choosing `$` as prefix, the list would show - > - Setting default `.ada` prefix domain service - > - `Domain Service A` - > - `Domain Service B` - > - Setting default `$` suffix domain service - > - `Domain Service C` - > - `Domain Service D` - > - For example, when user selected `Domain Service A` as default for `.ada`, even for `Resolve Case 2` as illustrated above, it would go with `Proceed Case 1` (to directly proceed with transaction) but not `Proceed Case 2` (to show user prompt). - - Without user specification, there should always be an option prompting to user in case of domain name conflict. - -## 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. - -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. - -- 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. - -| 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 | -| | | | | -| | | | | - -## Open Questions - -## Copyright - -This CIP is licensed under [CC-BY-4.0]. - -[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode From 563ae56973e5c2bb095c901cd73def0be82168e7 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Thu, 26 Oct 2023 14:22:14 -0400 Subject: [PATCH 09/12] more specific + currently accurate title --- CPS-?/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-?/README.md b/CPS-?/README.md index e11219edf..5d932c1f0 100644 --- a/CPS-?/README.md +++ b/CPS-?/README.md @@ -1,6 +1,6 @@ --- CPS: ? -Title: Domain Information Resolving Standard +Title: Domain Name Resolution Status: Proposed Category: Wallets Authors: From a641e97f8844a7c2a9710b0b25fa07a5d43250fb Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Thu, 26 Oct 2023 14:23:52 -0400 Subject: [PATCH 10/12] Tools, since not only Wallets but also UX, dApps etc. --- CPS-?/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-?/README.md b/CPS-?/README.md index 5d932c1f0..97753e7e1 100644 --- a/CPS-?/README.md +++ b/CPS-?/README.md @@ -2,7 +2,7 @@ CPS: ? Title: Domain Name Resolution Status: Proposed -Category: Wallets +Category: Tools Authors: - Hinson Wong Proposed Solution: [] From 4237d22393a535fe66ec557688b773508bd5d848 Mon Sep 17 00:00:00 2001 From: "[SIDAN] Whatever" <90688504+SIDANWhatever@users.noreply.github.com> Date: Wed, 15 Nov 2023 11:17:52 +0800 Subject: [PATCH 11/12] Update CPS-?/README.md Co-authored-by: Robert Phair --- CPS-?/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CPS-?/README.md b/CPS-?/README.md index 97753e7e1..464f34ee4 100644 --- a/CPS-?/README.md +++ b/CPS-?/README.md @@ -1,5 +1,5 @@ --- -CPS: ? +CPS: 8 Title: Domain Name Resolution Status: Proposed Category: Tools From 9cd2bcab7bf57c440a17bdb49a12d735b9208070 Mon Sep 17 00:00:00 2001 From: SIDANWhatever Date: Wed, 15 Nov 2023 11:27:10 +0800 Subject: [PATCH 12/12] renaming directory according to assigned number --- {CPS-? => CPS-0008}/README.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {CPS-? => CPS-0008}/README.md (100%) diff --git a/CPS-?/README.md b/CPS-0008/README.md similarity index 100% rename from CPS-?/README.md rename to CPS-0008/README.md