Hacker News Reader

Comment by dspillett | Hacker News Reader

Excellent plan.

Now we only need to worry about the small matters designing an alternative system that acheives what the domain name system does without those draw-backs, and convincing people to use the new system...

View on HN

There is one, and its called search. People are getting used to ask the search engine on their phones and tablets for finding websites, so the big engineer problem is remaking the service into private instances which isn't controlled by google or apple.

It's true that people find things by googling them, and so it usually doesn't really matter if a hostname is www.gimp.org or eqt5g4fuenphqinx.onion, while it does really matter that the search link via www.gimp.org can break suddenly for no good reason. It also matters that the pages at eqt5g4fuenphqinx.onion are dependent on a server operator.

So on your business card instead of putting your name@domain you can just put "Hey! To find me just google 'my name at my long company name'" and people will end up in the right website, right? And what about email?

Put a QR code of your public key or public key hash on your business card, like the one in http://www.openbsd.org/papers/bsdcan-signify.html. You really only need about 80 bits.

Seems insanely sensitive to fraud and pretty much impossible to implement, in a usable way, on the same scale as current DNS.

There are many circumstances where direct linking is needed, including from outside the system (posters, business cards) - search doesn't work for that.

Even if you go for something like QR codes you want a method that doesn't rely on encoding the fixed network address of a resource (as fixed addresses are usually not as permanently static as they are initially intended).

How would hyperlinks work in this model? If I have a hyperlink "This is an awesome program" that links to gimp.org, how is search going to help if gimp.org goes away?

The hyperlink URL text could contain a secure hash of the gimp.org home page. Or a revision number and the hash of a public key used to sign gimp.org home page revisions. Or of a document containing three public keys, the majority of which need to sign a home page revision for it to be considered a valid value for the link. Or, as in onion services, the hash of the public key of the server hosting the document, along with a document path to send to that server when you manage to reach them. Or a name unique within a certain namespace, and a public key used to sign new versions of the document listing the name-hash mappings for the latest version of the namespace. And maybe a list of IPv4:port pairs to contact to ask for the document. Or the name of a decentralized pub-sub channel where versions of the page are periodically announced — maybe the Bitcoin blockchain. There are lots of possibilities.

"The hyperlink URL text could contain a secure hash of the gimp.org home page. Or a revision number and the hash of a public key used to sign gimp.org home page revisions."

That would help to make sure you got the right page, but wouldn't help you find it.

Your other suggestions (e.g. a list of IP addresses/ports) are basically just reimplementing DNS, but with more complexity. :-)

With more or less complexity (although that statement makes me suspect you’ve never administered BIND) — but with different failure characteristics! And hopefully better ones.

If we look at how people currently share links in social media then url shorterners are very common in use. That would point towards either local or centralized services providing the share-ability of links which would translate between a local address and a global name which may simply be a hash string. There are also QR codes and magnet links which neither rely on a domain name service to operate, but which are used by people to share the address identification for a resource.

They are not trivial solutions to the problem, but the fact that they are in use makes its plausible that a solution can be found.

Reply on news.ycombinator.com