Solving #1 is interesting because it would also be useful if you didn't care to use a Handshake name and also didn't want to depend on the traditional CA system. It could save the need to for companies to ever install a certificate on their employee's machines along with coordination around updating the certificate.
Handshake is very different than Namecoin. Its possible to come to this conclusion by doing any amount of research. Please consider thinking before speaking in tribalism. There is no good trustless sidechain technology. Sovereign names can exist in parallel to sovereign money and both can benefit from each other.
In blockchains, there is a difference between consensus and policy. The way that the Handshake recursive resolver works is not based on consensus. This means that people can insert rules for delegating a particular request to ICANN or to the Handshake authoritative resolver. It currently checks the Handshake authoritative resolver first, then falls back to ICANN.
If this behavior is easily configurable/shared and open source, then people can opt into whatever configuration that best suites their needs.
Awesome, that's good to hear! Sounds like a pretty easy fix then. Users just need to configure the recursive DNS resolver to delegate existing TLDs to ICANN and that fixes the compatibility issue. I might actually give that a try at some point.
I think ENS is queried more often in a different context than DNS, since many people access it via JSON RPC over HTTP. The interface is an Ethereum contract, although records could be cached in a DNS server if the server can hit an Ethereum node upstream. The two projects feel pretty different for that reason. Handshake could be accessed over DoH potentially.
> If names have to be renewed on a year-by-year basis, is there any mechanism for archival? Won't this be strictly worse for link rot?
Blockchains are good for timestamping. The records on chain can be tracked over time but this doesn't solve the problem of when the blockchain authoritative name server delegates to the tld's authoritative name server. Maybe the tld nameserver could index the records in a git like data structure and be able to serve queries with a time parameter
Proof of Work solves that by preventing Sybil attacks - it's costly to mine (which is equivalent to signing off on, because it wouldn't make sense to sign an invalid block, you would get rewarded). It's the only signature scheme known to be dynamic and allow for an arbitrary participant size. The point is that you can trust the chain with the most proof of work. As long as you maintain a diverse set of peers and validate blocks, you can know the state of the network.
It doesn’t solve this problem at all. The site says:
How do you know that Google's public key is actually Google's public key? When you make that first request to Google, an intermediate network may have intercepted your request and returned a fake public key for Google. CAs attempt to solve this problem. CAs are trusted third parties that verify the authenticity of public keys for websites.
How does proof of work ensure that google.com really goes to Google and not someone who paid $2,000 to mine something?
A miner wouldn’t be able to do that. Only the private key owner of Google could do that. At most a miner could do a double spend attack (would cost a lot more than $2000), but that wouldn’t change the DNS record for Google.
The question is how do you know that the owner of the private key is the “owner of GOOGLE”. That’s what CA’s solve. Blockchain doesn’t solve this problem.
Just make a fun website that is only accessible through the system.
Businesses can own a cryptographic asset (their domain name) that can accrue value based on services provided.
Potentially people may try to use their domains as collateral or experiment in collective ownership of public services through multisig or DAO like constructions.
Hopefully it helps push forward innovation on the chain of trust, opening it up to be something more configurable and dynamic.
The JS implemention is a fork of bcoin, the JS Bitcoin full node and production backend.
It binds to libunbound but you are right that you would want a lower level language for it to be more scalable. There is a rust implemention work in progress here:
https://github.com/UrkelLabs/rsd
Handshake is for top level domains. You can do quick updates using traditional DNS infrastructure at a domain underneath a Handshake top level domain. The benefit is that you have a cryptographic asset representing the top level domain, the root of trust comes from you, value can accrue in the asset itself, its tradable with non interactive atomic swaps and is censorship resistant.
