Naming system in the form of registry contract within Hedera #534
Conversation
✅ Deploy Preview for hedera-hips ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
| Fostering overall growth of Hedera, minting of HTLDs (Hedera based -Top-Level-Domains) & SLDs (Second-Level-Domains) within Hedera are open. Any entity, person could mint of the HTLDs & SLDs which could eventually create issues like: | ||
| a. Duplication of TLDs; .hbar (for example) by one contract & .hbarby the other contract | ||
| b. Duplication of SLDs; for example, minted SLD user.tld by one contract & user.tld by the other contract | ||
| c. Phishing attempts and inconvenience amongst the community owing to the duplication of names |
There was a problem hiding this comment.
Inconvenience amongst the community is a valid concern here. Creating standardization is necessary, but it should be clear that the community collaboration in standards on this topic will not thwart phishing attempts, the language of "phishing" should be removed as this HIP will appear compromised when phishing continues to happen in adjacent ways.
| b. Duplication of SLDs; for example, minted SLD user.tld by one contract & user.tld by the other contract | ||
| c. Phishing attempts and inconvenience amongst the community owing to the duplication of names | ||
| d. Challenges for the wallets providers to choose one contract over the other | ||
| e. Complete chaos within the Hedera ecosystem |
There was a problem hiding this comment.
This is fear based anti-competitive rhetoric and does not add substantive guideline to what this HIP is trying to accomplish. Please remove and keep text on HIP to helpful structure for the community to follow.
There was a problem hiding this comment.
There is good stuff here, but the content of this HIP should constitute more rigor. Would love to help more with structuring this. Also, this HIP shouldn't designate a specific provider but community agreed upon structure. Other things that would be helpful to include: Data format of domains, technical details and operational processes for system compromise and other security issues, composability for future expansion of product, agreed upon auditing and long term quality provision standards.
| a. Duplication of TLDs; .hbar (for example) by one contract & .hbarby the other contract | ||
| b. Duplication of SLDs; for example, minted SLD user.tld by one contract & user.tld by the other contract | ||
| c. Phishing attempts and inconvenience amongst the community owing to the duplication of names | ||
| d. Challenges for the wallets providers to choose one contract over the other |
There was a problem hiding this comment.
There are solutions of definable standards on chain that would allow for multiple naming services to exist and not mint duplicate names.
|  | ||
|
|
||
|
|
||
| (Image source: https://drive.google.com/file/d/1e3yxtaY8glEiptSXlrNxznxfzTfk1SKr/view) |
There was a problem hiding this comment.
As an abstraction this graphic is helpful, but the exact architecture in the document isn't currently viable as a contract based solution on Hedera, would be good to have a more complex rendering of what is actually going on.
| ## Detailed note on the flow | ||
|
|
||
| **1. What is Registry Contract Suite?**<br /> | ||
| Registry Contract Suite is a group of smart Contracts developed over Solidity. These smart contracts are intended to register HTLDs (Hedera Top-Level-Domains) and Second-Level-Domains (SLDs) in a hierarchical manner. Domains and HTLDs once registered could be queried and looked up to avoid duplication.<br /> |
There was a problem hiding this comment.
I think when you say 'Domain' you mean SLD, but would probably be best to avoid generic use of 'Domain' for this HIP.
| **1. What is Registry Contract Suite?**<br /> | ||
| Registry Contract Suite is a group of smart Contracts developed over Solidity. These smart contracts are intended to register HTLDs (Hedera Top-Level-Domains) and Second-Level-Domains (SLDs) in a hierarchical manner. Domains and HTLDs once registered could be queried and looked up to avoid duplication.<br /> | ||
| **2. How does Registry Contract Suite Works?**<br /> | ||
| Registry Contract Suite is an intelligent group of smart contract that maintains an alphabetical hierarchy to register HTLDs and is smart enough to create and store HTLDs in their respective Alphabetical Registry Component.<br /> |
There was a problem hiding this comment.
We should probably avoid words like 'Intelligent' and 'Smart enough'. How exactly is the contract architecture communicating with subordinate contracts?
| Registry Contract Suite is a group of smart Contracts developed over Solidity. These smart contracts are intended to register HTLDs (Hedera Top-Level-Domains) and Second-Level-Domains (SLDs) in a hierarchical manner. Domains and HTLDs once registered could be queried and looked up to avoid duplication.<br /> | ||
| **2. How does Registry Contract Suite Works?**<br /> | ||
| Registry Contract Suite is an intelligent group of smart contract that maintains an alphabetical hierarchy to register HTLDs and is smart enough to create and store HTLDs in their respective Alphabetical Registry Component.<br /> | ||
| Once a HTLD is registered by the provider, an entry in respective alphabetical hierarchy smart contract is made. All further domains and subdomains under that hierarchy would be stored in that structure. So that for future, queries for that registered domain names or HTLD/s could be appropriately handled.<br /> |
There was a problem hiding this comment.
I'm not sure that an alphabetical hierarchy of smart contracts is necessary, can there be a subsection defining this?
| Registry Contract Suite is an intelligent group of smart contract that maintains an alphabetical hierarchy to register HTLDs and is smart enough to create and store HTLDs in their respective Alphabetical Registry Component.<br /> | ||
| Once a HTLD is registered by the provider, an entry in respective alphabetical hierarchy smart contract is made. All further domains and subdomains under that hierarchy would be stored in that structure. So that for future, queries for that registered domain names or HTLD/s could be appropriately handled.<br /> | ||
| **3. Who are providers and how could someone become a provider of domains/HTLDs?**<br /> | ||
| Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. <br /> |
There was a problem hiding this comment.
Decentralized implementation should avoid traditional constructs like contracts that give many people the ability to sell them, this creates a value vacuum in the system that isn't necessary. The system itself should exist as a public good and value created by it should be dispersed to the community supporting it.
| Once a HTLD is registered by the provider, an entry in respective alphabetical hierarchy smart contract is made. All further domains and subdomains under that hierarchy would be stored in that structure. So that for future, queries for that registered domain names or HTLD/s could be appropriately handled.<br /> | ||
| **3. Who are providers and how could someone become a provider of domains/HTLDs?**<br /> | ||
| Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. <br /> | ||
| To become a provider, entities need to raise a request to the admin of Registry Contracts, who have the privilege to add addresses as providers for the Registry Smart Contract Suite. Initially this would be done through a form accessible via the website of Web23 at web23.io with a goal of moving to a fully decentralized approach.<br /> |
There was a problem hiding this comment.
Again, privilege and centralized authorities imbued with the power to give privilege aren't necessary in web3 and remove value from the system.
|
|
||
| b. **AlphaRegistry:** This solidity file is responsible for doing all the jobs and is exposed for providers. It would internally call different smart contracts from the suite to get the job done. | ||
|
|
||
| c. **UTools:** This smart contract empowers the suite with a handful of utility functions like substring and all. |
There was a problem hiding this comment.
string manipulation methods shouldn't be on chain, they aren't gas friendly and would cause undo burden on the network, at least for the near and mid future.
|
|
||
| c. **UTools:** This smart contract empowers the suite with a handful of utility functions like substring and all. | ||
|
|
||
| d. **AToZRegistry:** This solidity file is responsible for creating a hierarchical alphabetical order of smart contracts |
There was a problem hiding this comment.
how is the system both hierarchical and alphabetical? Not a critique, but would like these technical details explained.
| @@ -0,0 +1,160 @@ | |||
| --- | |||
| hip: <HIP number (this is determined by the HIP editor)> | |||
| title: REGISTRY CONTRACT containing default naming structure format for HTLDs & SLDs ever minted over Hedera network | |||
There was a problem hiding this comment.
This title is a smidge long. Maybe there is another that fits and is shorter? What about "Naming Structure of Registry Contracts"?
| author: som-web23,([email protected]) | ||
| working-group: ([email protected]),([email protected]),([email protected]) |
There was a problem hiding this comment.
authors and working-group should be comma delimited lists in the form:
Firstname Lastname (@gitname or email)
There was a problem hiding this comment.
Hi @mgarbs , FYI - @gitname is my username on GitHub. I got a notification about this Issue when my username was mentioned. I'll unsubscribe from this Issue.
|
|
||
| ## Motivation | ||
|
|
||
| Hedera public ledger is comparatively new in comparison to other existing L1 chains. Hedera wins over the other chains through higher TPS leading to scalable solutions, negligible cost to execute the transactions to name a few. |
There was a problem hiding this comment.
This particular paragraph might be straying a little from the topic here. Although I totally agree with you, maybe it is best that we drop this part.
| d. Challenges for the wallets providers to choose one contract over the other | ||
| e. Complete chaos within the Hedera ecosystem | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
Let's bring these great thoughts into more concise points.
Motivation:
To develop a naming standard in registry contracts to prohibit duplicate HTLDs and SLDs.
Your summarized history of TLD growth and the need for naming standards
|
|
||
| Hedera public ledger is comparatively new in comparison to other existing L1 chains. Hedera wins over the other chains through higher TPS leading to scalable solutions, negligible cost to execute the transactions to name a few. | ||
| In the beginning, ICANN (The Internet Corporation for Assigned Names and Numbers) responsible for web2 domains had started with thirteen TLDs. Today, we have hundreds of gTLD (generic Top Level Domains) like .biz, .capital etc. At the same time, no two SLD within a TLD match or so to say, duplication of domain names within a TLDs does not exist across the globe although buying of domains is administered by hundreds of domain registrars, resellers etc. | ||
| Riding on the exceptional capabilities of Hedera & following the design philosophy of ICANN where no two SLDs are identical, proposed default structured format of TLDs & SLDs in the form of registry contract within Hedera would allow multi-parties to co-exist without leading to the confusion. |
There was a problem hiding this comment.
We should avoid language like "Riding on the exceptional capabilities of Hedera" because it pulls focus away from the subject of this hip
| Once a HTLD is registered by the provider, an entry in respective alphabetical hierarchy smart contract is made. All further domains and subdomains under that hierarchy would be stored in that structure. So that for future, queries for that registered domain names or HTLD/s could be appropriately handled.<br /> | ||
| **3. Who are providers and how could someone become a provider of domains/HTLDs?**<br /> | ||
| Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. <br /> | ||
| To become a provider, entities need to raise a request to the admin of Registry Contracts, who have the privilege to add addresses as providers for the Registry Smart Contract Suite. Initially this would be done through a form accessible via the website of Web23 at web23.io with a goal of moving to a fully decentralized approach.<br /> |
There was a problem hiding this comment.
I do not think that this would be the right process, even if it is easier initially. This type of process can lead to gate keeping and bias and should be handled by a third-party right from the start.
|
Is there a discussion forum by which we can talk about this? It seems to outline a specific set of smart contracts (without a reference implementation) but does not define a way by which to mitigate multiple issuers of a domain/namespace. Specifically, does this HIP imply that in order to establish |
Hello @Cooper-Kunz , we have a Slack Channel as a discussion forum for the HIP. We have outlined a set of smart contracts where we allow multiple issuers of domain/namespace , as providers. Each and every provider has the capabilities to issue domains/TLDs and register it under the smart contract. These registry contracts have a pure intention to avoid duplicates. This is a common domains/namespaces dumping station , where any provider can book domains at their end using their smart contracts and they just need to intimate these smart contracts that yes something has been booked. So in order to establish .any .tld there needs to be couple of things whih needs to be done :-
This registration of TLDs ensures registry contracts holds a record of .tld under your provider Role and will not be duplicated in any sense. Now as a provider you can implement your logic to mint domains under that .tld, and that is independent of Registry Contracts. Also web23 doesn't own,govern or control any of these. These Smart contracts once released would be owned by Swirlds Lab or so and Web23 would be interacting with these smart contracts as Providers. |
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
Signed-off-by: som-web23 <[email protected]>
| Once a HTLD is registered by the provider, an entry in respective alphabetical hierarchy smart contract is made. All further domains and subdomains under that hierarchy would be stored in that structure. So that for future, queries for that registered domain names or HTLD/s could be appropriately handled.<br /> | ||
| **3. Who are providers and how could someone become a provider of domains/HTLDs?**<br /> | ||
| Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. <br /> | ||
| Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. All these would be handled by Swirlds Lab or Hbar Foundation.(So that no Provider controls or gate keeps the process) <br /> |
There was a problem hiding this comment.
"All these..." refers to what? The meaning of this is unclear.
| Once a HTLD is registered by the provider, an entry in respective alphabetical hierarchy smart contract is made. All further domains and subdomains under that hierarchy would be stored in that structure. So that for future, queries for that registered domain names or HTLD/s could be appropriately handled.<br /> | ||
| **3. Who are providers and how could someone become a provider of domains/HTLDs?**<br /> | ||
| Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. <br /> | ||
| Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. All these would be handled by Swirlds Lab or Hbar Foundation.(So that no Provider controls or gate keeps the process) <br /> | ||
| To become a provider, entities need to raise a request to the admin of Registry Contracts, who have the privilege to add addresses as providers for the Registry Smart Contract Suite. Initially this would be done through a form accessible via the website of Web23 at web23.io with a goal of moving to a fully decentralized approach.<br /> |
There was a problem hiding this comment.
This revision still leaves Web23 as a centralized gatekeeper with purview over who can become a name provider. There is no discussion of the requirements for becoming a name provider or the policies a name provider must follow. Without HNS-level policies, the incentives for a bad actor are high. A new name provider could set $0 registration fees and hoard domains for its own or an affiliates account. Likewise, policies need to be in place that provide certainty on renewal fees. Without HNS-level policies on this topic, a name provider has the discretion to set and change renewal fees; a name provider, as a bad actor would be free to target and extort exorbitant renewal fees from successful domain projects. The HNS needs ecosystem-wide policies and a community-based governance model that establishes a process for setting policies and changing them when required. It's antithetical to Web3 to have Web23 be the gatekeeper to HNS or require builders/investors to "trust" in the future behavior of a name provider.
There was a problem hiding this comment.
This HIP has major flaws. First, it leaves Web23 as a gatekeeper of the HNS registry with discretion as to who can become an HNS name provider. Second, it does not establish what criteria would be used to approve/disapprove a new name provider. Third, it leaves name providers with full discretion over setting registration fees, renewal fees, and processes for expired domains. Builders and investors need certainty; this HIP, if implemented, would create massive uncertainty and discourage investment or development of HNS assets.
It is important that HNS become decentralized, but the consequences of giving a name provider authority over who else can become a name provider are bad on its face. At the same time, allowing multiple domain providers may seem like a step toward decentralization, but if each name provider has complete discretion over policies and terms, the result is chaos. What prevents a name provider from setting registration fees at $0? What prevents a name provider from setting exorbitant renewal fees after a project has been developed? The HNS needs an organization like Swirlds or the HBAR Foundation to guide this process with a path to a community-based (DAO) governance model.
Web3 models are based on trustless transactions. As written, this HIP requires HNS builders to trust in a centralized gatekeeper of HNS and trust in the future behavior of domain providers.
|
What do we want to do with this HIP @som-web23 @rahul-web23 @nostradaomus ? Making it Stagnant for now because it hasnt had activity for a while. It can be resurrected or a new HIP can be created |
|
@mgarbs I think it's best if the parties involved (which at this point is just BCW Group and Kabuto) start fresh on a new proposal. |
…ph#534) Signed-off-by: som-web23 <[email protected]> Co-authored-by: Michael Garber <[email protected]> Signed-off-by: Kim Rader <[email protected]>
Description:
This PR proposes new schema of naming system in the form of registry contract within Hedera that would allow multi-parties to co-exist and provide minting, managing of web3 domains in .hbar or HTTLDs (Hedera Top Level Domains)
This PR modifies ... in order to support ...
Related issue(s):
Fixes #
Notes for reviewer:
A Draft for HIP - Registry Contracy for Naming Services
Checklist