Unified naming system to resolve domains

[mgarbs]

Currently, on Hedera, we have three different methods of doing a naming registry, but it would be great to establish a single standard and way of resolving domains. This would support the growth of a strong and unified community going forward.

Having a single standardized way of resolving domains will provide clarity and consistency, making it easier for users and developers alike. It will also allow for better collaboration and increased adoption among the greater community.

Opening the floor to hear your thoughts and suggestions on how we can achieve this goal. If you have any ideas or would like to contribute, please consider adding to this discussion. Let's work together to build a better and more unified Hedera community!

There was a hip created a while back that has gone stale and would be a great fit to engage with this discussion so that it gets built out to a complete state.

[hashpool-network]

Can you clarify what you mean by, "we have three different methods of doing a naming registry."

[mgarbs]

Of course! There is a hip @som-web23 proposed to have a naming system in the form of registry contract within Hedera and we also have 2 other naming services which handle resolving domains on hedera differently. It would be really cool I think if we had a single standard everyone followed together as it would help open up more potential and collaboration. The hip I mentioned was a good start so my hope is that people see it and contribute to it.

[hashpool-network]

Thank you. As someone with a potential HNS project, I think a single naming registry/resolver is essential. This would facilitate the decentralization of HNS and allow domain owners to become name provider registrars for their own assets. The ability for a domain owner to rent, sell, or assign subdomains is an advertised "feature" of HNS and HIP-534 which you referred to would provide this capability but based on my discussions there has been no progress (or dev resources made available) toward implementation.

The other potential issue that needs to be resolved is the current lack of protocol governance. Allowing decentralized access to '.hbar' TLD is good but without any protocol policies, it becomes ripe for bad actors. For example, without established minimum registration fees at the protocol layer a bad-acting domain name provider could set registration fees at $0 and hoard domains. Also, there needs to be certainty and uniformity for renewal fees; otherwise, a project built on a domain is subject to discretionary annual renewal fees. That requires builders to "trust" the future behavior of a name provider they register with will be honest. There are a few other issues that I have come across that will require protocol layer policies as well.

I think the development path of the ENS and role of the ENS-DAO can be instructive here. Ultimately, it is probably best if the '.hbar' domains are consolidated under one name provider with community governance mechanisms (and ultimately a DAO) established to set policies and change them when required. There seems to be a lot of material here for 1 process HIP. Is this something Swirlds can take a lead on?