Maybe even the .tld model is too old to help identify hosts. In the beginning of Internet com, edu, gov, mil, org were enough to group hosts. But now, that we have zillions of hosts, .tld might not be enough.
If IPv6 is a response to IPv4 limits, maybe we need something better than .tld, too.
opening up TLDs for sale seems like a (somewhat) logical way to expand the available namespace for domains. We have zillions of hosts, why require them to conform to one of a few random categories.
Certainly, I have issues with how TLDs are allocated and controlled, but that doesn't mean that the general idea of allowing essentially arbitrary top level domains the same the way we do with second level domains is inherently a bad thing.
Some would say the new gTLDs have failed to increase the supply of useful domain names, because the only people who use the likes of .info and .biz are scammers, and that bad reputation scares users off.
It was also well known from the start that the gTLD program was going to extract a lot of rent from domain owners - that the likes of Volvo would end up paying $180k for the .volvo TLD and $300 for volvo.sucks and so on.
Some people see the fact gTLDs had none of the benefits and all of the costs, and yet ICANN keeps on issuing them, as a sign that it was never about the benefits to begin with - that it was about shaking people down for rent all along.
I tried to buy california.beer on the first day .beer was available to the public. It was always listed as unregistered but if I tried to buy it strange errors occurred.
After the time period where they were required to allow registrations for a set price, california.beer was listed for $1000+.
Any of .onion, .bit, .coin, .eth, .crypto, .zil, can expect the .dev treatment, or, in time there won't be many nice available one for future developments. Similar issue might be with things like .ipfs, which don't resolve in the usual sense, but could cause confusion if there was an ICANN .ipfs domain.
Some domain trader will come and say those aren't "real" names, and you are supposed to rent them from ICANN, but that seems like a protection racket.
https://www.iana.org/assignments/special-use-domain-names/sp...
It does the reverse. There is only one root zone. Before the root was a free-for-all there were hundreds of different areas to set up shop in the namespace. Now there are exactly two: 1. have fuckloads of money to piss away on a vanity TLD, or 2. use someone else's TLD.
Every TLD has the same possibility space as the root zone, but we only get one root zone. There are no do-overs. Careful creation of TLDs allowed mistakes of previous TLDs models to not be repeated, experimentation with different implementations, business models or namespace allocation strategies. Now there's exactly one.
We used to have headroom at the top to sidestep "hope an existing brand isn't squatting the name" and try things like country code TLDs, .arpa, and .int. Or tack resolution experiment onto the side with .local or .onion.
If you wanted to do any of those now, it's impossible because the namespace has been reduced. Go back to options 1 and 2.
I fail to see alternative DNS as much better solution, as that still depends on having tlds.
For sure, identifying hosts in a "good for all purposes and all actors" manner it isn't a easy problem to solve, but it something that might makes lives of many easier.
And even if you come up with a great solution, how you convince most actors to use it?
If we had DNSSEC and DANE support in browsers, it would solve the security problems stemming from certificate authorities being able to issue certificates for any domain they like. Handshake would enable people to actually own their domains and bypass the CAs altogether.
Definitely a valid point - DNSSEC and DANE are incomplete without Handshake [1].
> quirky version of the DNS
It's the same DNS, simply the root was decentralized from ICANN to the commons.
> I don't understand why this project is taken seriously.
The reason the project is taken so seriously by so many is because the project improves our internet by improving security [2] and gives ownership of the internet back to the people where it originated, and where it belongs [3].
[1] https://github.com/handshake-org/hdns
[2] https://handshake.org/files/handshake.txt '### Proof of Work as a Trust Anchor'
[3] https://handshake.org/files/handshake.txt '# Stakeholders'
Rather than being a 'blockchain' project, Handshake is a project that makes use of blockchain technology to solve a real problem that the world has been trying to solve for some time [2].
Later:
Sure looks monetized:
https://www.coingecko.com/en/coins/handshake
Is this just someone stealing the Handshake project's name, or does the Handshake project really believe that a piece of Internet infrastructure will be run off a trading cryptocurrency --- and, not just that, but their trading cryptocurrency?
Perhaps if you're really short on time (aren't we all?), you might at least find it amusing that the Handshake developers took $10 million of VC money and donated it to Free and Open Source foundations [2]. That was actual cash donated, not just magical internet money.
It doesn't even matter what I think about this design. Speaking positively, not normatively: this is never going to happen. Everyone from billion dollar corporations to academic research labs to inexplicably influential Internet curmudgeons working out of basements will recoil from this.
With that aside, to answer your question regarding monetized/cryptocurrency, here is an excerpt from the notes and there are far more details that can be found therein:
A blockchain is proposed which optimizes for correcting prior weaknesses around acknowledging stakeholders such as existing top-level domain (TLD) holders and optimizes for decentralization (while still allowing for n-of-m attestations). Users use the native token (coin) to register TLDs which are pinned to a specific certificate as the identity. A committed merkelized proof of all top-level names allow for compact, shareable inclusion and exclusion proofs. This blockchain exists to attempt to resolve the need for a globally unique namespace which is necessary to have an association with unique names and certificates. While it's possible to create a singular centralized globally unique association (DNSSEC), a decentralized system can be resolved by creating a blockchain with its own cryptoeconomic incentives (coin), including name auctions of a unique namespace and block creation. Scarce resources require sybil protection, usually managed by a central trusted authority (CAs, ICANN), but can be resolved by having a blockchain based mechanism for global consensus and resource allocation.
[1] https://handshake.org/files/handshake.txt (# Project Summary)
If so: it's a dead project. I don't know why anyone would take it seriously. I'm skeptical of the entire model for any application. But for Internet infrastructure? Never going to happen.
Handshake is based on the ideal that the internet belongs to the people.
> If so: it's a dead project. I don't know why anyone would take it seriously. I'm skeptical of the entire model for any application. But for Internet infrastructure? Never going to happen.
People will always strive for better. I believe it will be Handshake, but if not, something else will come. People find a way, that's how we all got here today. This very thread itself is proof that the current system doesn't fulfill the wishes of humanity and there is a need for change.
If you believe Handshake has faults, let's all work together and improve it!
The step seemed like it lacked any understanding of the mechanism design of handshake, and I realized it's because we skipped a step here. I like to start my count with 0:
Step 0: Please read the design notes document. Let's be constructive here.
Later:
In all seriousness, though, I urge you to read and understand how Handshake works and how different it is from these other 'cryptocurrency' projects that I am (and I'm sure many in the hn community) on the exact same page as you about. I trust you'll see why the community is moving in this direction.
Later 2:
Just incase you don't read the paper, the coin, and auction process, helps prevent sybil attacks among other things.
It’s clear you believe the usage of blockchain technology in Handshake is justified. But throughout this thread, whenever the question of ~“is your project backed by a cryptocurrency which is traded speculatively” has been posed, you’ve dodged answering it outright.
Later: My first response [1] included a direct answer pasted from the design notes - and it’s very clesr. Unfortunately, it won’t help if you don’t know what a Sybil Attack is. I incorrectly assumed that was basic knowledge in 2020 for anyone on Hacker News [2].
Instead, you’re deflecting by insinuating that we haven’t read the spec, and thus refusing to answer the question we’re posing to you.
If you're saying B) I didn't explain to you what a sybil attack is, you're right, albeit I did provide a link.
In a global unique namespace that has no centralized control, there needs to be constraints and scarcity built into the system itself in order to prevent someone from launching a "sybil attack" which, in this context, means someone could register a trillion names without anything stopping them. By introducing a coin that in itself is a limited resource and including an auction process, essentially, there are a limited number of names since there are a limited number of coins, and, in addition, the auction process itself helps to prevent someone from getting a lot of coins and registering many names.
This explanation really just touches the surface as all the intricacies of the architecture are better detailed in full, in our project design notes [1] as I have continued to urge you to read.
You get 63 bytes (really, ASCII chars, fewer Unicode codepoints using IDNA) per-label in a DNS domainname, and you can have many labels per-domainname, which means we really can't run out of names the way we have run out of IPv4 addresses. The comparison you drew is just not valid.
By "tld" you seem to mean "DNS". DNS is basically irreplaceable at this point. We can replace the UDP port 53 protocol with, e.g., DoT (DNS over TLS) or DoH (DNS over HTTP), maybe nice RESTful APIs -- whatever, but we can't replace the DNS data model because it's too deeply embedded, and not exactly busted and in need of replacement.
That is, domainnames are here to stay. DNS Resource Records are here to stay. Access methods and representation on the wire can change, but their semantics can't.
Given that, more TLDs, or not, makes no difference whatsoever to availability of domains for all sorts of organizations, as well as individuals.