Introducing Nomulus: an open source top-level domain name registry

That is the goal. This runs on App Engine, Google's PAAS, if the Java lock-in is anything like the Python lock-in I have experienced this won't be very useful outside of their infrastructure. At least not without a major rewrite.

OTOH, one of the justifications for why domains cost $7 instead of $2 is all the quadruple-redundant Oracle databases and such that Verisign uses. If a registry can be built cheaper it argues for lower prices.

> anyone who is going to be operating a registry really has the resources and expertise to manage this kind of thing

Broadly speaking, this only holds true for a limited number of large legacy gTLDs (e.g. .com, .net) and the largest ccTLDs.

It is a bit odd, but I have friends in African countries with TLDs that need to be registered via paper forms / GPG-signed emails only.

This move by Google just massively simplified the barriers to entry for small countries running their own ccTLDs in a more modern way.

(I work for a registrar, dealing with ccTLD idiosyncracies all day. If more registries adopt common premium price extensions, etc, it will make my life a lot easier, too.)

Registrars.

Besides the post of rdrey, this is also a nice PR/marketing move targeting the open source community.

It's essentially an artifact of the way that third-party dependencies are handled in the Google monorepo. If we had started this project from scratch on GitHub, rather than exporting it at a later date, we most likely would not have gone down this path.

I'm responsible for that BUILD file. Here's why I did it.

Every team at Google stores its code in a single shared monolithic repository with petabytes of code: http://research.google.com/pubs/pub45424.html The Nomulus BUILD files you see in the GitHub repository are actually identical to the ones we use internally.

In order to make the BUILD the same both internally and externally, we needed to have some BUILD files in the open source repository, which at first glance, appear to be superfluous. The reason why @guava//jar is mapped to //java/com/google/common/collect is because that's what it's called in the internal repository. By creating this alias, we don't have to update the hundreds of other deps=[...] lines that reference it.

In the future, our tooling will improve and we will no longer need those files. But for the time being, they're a good workaround.

To go into more detail than I was able to fit into the blog post (and keep in mind that I'm writing from my perspective, not ICANN's):

It definitely increases choice. Before the gTLD expansion, you had your choice of the existing legacy gTLDs, your country's ccTLD, and some ccTLDs from other countries that don't have strict location requirements. That's easily under 100 choices. Contrast with now, post-TLD expansion, in which you have over a thousand choices.

There are more opportunities for technical innovation, though admittedly most of the new TLDs so far have been generic open TLDs. But you can imagine all sorts of new things that are possible with closed or restricted TLDs. Some random ideas include: An entire TLD whose registrations are backed by Namecoin or some other blockchain, a secure TLD with really stringent identity verification requirements to cut down on scamming, and a TLD on which domain names never expire and don't have renewal costs (you'd pay more up front for one, understandably). I'm just throwing random ideas out here; this isn't anything we're necessarily working on. But you can imagine lots more possibilities.

More info here: https://newgtlds.icann.org/en/about/program

But the tl;dr is that you need to wait for the next round of expansion if you didn't already participate in the current round.

In principle there's no reason you couldn't. We support an extendable DNS interface, so if you were to integrate that with the DNS system running a local or corporate network, and your DNS provider in your OS set up to use that, it should work. I don't think you'd even need a browser extension. It's one potential use case we've thought of before, but haven't done any specific work towards implementing, so there might be some gotchas or adjustments required in areas where we make certain assumptions that all entities managed by the system resolve at the top level of the Internet.

If anyone does work on something like this, please let me know. I'd be very interested to see the parts in action.

FRED by CZ.NIC: https://fred.nic.cz/ . Open sourced as well and it's been around for a long time.

The one used by the New Zealand registry:

https://sourceforge.net/projects/dnrs/

It's about an open source TLD registry, and it says it's about an open source TLD registry. That's not clickbait: It's perfectly accurate. The fact that it's Google is something you ought to be able to tell, because it's indicated by the domain, something HN always shows.

And just because the collective disagrees with you doesn't mean the site itself is an echochamber. Case in point: You haven't been censored in any way, even though you expressed a different opinion. The collective has merely decided that your comment isn't worth looking at. People can still read it.

In my opinion your comment, now removed, wasn't informative. You complained the title was clickbait and that you initially didn't want to click it (ok, then don't). Then followed about Alphabet's ever increasing privacy invasion.

The source "googleblog.com" next to the title on HN is clear enough. It's a company that open sources a project on github (https://github.com/google/nomulus). I don't think the announcement is disguised, spinned or misleading.

My downvote as off-topic came because it didn't address the announcement itself. To be honest I had the impression you read the title only, not the announcement itself.

That said I think the title techcrunch chose is clearer "Google open sources the code that powers its domain registry"