Comment by HumanCCF
1 day ago
We don't necessarily, however there are many benefits for doing so. We could simply purchase a domain and then build our initiative beneath it but then everything we do would be beneath that domain, meaning there would be two dots in what is our effective TLD. That would also mean we are a bit beholden to whichever TLD we are beneath and also whichever registrar we purchased our domain from. With the services we hope to offer around things like TLS certs and emails, it just makes more sense for use to own the whole thing from the root.
<something>.duckdns.org. works fine, and being "beholden" to ICANN is no worse than being a client of one of the big traditional gTLDs. If you want "one person, one name", well, .name is there for that.
It's a commons-pollution problem. Are we going to have to start thinking of every word with a dot in the middle as a potential name? IMHO, a new gTLD is justifiable only when there's some concrete differentiator attached to it, e.g. .local indicating mDNS, or .it indicating "Italy"
What value is there in "horse.horse" being something you can resolve with DNS? What value does <something>.self give me, as a reader, that <something>.name or <something>.me or any of the other zillion variations on the same idea doesn't?
If anything, it creates confusion! "Oh, I met Bob McBobFace. Is he mcbobface.me? mcbobface.name? mcbobface.local?".
I have no objection to providing people with free subdomains under whatever assignment scheme you guys are using, but wouldn't <something>.net have worked too, and been a lot cheaper?
I guess I just don't get the value to the public of increasing the set of dotted word suffixes that indicate that a word is a a cognizable DNS object.
> It's a commons-pollution problem. Are we going to have to start thinking of every word with a dot in the middle as a potential name? IMHO, a new gTLD is justifiable only when there's some concrete differentiator attached to it, e.g. .local indicating mDNS, or .it indicating "Italy"
So the new gTLD round is open right now, we're getting more TLDs whether we like it or not. Our goal is to make one that has features built-in which cater to the self-hosting use case. So that is our key differentiator, that every endpoint leveraging our TLD should be someone's small-scale homelab setup.
> I have no objection to providing people with free subdomains under whatever assignment scheme you guys are using, but wouldn't <something>.net have worked too, and been a lot cheaper?
Technically yes it could work, but given the suite of features we'd like to build into our TLD, it would make things more difficult if we didn't own it. We would be dependent on external parties for our root domain, the root of trust for TLS certificates, all users' subdomains would have an extra dot etc.
It just feels a bit like you've decided to solve the hardest possible side quest first.
Everything else on your roadmap could have been built and shipped in the universe that exists, and then if down the road it's working, you could have aimed for your own TLD.
Instead you're putting the TLD first and any of the actual functionality that end users might want afterwards.
2 replies →
You can't purchase a domain, only rent it. If anything, going through a "pay to get a temporary monopoly on some virtual object" is the very opposite of empowering people with more autonomy as the project seems to try to support.