127 comments

[ 0.17 ms ] story [ 201 ms ] thread
This is golden, it reminds the time when Let's encrypt started. Something that is challenging and can change a lot the direction of the internet.
>Created: 40 min ago
Please don't shame users for creating new accounts. I appreciate that you're trying to protect HN, but we definitely don't want to attack people for joining the site. The damage that does in the case of a genuine new user is much worse than the benefit it provides in the fake user case. If you suspect abuse, please follow the site guidelines and email hn@ycombinator.com instead so we can look at the data.

https://news.ycombinator.com/newsguidelines.html

I don't see information on how names are handled. I know Zeronet started the entire .bit (which can be purchased with NameCoin). Are there reserved TLDs for handshake?

Has ICANN said anything about .bit or .onion TLDs? I suspect TOR is big enough they won't touch .onion, but if they sell .bit, you'll then have some name overlap/conflicts.

The handshake namespace overlaps with the normal domain name system, but they reserve the top 100k domains for the current owners. My only concern is the long term sync between DNS and the old system. But I like the project and I think it’s a good way forward for replacing the current centralized DNS and PKI system
That's just an immediate non-starter then. Nobody is following all of these esoteric systems in the case that one of them gains marketshare, it guarantees that people will be phished and defrauded as soon as they use it. We had this issue with namecoin already, where people went and registered names of prominent people and tried to use that to solicit fraudulent donations.
That’s a fair point and I share the same concern. I would have allowed anyone that owns a domain and can prove it, to get their domain for free in the new system. You could do the proof similarly to how Let’s Encrypt does it
I'd say it extends more than overlap: If a name is not found on the Handshake chain, the resolver "falls back" to legacy ICANN DNS. Since all current gTLDs are reserved as well as the top 100k, there won't be any overlap for a while.
That's great. I didn’t know that all the gTLDs are blacklisted, I thought they only the first 100k. This should make the transition smoother
First impression: Great another ICO.

Second impression: Not a wildly outlandish idea but im not sure if it's a good idea either. Decentralized and automated registrar with a concept of renewals. Nifty.

I'm not really sure how the economics here work out.. Could I scoop up a few million names early on and then hold them forever? Has that already happened? Could this enable anonymous registration? Would these things make users trust these names more or less?

The project raised $10M and then gave 100% of it away to open source projects. They receive some HNS tokens in return. There is a massive airdrop of coins to hundreds of thousands of guthub users, spreading out the money supply to people who might be the most interested in using the system. In other words, this is the least ICO-y new blockchain in a decade.

Names roll out over 52 weeks: HashName(name) % 52 = week number that a name is available. So that should attenuate squatting. Also bidding on names locks up coins for something like 2 weeks, so it's hard to bid on too many names.

Well. That's a nice publicity stunt. lets see how they get their investment back. It's nice that this project does some good. https://github.com/handshake-org/hsd/blob/56c83ca7344def512e...

So if I read this right

Creators get: 102mi coins

Sponsors get: 102mi coins

they are airdropping about 952mi coins to users on github to the tune of 4,246 per user.

So they're collecting about 20% of all coins initially dropped. That's slightly more then some. And at the value listed on https://www.namebase.io/ that adds up to some 102,000,000 * $0.44 = $44mi.

Ok, so it's not an ICO exactly, instead they raised VC funds which is expecting a return by selling coins.

I've just spent a few minutes looking through the website, docs, and a little code. And I have no idea how an end user will use these names. Everything polished about it is for trading coins not real world usage. Sounds like every other crypto coin.

>how an end user will use these names

It’s aimed at open source developers who will be able to figure out how to use the system, not mainstream non-tech normies. As evidenced by the large airdrop to Github.

Most people who own domain names and run websites are mainstream non-tech normies.
Handshake didn't do an ICO. They raised $10.2m from institutional investors like A16Z, Sequoia, Greylock, and Founders Fund, and then donated all the money they raised to non-profits and open-source projects. Here's a notice from the free software foundation when they received $1m from Handshake https://www.fsf.org/news/free-software-foundation-receives-1...
Anyone participating in the GooSig airdrop [1] can technically register names anonymously as their keys will not be exposed in terms of having received the coins.

Additionally, anyone who can obtain HNS anonymously can thus register anonymously.

[1] https://github.com/handshake-org/goosig

They've somehow managed to make the two least optimal choices of language possible.

    The full node daemon, hsd, is written in Javascript.
A non type safe language with poor package management for consensus critical code.

    We also have a light client, hnsd, which is written in C
A non memory safe and error prone language for client code people would run on their systems as root.
I hope more implementations will become available. It’s a decent start, since the C based light client doesn’t expose any services.
You can't say that a C daemon interacting with a network has no attack surface, especially as the thing runs as root.

It promiscuously makes outgoing TCP connections to an unauthenticated P2P network, so given enough time you'll eventually interact with an attacker if there is one.

Well at least you don't have to worry about package management, all the dependencies are built by the organization either from scratch or with vendored code.

Re: JavaScript, you should take a look at the code in repo, it's excellent. There is a such thing as great Javascript code and bcoin/hsd are prime examples.

Better the cannot open shared object file: No such file or directory you know than the left-pad you don't.
I'm very aware of bcoin.

https://npm.anvaka.com/#/view/2d/bcoin

Many steps of indirection away we find things like this include.

https://github.com/juliangruber/isarray/blob/master/index.js

    module.exports = Array.isArray || function (arr) {
      return toString.call(arr) == '[object Array]';
    };
Javascript is an absolute joke of a language.
For real, it can't even work with regular expressions decently.
I don't really see the problem. On any remotely modern version of Node that's just a noop. On ancient versions of Node its a very useful polyfill.
(comment deleted)
This has been tried. It's called Namecoin and it failed to get much traction.

I suspect that using Bitcoin instead would improve adoption dramatically instead of creating yet another token. This can be done using sidechains or something similar.

It is not the same as Namecoin.

