
Introducing Nomulus: an open source top-level domain name registry - kungfudoi
https://opensource.googleblog.com/2016/10/introducing-nomulus-open-source.html
======
robalfonso
Its great that google is open sourcing this, however, its a bit curious as
anyone who is going to be operating a registry really has the resources and
expertise to manage this kind of thing (both hw and sw). Unless the end game
is to get big resource users (like registries) onto GCE, its a bit odd.

~~~
rdrey
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.)

~~~
CydeWeys
You'll be happy to know that we support Gavin Brown's fee extension:
[https://tools.ietf.org/html/draft-brown-epp-
fees-00](https://tools.ietf.org/html/draft-brown-epp-fees-00)

The implementation is here:
[https://github.com/google/nomulus/tree/master/java/google/re...](https://github.com/google/nomulus/tree/master/java/google/registry/model/domain)

And a sample domain create EPP message with an attached fee from our test
suite:
[https://github.com/google/nomulus/blob/master/javatests/goog...](https://github.com/google/nomulus/blob/master/javatests/google/registry/model/domain/testdata/domain_create_fee.xml)

~~~
robalfonso
Can I just say, anyone who uses the fee extension over crazy price api's or
downloaded lists is my friend!

~~~
CydeWeys
We support downloadable static premium price lists too (it's all that some
registrars can handle), but yes, obviously we prefer the price extension too.
Here's the entry point into the static premium pricing lists if you're
curious:
[https://github.com/google/nomulus/blob/master/java/google/re...](https://github.com/google/nomulus/blob/master/java/google/registry/model/pricing/StaticPremiumListPricingEngine.java)

Said lists are imported into the system from the CSV file format that is given
to registrars by this command-line tool:
[https://github.com/google/nomulus/blob/master/java/google/re...](https://github.com/google/nomulus/blob/master/java/google/registry/tools/CreateOrUpdatePremiumListCommand.java)

By the way, can I just say as an aside, that it's so awesome that I can
finally link to and discuss our code in the open (I wrote this pricing stuff
under stuff).

------
tracker1
I'm not quite sure what I expected from this... I do hope it can turn into
something useful that drives down some of the costs/pricing. That said, given
the amount of squatting and land grabbing, I'm not sure I want it to all cost
all that much less.

I'm not sure what the solution is, but $7-15 for most domains isn't killing
anyone's budget. Though having better and faster moving infrastructure in most
registrars would be nice.

------
djhworld
Can anyone explain what is going on with the repo

It looks like they're vendoring all of their third party/first party
depedencies e.g.

[https://github.com/google/nomulus/tree/master/java/com/googl...](https://github.com/google/nomulus/tree/master/java/com/google/common/collect)

[https://github.com/google/nomulus/tree/master/third_party/ja...](https://github.com/google/nomulus/tree/master/third_party/java/joda_time)

Is this a common pattern for modern java projects? I've never seen it done
this way....I'm hoping all those BUILD files are autogenerated...

~~~
jart
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](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.

~~~
bowersbros
What stops you from seeing code you aren't allowed (ie. the search algorithm)
if its a monolithic repo?

Also, with a repository that large, how do you have it setup locally that is
usable?

~~~
hk__2
OP posted a link to a paper that answers your questions:
[http://research.google.com/pubs/pub45424.html](http://research.google.com/pubs/pub45424.html)

------
serge2k
> Internet Corporation for Assigned Names and Numbers (ICANN) announced the
> biggest ever expansion of Internet namespace, aimed at improving choice and
> spurring innovation for Internet users

Not sure what exactly it was really for, but my guess is not that.

On the other hand, maybe innovation is spurred by letting google own ".dad".

~~~
CydeWeys
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.

~~~
serge2k
Oh there is cool stuff. Even just being able to do to search.google and
docs.google or <channel>.youtube is awesome.

I just don't see it as being anything other than a land grab for most of the
TLDs google and other companies registered. If you have a trademark on
something, or you have a good technical proposal (e.g. .ncd for namecoin
backed domain) that you are willing to support then that's fine. .dad, .shop,
.buy, etc...

It's just selling out.

I would love to hear technical reasons for their list,
[https://googleblog.blogspot.com/2012/05/expanding-
internet-d...](https://googleblog.blogspot.com/2012/05/expanding-internet-
domain-space.html)

Anyway, the project is still cool.

------
lolc
What's the process of getting a TLD?

~~~
CydeWeys
More info here:
[https://newgtlds.icann.org/en/about/program](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.

~~~
duskwuff
And at the rate the first round is currently going, the next round is probably
at least 5+ years down the road. So don't hold your breath.

------
captncraig
Is there an easy way to use a non-ICANN sanctioned tld? I kinda like the idea
of my own whole tld, even if it takes some work to access it. Is there a
browser extension or something that lets me add custom registries?

~~~
CydeWeys
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.

------
omouse
what are the other open source options?

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

------
hirzel
I am so sorry. I have to write this here: NomNomNomulus

------
brashrat
[informative comment about corporate PR disguised as open source news removed
as "off-topic"]

~~~
qwertyuiop924
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.

~~~
navls
(comment now censored)

~~~
qwertyuiop924
Well, crap.

