TLDs, TLDs & more TLDs

As the heading alludes to, this article is about Top Level Domains (TLDs). If you find yourself here, you probably know what a decentralized domain is. You may understand that it is a system to give nice human-readable names to unreadable addresses (public keys). For now, you can at least use it on the blockchain to send and receive funds.

In this context, there is one thing I have been wondering about quite a bit lately: what makes a decentralized blockchain-based domain name service successful? From a user perspective, what are the rational deciding factors when choosing which one to host your identity?

When thinking about bringing value to users, I can’t help but interrogate the level of actual adoption these decentralized name services experience not just within but beyond their own web3 silos, which is to say on our broader “traditional” web. Yes, we do get to use our domain names as a social presence to brag about or participate within the frameworks of available integrations but it’s not near where it could be. What’s the matter? When and how can decentralized domains broaden their reach into the other spaces we know and use today? For instance, when will we start leveraging this uncensorable and user-owned identity in the omnipresent Internet of Things? That would be value to me.

The value of a naming convention is proportional to its adoption

When it comes to naming things, convention is everything. The original naming system is language itself, and a language is nothing if it is not spoken, which is to say adopted. Language and naming systems in general are conventions or protocols, and therefore adoption is the name of the game. A domain is only as valuable as its current (or future) level of adoption within but also beyond its native ecosystem.

In this regard, managing a new TLD is all about gathering momentum and using it to get ever-bigger partnerships. Momentum for a TLD is measured in terms of visibility and user base. Partnering with projects such as Cloudflare, NextDNS, Microsoft and alike would be a golden opportunity to bridge the gap between web3 and web2, to bring value to everyone in the namespace. To make this possible only numbers can give us a seat at the table - whether we’re talking about userbase or integrations.

There’s already a big universally adopted naming service out there, which we just call DNS. It is managed by ICANN. The ICANN root domain is the de facto actual root domain. The endgame we want is to be considered for integration within this system and it’s easier to ask for a single prominent TLD.

Perhaps we can use the Ethereum Name Service’s (.eth) success thus far as an example. I think their success lies particularly in their unified strength. A single TLD that focuses on functionality and fostering partnerships for its users. Integrating within a broader already existing and adopted framework is perceivably their ultimate objective.

Here we can argue the same for the Solana name service. The work we're doing by integrating with browsers and increasing SNS’ adoption is a way to bridge that gap towards having our own decentralized TLD with Solana as the ultimate source of truth.

Now, on the contrary, it seems quite probable that if multiple TLDs with similar levels of adoption existed on the same blockchain, potential partners might question the value of such a split. Even worse, they might get to choose who to support themselves between the different available offerings based on factors they entirely control. This can result in user base segmentation as different TLDs cater to different partnership integrations. We could say that that’ll lead to a set of competing TLDs, each with its own specific utility, and none encompassing it all, which just degrades user experience. I believe the value proposition of a single TLD that is functional and well-maintained is that it optimizes for maximum adoption. If I have managed to convince you of the necessity of adoption, I’d say any initiative to fragment a TLD puts into peril the entire idea of having a blockchain-based naming service.

You have to face these harder questions when considering a particular naming service and how it fits within broader existing naming protocols. Wanting your own TLD for branding purposes just misses the point of a naming system entirely, until that is, you can negotiate one-to-one with ICANN. The value we’re trying to create here lies way beyond that and is, in essence, community-driven. In my perspective, this community is better served in the medium and long runs by a single unified TLD.

A single domain can & should as far as possible be used for everything

Every use case for a separate TLD can easily be covered within a single TLD. If the desire to create your own TLD is to strengthen branding, there is nothing stopping you from using a registered domain within the already adopted TLD and creating subdomains in place of domains. How you choose to refer to it within the context of your application is merely a UI-level decision, and you’re not opting out of all current and future integrations for no discernible reason.

To be clear, this is not a new idea. It has been long used in the Web2 DNS space. Take the United Kingdom, for example, which only has one .uk TLD: commercial websites are registered under .co.uk and government institutions under .gov.uk. The co.uk domain basically acts as a TLD.

The Name service's functionality is recursive by design (TLDs are functionally equivalent to domain names), the only thing to lose is a slight increase in URL length, but this compromise has a good upside: better integration over time through optimized adoption.

I guess all these loose-hanging thoughts come down to this;

• A TLD is only valuable if there is at least a possibility of widespread adoption
• When evaluating whether a TLD is valuable you have to consider functionality and integration before your own branding prospects
• The value of a name service can be boosted by integrating within an already existing and wider adopted framework, and segmentation suppresses this possibility