Handshake at it's core is a decentralized root zone of trust, the equivalent of ICANN. It's up to people building on it to create the registrars and such.

Previous experiments were for one TLD like .bit or .eth

With Handshake, every possible TLD is released over 52 weeks

Even more so, it works with existing DNS infrastructure and tools. All it is doing is allowing for all TLDs and resolving them (with preference for ICANN / HNS) where the overlap occurs. It was built from the start to exist along side today's systems.

Yeah, domain registration seemed like one of the few problems that potentially (lots and lots of handwaving around the details here) could actually have been a good fit for a blockchain solution.

- It's all public - It doesn't change that often - It is a data storage issue (as compared to processing) - On a per record basis it's pretty small (as compared to trying to store PNGs in the blockchain)

One of the issues with Namecoin is the issuance. You can register any name for a set price. This leads to easy squatting behavior and allows whales to buy up all the good names. Handshake built in mechanisms to improve the issuance of names (detailed in danShumway's comment) which is critical when you're working with the issuance of scarce, non-fungible assets. It's like drawing a comparison to bitcoin and bit gold. Both had the same idea, but the specifics matter.
(comment deleted)
ENS is running on top of ethereum just fine
(comment deleted)
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.
(comment deleted)
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.

Also HNS is a coin, not a token.

Hey Jimmy - I hope the bitcoiners that eventually read this thread can get both sides, as many project teams have received some version of the "do it on bitcoin with sidechains/lightning/liquid/rsk" refrain. I think in practice it's more complicated than that.

First - I tend to think an idea with clear similarities being tried before and failing is default a non-negative (sometimes good) sign: shows us what didn't work, and deepens everyone's understanding/validation of the problem space.

I would also say that it's more similar to Bitcoin than most people would think. Looking at the software, I think it's pretty cool that handshake's first implementation is a fork of a bitcoin implementation that has seen production usage for years (bcoin), one important change is the addition of opcodes to support covenants, so that blinded vickery name auctions can be done fully on-chain.

Basically, Handshake can build on top of the security and reliability that Bitcoin-like systems have validated for us over the last few years: namely, UTXO systems, proof of work, user knowledge/habits around self-custody.

I think Bitcoiners could consider looking at Handshake from this perspective: there is a lot of core technology, architecture decisions, and spirit that is similar. Perhaps if you believe in the potential of public blockchains like many early Bitcoiners do, the solution might not be things like sidechains (which are mentioned as a potential scaling option in the design notes), but extending the core technology in a minimal, single-purpose way (to support auctions)?

Perhaps it is possible that Handshake goes down as one of the best examples of an ambitious new project actually "using Bitcoin" (albeit in a way most Bitcoiners would not immediately agree with) instead of creating "yet another token"?

----

p.s. I've been a fan of yours for years and your content was some of the first I ran into when I was entering crypto full-time. I guess at the end of the day I'm simply curious what you thought of the other projects so far (including Namecoin and ENS) - do you own any names on other decentralized naming systems?

What do you think prevented Namecoin from getting sufficient traction from your perspective?

There is currently no such thing as a decentralized side chain. No one wants all this data on Bitcoin.
I know the handshake devs/maintainers are active on here. I've heard explanations from y'all about how handshake tries to solve the squatter problem. As far as I understand those explanations:

- Names are released at a trickle, meaning no one can buy all of them in one go.

- Names have to be constantly renewed (it's not a buy-once-keep-forever scheme), and (correct me if I'm wrong), you can't buy 10 years out in advance.

- A large portion of the initial names are reserved for Open Source developers, under the assumption that squatting won't be so much of a problem if they get first pick.

It's still not clear to me how this solves resource scarcity.

- If names are released at a trickle, does this mean I might want to register a domain for a project and there literally won't be any able available for me to choose from?

- 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?

- If names are released at a trickle, doesn't this create an even greater incentive for both good and bad actors to grab them as soon as they become available?

I'm mildly interested in Handshake because based on very limited research it seems in general to be an improvement over what we have. I get that perfect is the enemy of the good, I would take almost any improvement over the existing system. But at the same time, I still just don't understand how this helps solve the squatter problem -- every once and a while I ask and get an explanation, and then think about it for a while and end up having more questions.

My perspective is, we want everyone to be online. We want everyone to have their own blog, we want people to be able to create websites on impulse. And we want resilient, long-term links that can serve as permanent addresses for content. The idea of combating squatters is based on the assumption that domain names will continue to be a scarce resource. But you fundamentally can't have domains be a limited resource that are difficult to hoard if you also want random/poor elementary school kids to be able to buy them.

Handshake talks about solving Zooko's triangle: human-meaningful, decentralized, or secure. But the way I originally heard Zooko's triangle explained to me (which may have been wrong) was: human-meaningful, secure, high-availability. Am I correct in assuming that in the second version, Handshake is optimized for human-meaningful and secure at the expense of high-availability? That domains will continue to be a limited, scarce resource that are susceptible to hoarding by people with lots of money? Or are there other mechanisms here that I don't understand?

- Names are released over the course of 52 weeks. Determined by hash(name) % 52. So at worst the name you want to register will not be available until ~51 weeks from now (Handshake launched last week!). - Names have to be renewed bi-annually. You don't need to pay a fee, you just need to submit a transaction to prove you still have access to the private key. I don't think this will be any different than the existing DNS in terms of link rot. - I think the main thing names being released over time does is it allows for more people to find out about Handshake and start competing for the good names before they're gone. In an ideal world, everyone would know about Handshake at the same time, and so any name that is registered has the maximum competition for it. That world is not feasible but we can get closer to it by releasing names over time. - I've only heard Zooko's triangle described in the first way, which matches the wikipedia article on it https://en.wikipedia.org/wiki/Zooko%27s_triangle

Disclaimer: I'm the ceo of Namebase.io, we built a registrar for Handshake domains and exchange for Handshake coins (HNS), so I'm pretty bullish on Handshake.

If I'm understanding you, the 52 week release is a one time thing, not a continual thing? So it's not that names will be continually trickle-released it's that for the next 52 (51) weeks, they'll be trickle-released, and then everything will be out there and this will work just like normal domain registration? I was under the impression that the trickle release was just how registration would work in general.

That doesn't seem to me at first glance like it's going to be that much of an improvement over squatting, but again, I get that there are multiple goals here worth accomplishing. And it is a much simpler system than needing to go into a queue to register a domain.

Just to make sure I understand -- am I correct in saying that Handshake is not designed to solve domain name scarcity, more to decentralize it so that an organization like ICANN can't rent-seek on top of that scarcity?

You are correct in that Handshake is trying to decentralize DNS more so than solve the scarcity nature of naming. That said, Handshake will increase the supply of TLDs by multiple orders of magnitude so the names do become less scarce overall.
Additionally to combat squatting, to register a name, one needs to go thru a Vickrey auction and bid on a name after it is released. Bidding continues for about 5 days thereafter and there are 10 days to reveal the bids.

The winner pays the second highest bid.

Wait, what?

That seems like it could have a lot of unintended consequences, to the point of invalidating all of the benefits from having tons and tons of new names. I have a lot of follow questions about the potential for abuse.

From the squatter/troll angle: if I'm a troll or I'm trying to steal good names before anyone else can get them, what stops me from monitoring the current auctions and stealing domains by bidding above the statistically most likely market price for that domain? Users have to guess in advance how much a domain will cost?

From the decentralized, anti-corporate angle: if I'm Comcast, what stops me from monitoring the current auctions, and blocking anyone who tries to register any variant of `comcastsucks`? With the current system, that's prohibitively expensive since there are tons of variations that I'd need to preemptively register. With the system you're describing, it costs me nothing until someone tries to register a domain that triggers my Regex, and then I just outbid them and block any domain that criticizes me, because as a company I'll always be able to trivially and safely outbid any single person.

From a general user angle: does this mean I have to wait 5 days to register a new domain? With the current system, I can set up a brand new website in a single evening, and all I need to do is find a name that isn't taken yet -- I don't have to worry someone else will see what I'm doing and snipe my purchase. With the system you're describing, I have to wait 5 days to discover whether or not I'm actually going to be able to buy the domain I want at all, and if I don't get it, then I need to repeat the entire process?

I have so many questions about this system now. There has to be something you're leaving out here. I can't imagine using a DNS registrar that made me wait 5 days to discover whether or not I got to have the domain, or that made me guess how much it would cost at the risk of losing the entire domain. If there aren't other details you're leaving out, that's a strictly worse system than what we have right now.

The auctions are semi-blind. You bid, and can optionally add a blind to your bid. The network sees your combined total bid + blind, but won't know your true bid value until the reveal period. So if you want to guarantee you win an auction, just make sure your bid is greater than the highest existing total.
> if you want to guarantee you win an auction, just make sure your bid is greater than the highest existing total.

How do I do that if other people's bids can contain blinds? How do I know what the highest existing total is -- I still have to guess everyone else's total, right?

And even if the auction wasn't partially sealed, even if it was completely public -- I don't see how my concerns above would go away. Isn't it still possible for companies who can trivially outspend anyone else to do regex matches on all of the current auctions and dominate the entire domain space? Don't I still need to wait 5 days to do something that I can do today in less than an hour?

Learning about auctions pretty much entirely, just by itself, took me from thinking, "it's not perfect, but it still seems almost universally better than what we have" to, "no, this would be a massive downgrade from our current system." I thought the point was to stop rent-seeking, not to implicitly allow every fortune 500 company and government to personally vet/block every single domain transaction.

The auction system being described here doesn't just focus on other problems other than name scarcity, it makes the name scarcity problem way worse. If I'm China and I want to censor this system, what stops me from monitoring the auctions and throwing a measly $2000 at any domain name that sounds critical of me in any way? What's the point of having a distributed or decentralized protocol in that scenario?

> How do I do that if other people's bids can contain blinds?

You're right, you can't. I'm not sure what "just make sure your bid is greater than the highest existing total" means when blinds are in the mix.

> If I'm China and I want to censor this system, what stops me from monitoring the auctions and throwing a measly $2000 at any domain name that sounds critical of me in any way?

Nothing, but there are quite a few(TM) domain names. Everything that isn't an ICANN TLD (or a future ICANN TLD, I guess--not sure how that would work) is available. I don't think a government could reliably censor all objectionable TLD's.

Furthermore, once you own a Handshake TLD, you become the registrar for that TLD. So every subdomain is yours to sell, no auction necessary. So as long as someone purchases some simple TLD and is willing to sell you some relevant subdomain, you're good. It's not really necessary to have censorthis/; you can just buy censorthis.sometld. Of course, then you do depend on the owner of sometld as a registrar, but that's not very significant given the space of TLD's available. It wouldn't be difficult to find a new registrar if something happened.

> Nothing, but there are quite a few(TM) domain names. Everything that isn't an ICANN TLD (or a future ICANN TLD, I guess--not sure how that would work) is available. I don't think a government could reliably censor all objectionable TLD's.

If I understand correctly (and maybe I don't), the domain being auctioned is public. With the current system, a government can't censor everything because doing so would require them to pre-emptively grab the entire space, which is economically infeasible. With public auctions, my understanding is they only need to pay attention to the domains someone actually tries to register. So if I'm China, I don't need to preemptively register the entire space of `/tiananmen/g`. I only need to download the list of auctions every day and run a regex on that finite space.

Of course, they can't restrict subdomains, so maybe that allows people to sneak stealth TLDs through without getting censored. But (see below) it seems like actually owning TLDs is really important, so I still need to navigate a space where every troll and every government and every fortune 500 company is given the opportunity to snipe every TLD I want, and it seems like that's at least an opportunity for wild price increases on TLDs.

> Of course, then you do depend on the owner of sometld as a registrar, but that's not very significant given the space of TLD's available. It wouldn't be difficult to find a new registrar if something happened.

Can you expand on this?

Right now, if I lose a .com domain, I can find a new registrar and set up a different domain. But all of the links to my current domain will be broken, and if I'm using that domain for email I'll have lost control of all the emails being sent there, and I'll basically be starting over from scratch.

Part of the reason I've avoided "novelty" TLDs like `.tech`, `.party`, `.amazon`, etc... in the current system is because many of them are completely privatized. The owners of those TLDs can raise prices however they want, and can kick anyone off for any reason. And if I'm tying my entire business or (even worse) my entire online identity to one of those domains, that would catastrophic.

If a registrar behind a top level Handshake domain goes bad, is there a mechanism where I can switch registrars and keep myself as a subdomain of the original TLD? If not, won't I be in the same position?

The thing that's attractive to me about Handshake is owning TLDs -- being able to own something that can't be arbitrarily taken away from me by a centralized authority. Otherwise I haven't gained anything as a user over the current system, I've just lost any regulatory price caps that might exist.

----

I guess I can register an innocuous TLD like `danshumway`, hope the trolls don't notice and outbid me, and then use it as a private TLD I control. Realistically, to preserve privacy and avoid linking everything I do together under a single identity, I'll likely want at least 4 or 5 TLDs, possibly more. I don't think I'm atypical there. Anyone who's using a domain for their email or an identity server will want to own that TLD. Is the system designed to scale to that?

Direct question to the people behind Handshake: what do you expect the average cost of a generic 2-3 word TLD to be? A while ago I registered the domain `animalsareignorant.com` for a personal art project I'm still working on. It costs $10 a year. Are we expecting a TLD like `animalsareignorant` to cost $100? $1000? A million? I assume you've done market research on this and you're not just jumping in blind.

This isn't a theoretical question. When (at this point, if) I ever start using Handshake, at some point I'm going to register a TLD and you're going to ask me how much I want to bid for that domain. So if you expect people like me to be able to guess on the spot what the market value of a TLD is, you nee...

> With public auctions, my understanding is they only need to pay attention to the domains someone actually tries to register. So if I'm China, I don't need to preemptively register the entire space of `/tiananmen/g`. I only need to download the list of auctions every day and run a regex on that finite space.

Sure, but since it doesn't cost anything to lose a bid (I believe?) if anyone tried that it'd be pretty easy to force them to spend a _lot_ of money buying domains that they have no intention of using. It also wouldn't stop anyone from registering `tiananmen.massacre`, as you noted.

> Don't I still need to wait 5 days to do something that I can do today in less than an hour?

It takes months to years to get a tld today with a 185k deposit and no guarantee you'll actually get through the process [1].

[1] https://newgtlds.icann.org/en/applicants/global-support/faqs...

Sure, but owning my own TLD is the only value proposition I see in Handshake. If only big companies can register TLDs, and if I end up renting subdomains from another registrar, what is the benefit to me that the TLD system is decentralized?

I can already rent `.com` subdomains today, and they have price caps. The worst case scenario for a `.com` domain right now is that the current ICANN proposal goes through and the cost jumps up to maybe $20 a year. That's nothing compared to the rent-seeking that can happen on a purely privatized TLD with no oversight.

As a user, buying a subdomain controlled by a single source is not decentralization. I'll still have a single company that can do anything it wants to my domain, and by extension, anything it wants to my online identity. It'll still be trivial for governments to pressure that company into transferring my domain. I won't get to manage my own keys or set up my own security. I won't be able to renew the domain for free.

Unless I'm missing something really big, the only benefit I see from Handshake is democratizing TLDs for ordinary, everyday people.

> I can't imagine using a DNS registrar that made me wait 5 days to discover whether or not I got to have the domain, or that made me guess how much it would cost at the risk of losing the entire domain.

That's fair - may help to compare this with the current tld system, not just the regular domains (x.com). Right now, getting a new tld takes months and a six figure investment. Here it is 5+ days.

After that tld is claimed, it's up to the owner to administer it and make a profit on selling the names, or not.

> Names have to be renewed bi-annually. You don't need to pay a fee, you just need to submit a transaction to prove you still have access to the private key.

When talking about email alternatives here, I see a lot of comments strongly suggesting owning a custom domain and using it. If the domain cannot be renewed and kept alive in advance for a few years, the bus factor of being the only technical person in the family could mean that they lose their emails very soon (worst case scenario where something bad happens to the technical person towards the end of the bi-annual period just before the renewal).

“You need to submit a transaction to prove you still have access to the private key” — “transaction”? “prove”? “private key”? There’s no way this is going to last if people use these domains for emails and mailboxes for their families. At least with the conventional system, it’s easy to note down simple instructions to go to a site, pay and renew. This system seems better suited for institutions that may be able to handle it (though it could be argued that even large companies fail in trivial ways, like it happened with a certificate expiry with Microsoft recently).

I'm not affiliated with Handshake in any way.

But my assumption is that there would still be registrars that can handle this sort of thing for you, in the same way that a service like Netlify can handle setting up a static site server and renewing LetsEncrypt certificates. It's just that if you wanted to do it manually, you could.

Exactly. We built a registrar for Handshake (https://namebase.io) and our service will automatically handle renewal transactions. That said, anyone can still manage their keys and submit renewal transactions on their own if they want to do that, similar to how you can use Coinbase vs a desktop wallet for Bitcoin.
Thanks. I’m still wary of the bi-annual renewal requirement. If I register a name today, can I renew it one year later from today to stretch it to two years from then (which would be three years from now) or would I be able to renew it for two years only near the end of the two year period? In other words, can I perpetually have it renewed to approximately two years in the future at all times? If not, that brings the same risk I talked about in my comment above (where families may not have enough time to figure things out and handle it).
It's not even that. It reads like it's a cliff. Currently under ICANN, if you fail to renew a domain, you have ~90 days to figure out that you didn't renew it before it's lost forever. Even if it's scripted to renew, it could fail for any number of reasons (lack of fiat currency, transient network failures, lack of crypto-currency, etc).
Thanks. That makes sense. For some reason I didn’t think of concentrated service providers because I was too focused on decentralization (and to think of it, such concentrated providers are everywhere in decentralized platforms).
>- Names are released over the course of 52 weeks. Determined by hash(name) % 52. So at worst the name you want to register will not be available until ~51 weeks from now (Handshake launched last week!).

Can you clarify on what "names" means here? Common names, dictionary, every single name that exists in current DNS? If someone has a unique non-word domain right now do they have to submit that? Wait a year?

>- Names have to be renewed bi-annually. You don't need to pay a fee, you just need to submit a transaction to prove you still have access to the private key. I don't think this will be any different than the existing DNS in terms of link rot.

That sounds decent on the face of it but it depends on how automated that can be made, what the window is like, etc. Right now I can renew every 10 years, or do so for 10 years and add on more time every year so that if I ever forget or have trouble once I still have a huge window, and have automated billing/warnings etc. Not free, but pretty reliable. If namebase.io or the like are needed to handle this by most users I also don't see how decentralized that can actually end up being though I guess the infrastructure can help. How are transfers to different registrars handled?

(comment deleted)
Any name up to 63 characters (normal domain name characters, unicode gets converted to punycode) can be registered. The difference with Handshake is that users get to choose how they store their names. There's a spectrum of convenience and self-sovereignty. In traditional DNS the existing system makes that choice for you, whereas Handshake is creating a system where individuals get to choose based on their preferences. I place a lot of value on that freedom to choose.
>Any name up to 63 characters (normal domain name characters, unicode gets converted to punycode) can be registered.

But how does that square with the 52-week staggered release bit? If I wish to go register my domain right now, what happens? I don't see anything on namebase that would simply allow entry of an arbitrary domain, instead the "bid soon" seems to just be a bunch of dictionary words. There is an invitation to enter your handle or whatever, but does that mean all such handles and existing domains have been auto scanned already for entry? Or if I do a search, do you then take that and put it up for auction like so many typical registrars? This is a really basic thing and it's not clear.

>There's a spectrum of convenience and self-sovereignty. In traditional DNS the existing system makes that choice for you, whereas Handshake is creating a system where individuals get to choose based on their preferences. I place a lot of value on that freedom to choose.

No offense but this reads as boilerplate PR mush, it doesn't actually answer anything. Choose what? High level values are all well and good but they're not a substitute for nuts-and-bolts implementation specifics either.

>But how does that square with the 52-week staggered release bit?

It's random, but distributed over 52 weeks because the hash function has psuedo-random output. It's quite clever, IMO. That's what "Determined by hash(name) % 52" means. You want to register "meow" today? Well, then check if hash("meow") % 52 <= currentWeekIndex

That's my understanding, but I haven't actually read any docs.

> 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

> That domains will continue to be a limited, scarce resource that are susceptible to hoarding by people with lots of money?

I don't think so - note that these are for tlds, so a lot of existing internet infrastructure can be used for Handshake names.

Someone who wants elementary school kids to be able to buy them would allow for the purchase (at low, no, or negative cost) of subdomains (traditional domains) - it may allow for a proliferation of hundreds of little self-sovereign registrars with different policies.

`${name}.namesforschoolkids`

Does putting self-signed certs on a blockchain really solve the problem?
Everyone can put self-signed cert on a blockchain. You need to prove that you control the domain. Easiest way to prove that is to ask your registrar. And if your registrar will sign this fact you don't even need to ask him. So you naturally will come to DNS and DNSSec. And all standards are already here: deploy DNSSec, put TLSA record and it's done. It's a solved problem, just not widely supported.
"prove that you control the domain"? isn't that the rub? sounds a bit circular to me at least. there doesn't seem to be any solid replacement for the existing centralized trust authorities. what am i missing?
As long as we're talking about conventional DNS, it's centralized by design. And if you want to build a better DNS, you can just use onion: domain is public key and you can even mine good domains (facebookcorewwwi.onion).
Shameless plug - if anyone wants to try using Handshake, we built a registrar for Handshake domains and an exchange for Handshake coins (HNS) at https://namebase.io. We just launched last week but there's already been a lot of usage so it'll be interesting to see what people do with their Handshake domains when they become available.
Great, what the world really needs is a hideously inefficient set of distributed DNS servers that are permanently eating 100% CPU to do their proof-of-work blockchain mining crap. The page hand-waves this away by claiming (with no good reason) that it will all be renewable energy. Just like bitcoin in China, right?
You missed what HS does. It does not run the DNS system, it extends what ICANN does. The same DNS tools and infra are still used
I am actually curious because I don't fully understand how Handshake works... I believe it allows you to setup a K of N threshold signature scheme for changing DNS, which, is kinda cool, but I don't understand if this would help BGP route hijacking.

Edit: I guess this is a replacement for ICANN not the inter-carrier routing protocols, which is, interesting. Is the point here that if DNS authorities switch to Handshake for authoritative DNS it will be harder to hijack routes? I would love an explanation, sorry it I'm being dense!!

It doesn't address BGP, just DNS. You are correct about the signature scheme though. In fact, names are owned by unspent transaction outputs, exactly like Bitcoin. Meaning you can own a name with whatever weird script you want (2 of 3 before a certain date, 4 of 5 after...) you can even add scripts that allow certain keys to update a DNS resource, but a different key to transfer the name.
Decentralized systems generally have pretty complicated governance models and technology to support them, making it easy to get lost in the details. I've found when trying to assess things like this it's best to find a critical question and find out the details of the answer. For the case of decentralized naming, one interesting question tends to be "What happens when someone registers cocacola.com?"

Usually the answer to that question reveals whether the system is A) not in fact decentralized, or B) not compatible with laws in most jurisdictions.

Anyway, not necessarily a specific critique of this system since I don't know the answer to the question in this case. More just a useful framework I've found to assess distributed systems without getting mired in execution details.

All the existing TLDs like .com and .net are blacklisted so that only the TLD owners can register them. The claiming process for blacklisted TLDs uses DNSSEC so there are no third parties involved in the process. In addition, the top 100k Alexa domains are pre-registered so that only the domain owners can register those domains as TLDs (only google.com can register .google). That is done through DNSSEC as well.
This is useful info and should really, really be in the FAQ. Like, right at the top, because I don't think it's clear right now at all what happens to regular domain holders using them for email, their own services, intranets and so forth. If those in the current registrar system have a reliable path to transition/try it out at some point that's a good start.

Edit to add: your namebase.io FAQ seems a lot more useful than the handshake one. For starters it clarifies that there is a confusing terminology difference, where I guess the handshake people are using "domain" to mean "TLD" and "subdomain" to refer to what everyone typically calls a domain. So a core offering of this system appears to be a blockchain based replacement to the $150k+ (or whatever it is these days) "get your own arbitrary TLD" thing ICANN did, "anyone" gets to register their own TLD. But that raises more questions, like where the actual hardware behind all this goes particularly for existing TLDs which are blacklisted.

> This is useful info and should really, really be in the FAQ. Like, right at the top, because I don't think it's clear right now at all what happens to regular domain holders using them for email, their own services, intranets and so forth. If those in the current registrar system have a reliable path to transition/try it out at some point that's a good start.

Seconding this. I did not pick up on that at all.

I think this is a great question - I'll paraphrase my interpretation: "What does enforcement look like when a big name / known trademark is registered?" - I'll answer the question again in a different way. Will return to this.

----

But first - would like to +1 troquerre's answer - the DNSSEC proofs provide some degree of long-term primacy and compatibility/transferability to Handshake - it'll help minimize conflicts/disputes.

Adding to that answer: I think something often left unsaid is how Handshake is attempting to create incentives for everyone (not just the early devs) to work together and make the internet better. The wide distribution to FOSS developers and donations have been mentioned by the team in other replies, but I'd like to add more:

From the design notes: (source: https://handshake.org/files/handshake.txt)

``` ICANN has been the root namespace for the internet. ICANN (CA, US) is allocated 24,480,000 of the initial coin supply by the Handshake community.

Cloudflare, Inc. (DE, US) is a corporation doing fundamental research for naming, caching, and certificate authorities. They are allocated 6,800,000 of the initial token supply.

Namecoin is a decentralized naming blockchain. 10,200,000 of the initial supply was allocated to leading current and prior Namecoin developers.

Verisign, Inc. (VA, US) is the registrar for .com and .net. They are allocated 6,800,000 of the initial token supply. The .com and .net TLDs on Handshake will be given to Verisign with a DNSSEC proof.

Keybase has been innovating in the naming and certificate authority space. Keybase, Inc. (DE, US) are allocated 0.25% of the total token supply.

Public Internet Registry (VA, US) maintains the .org namespace. They are allocated 3,400,000 of the initial token supply. The .org TLD on Handshake will be given to PIR with a DNSSEC proof to pir.org.

Afilias plc (IE) has been the service provider for the .org namespace. They were allocated 3,400,000 of the initial supply to a DNSSEC proof of afilias.info. Note for both PIR and Afilias, this allocation was made before the proposed sale of the .org namespace. ```

These aren't trivial amounts for typical "ICO project marketing buzz / fake partnerships", they add up to percentages of total supply claimable by DNSSEC proof.

Because of this attempt to align incentives, I imagine there could be a world where community members (FOSS developers and wider mainstream 'internet' folks, not just 'crypto' folks) can get the best of both worlds, where any conflicts between ICANN and Handshake are minimized or the user pain mitigated by resolvers/other service providers.

----

*returning to the original question on cocacola -- the dnssec proof setup helps with .com domains where the holder wants to claim and use the Handshake tld there are a lot of situations where this is not enough.

What if someone registers cocacolacompany, or thecocacolacompany, or coke? It could totally happen:

Source: https://github.com/kyokan/namegrind ``` cocacolacompany,4032,2,false thecocacolacompany,22176,20,false coke,50400,48,false ``` Note: - that output is ${name},${blocknumber},${weeknumber},${reserved} - it can be generated with this tool https://github.com/kyokan/namegrind

If one puts together the pieces from some of the other posts from the team - someone can claim anonymously with GooSig and buy the above names, and the multinational that is "The Coca-Cola Company" will probably attempt to find and enforce trademark protections against the holder -- if they cannot find that person, and it is flagged as an infringing name -- resolvers or some other downstream service...

> mail became Gmail, usenet became reddit, blog replies became facebook and Medium, pingbacks became twitter, squid became Cloudflare, even gnutella became The Pirate Bay. Centralization exists because there is a need to manage spam, griefing, and sockpuppet/sybil attacks.

No, centralization exists because users don't care about the protocol. Users care about the brand.

It's way easier to use FB than it is to say "choose your hosting provider. Each one has a slightly different set of features. Then link with other people you care about, all of whom may be using different providers that you need to pay special attention to." With FB, I click "send a friend request" and then move on with my day. And that's just one example.

> No, centralization exists because users don't care about the protocol. Users care about the brand.

Brand is a proxy for the level of functionality delivered by that brand.

People didn't switch to GMail because it was a "cool" brand, they switched because the spam filtering worked, Google gives you a ton of free space (a problem at the time), and it didn't have obtrusive banner ads. This was passed on by word of mouth, and now GMail is popular.

> It's way easier to use FB than it is to say "choose your hosting provider. Each one has a slightly different set of features. Then link with other people you care about, all of whom may be using different providers that you need to pay special attention to." With FB, I click "send a friend request" and then move on with my day. And that's just one example.

Exactly my point, the UX is better and the network effect ensures that many/most of your friends are already there. It's not about branding, it's about ease of use.

> People didn't switch to GMail because it was a "cool" brand

In the early days of gmail when you needed an invite code, it definitely was a status symbol to have that @gmail.com on your email address.

And at the time, the actual functionality of gmail was far less significant than the fact it was free and decoupled from your internet provider, although you're right the storage capacity on a free email was unheard of at the time.

Gmail invites were at some point a joke. Everyone had them and I wouldn't be able to give them out quickly enough. Maybe at the very beginning they were exclusive a bit, but soon anyone interested could post online and get an invite in minutes.
> And at the time, the actual functionality of gmail was far less significant than the fact it was free and decoupled from your internet provider

If that was the real draw, then people would have just stuck with Hotmail, Yahoo, and the dozen other e-mail providers.

Hotmail and to a lesser extent Yahoo were perceived as toxic, due to spam mostly. There is still a website I frequent which requests customers email to be 'preferably not a @hotmail.com address'. All the other email providers were either restricted (companies, universities, clubs/guilds etc.), poorly run, or tied you to fees (ISP provided, paid email providers, AOL).
> Brand is a proxy for the level of functionality delivered by that brand.

100% agreed.

> People didn't switch to GMail because it was a "cool" brand,

Less agreed on this. Brand is also a proxy for PR, marketing, and the general image of the company. Gmail had an awesome feature set - better than its competitors at the time, but also spread wildly by word of mouth. At that time, Google was an exciting company for most people (it still is by and large, but that's another discussion). Gmail's "invite-only" onboarding was done well and made it exclusive. FB did the same thing when they rolled out to one school at a time.

Ultimately, I think we're on the same page. People want good UX; they want a product/company that their friends recommend; they want something that just works.

I really do not see the point. Naming not only is not important but it also causes issues with trust. I think that the solution that tor/i2p went with is much better.
:\

As has been the pattern with all these decentralized DNS schemes, the FAQ doesn't cover the most utterly basic question: "I currently have one or more domains that I use extensively for my own life/work. How do I transfer those to try this new scheme? How much actual dollars/euros/yen/yuan/... does it cost, not mystery blockchain-whatevers but predictable real money? Does this new scheme harm me?"

Shouldn't an experimental system in particular want regular tech people with personal domains trying it out? We'd probably be more willing to give it a whirl (with fallbacks) since it's more for our own private use. But instead it's all about trademark holders and the Alexa 100k and so on, which is important too but it seems like most such domain holders would be a lot more conservative. And I've had a growing suspicion that the last part of the question doesn't get answered clearly because the answer is "you may get screwed, we are ideologues who think that people should be able to take your domain if you're not rich enough to defend it."

I mean, right now I don't in fact see the current DNS system as horrible. Cloudflare and others are pretty reliable registrars and companies to deal with. A .com is about $8, .net and .org both about $10. A known amount of $200 or so and I'm set for 10 years, and I consider that a good thing. I've had my domains for nearly 20 years now, they're core to my online identity and personal infrastructure. Same for most businesses, DNS sits at the center of everything. My concerns are about ICANN allowed price increases due to monopoly, and whether bad actors could somehow try to claim my domain and how I'd fight that as an individual. But I don't see answers in the FAQ to how this would help answer those. My personal domains aren't in Alexa top-whatever so it sounds like handshake will auction them off. There is a "renewal fee" after that but it's handwave-y:

>Renewals for names are annual and cost a standard network fee

A standard network fee of what? $1? $10? $100? It can vary by thousands of percent at random like so many cryptocurrencies? How long is the renewal window? Can it be paid upfront? What happens if it gets missed? Is any of this predictable?

I simply don't see any brass tacks implementation stuff here. It's a bunch of high level hoohah about the evils of centralization without any acknowledgement of how centralization can be useful and efficient too and how they deal with that. The word "federation" does not appear at all, which is another important approach/aspect. It sounds worryingly like a common "religious" approach where people take a tool (like decentralization) and turn it into a goal in and of itself.

There's an airdrop that gives developers on github claims. Basically if you had over 15 followers on GitHub by August 2018 you likely got 4662 coins (worth a lot since current market price is $0.50[1]). These instructions walk through how to claim the airdrop https://namebase.io/airdrop. This way you can easily register names to try Handshake out even if you already have websites in traditional DNS.

[1] https://namebase.io

Went through the FAQ's, but still didn't understood much about how this is supposed to work alongside ICANN/current DNS system. Well, I didn't got Bitcoin the first 2 times either.

1. "Browsing the web with human readable names is what Internet users have gotten acclimated to." => give me an example of a "handshake" domain name in this case

2. I have some domains/sites not so popular (not in the first 100k Alexa domains). I will only hear about "Handshake" in 5 years time when Handshake completely replaced what we are using today, by which time, someone else might have "registered my domain names". What do I do? Obviously I can prove I own my .com/.net.

To site failed to answer some basic questions/concerns or give some real world use case scenarios.

Own answer to 2: So all existing TLDs are by default "pre-reserved".

Secondly, the 100k top Alexa sites refers to the inability to register a ".whatever" if that "whatever.some_tld" is in top 100k Alexa. So, basically this is "pre-reserving" "gTLD".

In my first impression, these 2 things were somehow correlated.

> I have some domains/sites not so popular (not in the first 100k Alexa domains). I will only hear about "Handshake" in 5 years time when Handshake completely replaced what we are using today, by which time, someone else might have "registered my domain names". What do I do? Obviously I can prove I own my .com/.net.

This is one part that Handshake does not explain very well. The existing domains and tlds that icann owns will continue to work moving forward. The top 100k Alexa domains bit works like this:

For the top 100k alexa domains, the owner receives the root of the domain as a domain in Handshake (ex: the owner of `example.com` receives the domain `example` in Handshake). All `*.com`, etc domains continue to operate as they have in the past.

What happens if someone gets “amazing/“ and then I pay icann to get .amazing?
This is a great idea with one easily correctable but nonetheless fatal flaw: it's an all-or-nothing preposition. If users choose to use Handshake as their DNS roots, they will no longer be able to access websites which only exist on ICANN's root zone.

Assuming I'm not mistaken and that really is how Handshake is set up (someone please correct me if I'm wrong), then IMO the whole project is essentially dead on arrival. There's no chance they're going to be able to convince millions of large websites to register on a new DNS root overnight. And even if they did somehow managed to convince 80% of websites move to the new system, users _still_ wouldn't switch over because doing so would effectively break 20% of the internet for them.

It's a real shame, because this problem would be trivially avoidable if they simply allowed the existing TLDs use the ICANN roots and confined Handshake domains to their own TLD (.handshake maybe). That way, adoption could happen slowly over time and users could switch over to the Handshake roots with no downsides. As-is though this is simply unworkable.

> If users choose to use Handshake as their DNS roots, they will no longer be able to access websites which only exist on ICANN's root zone.

This is not true. You can setup Handshake to be your resolver, and it will resolve both domains on handshake, and legacy domains from icann.

Then what's this paragraph in the FAQ about?

> Existing TLDs and over 100,000 Alexa websites are reserved on the Handshake blockchain. Upon removing collisions, generic, and exclusions (e.g. 1 or 2 character names), approximately 80,000 names remain. Using the root key and DNSSEC, domain owners can cryptographically prove ownership to the Handshake blockchain to claim names.

Does Handshake control existing (`.com`, `.org`, etc.) domain names or don't they? If they do, then what happens when a DNS entry in Handshake's roots contradicts what's in the ICANN roots? If Handshake wins conflicts, then that breaks the internet for existing users.

I have a longer answer here [0], but in short, Handshake does not control existing domain names. They are giving the top 100k existing domain name owners control of a gtld based on the domain they own. Ex `example.com` receives `example` in Handshake's system.

[0] https://news.ycombinator.com/item?id=22312059

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.
Seeing how Internet 1.0 is getting cannibalized by big business and governments, I'm hoping to see HS and other orgs start working on an offline mesh network and devise a completely new system of information distribution.

Humanity appears to be changing the public park infrastructure of the Internet into a paid-access theme park, with [them/someone else] writing the rules. It doesn't look like the righteous, tech illiterates, political manipulators or shareholder driven groups are going to relent.

The Internet used to be filled with raw data, but in the age of centralized, walled garden curating, the essence of the information superhighway has been lost.

It would be cool if they could pioneer a new way to replicate data in the age of autonomous vehicles or use the Internet to transfer volumes of data for offline nodes to broadcast and reimagine DNS and the other fundamental tools to make something like that resilient.

If they could remove most/all of the ads, marketing, monetization and censorship from the data, we might see another generation experience the raw data bliss many of use were raised on in the pre-dot.com era.

It was truly something special and felt like the world (of knowledge) was at your fingertips (instead of something slimey on the other end).

> Seeing how Internet 1.0 is getting cannibalized by big business and governments

How is it cannibalized? It is bigger and cheaper than ever before. To your anti-business comment, HS runs on an ICO powered platform. Isn't that business? It may not be big business but it certainly wouldn't be small if it were to replace a TLD.

> The Internet used to be filled with raw data, but in the age of centralized, walled garden curating, the essence of the information superhighway has been lost.

You mean when it was small enough so that it could be funded entirely by taxpayer money?

> It was truly something special and felt like the world (of knowledge) was at your fingertips (instead of something slimey on the other end).

Sadly that hasn't ended - governments are still burning pubic money like before, the only thing is now it's a drop in the. bucket. Ideally that spending would go down to zero but we have to be patient.

PSA if you had over 15 followers on GitHub by August 2018 you were likely included in the Handshake airdrop. Basically they developed a way to give each dev in the airdrop 4662 coins each (worth a lot since current market price is $0.50[1]). These instructions walk through what the claiming process is like, which can only be done after block 2016 in a day or so https://namebase.io/airdrop.

[1] https://namebase.io

I hope it updates the ssh keys, because I’m pretty sure I roll mine every couple of years.
It doesn't update with SSH keys because the tree is static, but it was updated within a few months ago, so if you claim now (in 1-2 days when claiming is enabled on the mainnet) it should work with your existing keys.
Interesting they are soliciting personalities, rather than infrastructure, sysadmins and others who might have more power to push Handshake. Leaves out a lot of the Great Old Ones too, like say a big hunk of Debian and Ubuntu developers. Or Firefox devs, who have a lot of power here. Lots of projects predate Github. When I looked, I'm honestly surprised how many followers I have there - why would you follow me personally? Rather than the projects? I wouldn't follow me. Seems rather creepy.

Edit: I see elsewhere there have been cash drops to Debian, Arch and probably some other projects. Which makes sense.

It’s not soliciting personalities but rather developers who have made things useful to at least 15 other developers, at least on Github.

They also needed exposed public keys to airdrop to, which limited the airdrop to Github and the WoT strong set.

> who have made things useful to at least 15 other developers

Then why not look how many stars one's repos have? That seems a much better metric to me.

A friend of mine has hundreds of stars on their repos but only 30 followers. I have around a hundred stars on my repos but only 20 followers. Conversely, I've seen people who are into networking, have a lot of GitHub followers, and no meaningful repos at all.

Tieshun, I fulfill those requirements, submitted the claim, was told the Handshake coins would appear in Namebase within half an hour, and... they didn't. The experience was smooth, except for the last part, which was a little underwhelming.

Time to read more about Handshake I guess?

Sorry I should've made this more clear. Txs aren't enabled until block 2016 (in less than 6 hours). The claiming process will only work after then. If you try again after block 2016 it should work! It's currently on block 1970 https://hnsxplorer.com/
It was clearly written in the non-interactive part of the instructions. Apparently I can't read. Thank you for your patience!
Well either way, we’re passed block 2016 now so you can claim! Were you able to try it out?
The only one I wanted isn’t released for a whole year, lucky me
A freaking ICO (shitcoin).

Had I know that I wouldn’t have bothered to read anything about it