Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Use any text as a domain name (github.com/amoffat)
261 points by daenz on Jan 1, 2014 | hide | past | favorite | 141 comments



I might be missing something, but I completely don't get this idea, especially with the examples provided by the author. I have two major concerns:

> Bind searches to domain names, eg "food in chicago" => f02970848a63988965aa40cd368ffcf9046209ca.com

This IMO is bad, and goes in completely wrong direction. We've invented search engines to have such phrases not bound to a particular domain. Who would handle the "#://food in chicago" domain? Would it be Google? Bing? Yelp? Local restaurant chain? Or maybe some scammers? And who would maintain the completely different website "#://food in Chicago", and why "#://Food in Chicago" wants to silently install me some malware?

The reason searching for such phrases makes sense, while having them as domains does not, is that things like "food in chicago" are poorly defined, fuzzy concepts. It would feel weird to change one letter in a query, or replace word "food" with, eg. "something to eat", and see completely different website. Moreover, major search engines are more or less egalitarian wrt. buisnesses. Yes, there's the whole SEO thing, but you can't get full control of what food joints are listed near your location just because you've managed to get the register first. I can (and do) trust listings from Google; they have both incentives and track record of being fair. I will never trust listings from random-autogenerated-squat-scam-business-site.

Which brings me to the second point,

> Good domain names are pretty scarce. It's a source of frustration for anyone who has ever tried to buy a domain.

Yes, they are, and the primary source of frustration is that they are mostly taken by various squatters and other scums of the Internet. What will happen is that, the moment there's any real possibility such hash-domain scheme is introduced, all those evil people and companies will take all the domains like "#://microsoft", "#://android" and "#://insert any popular keyword or phrase here" in order to sell them back to real businesses for boatloads of money. And then we'll be back to square one, with maybe a little bigger domain space than we have right now. Bad people win, good people loose and nothing changed.

So, again, the concepts behind this idea elude me.


The concepts that eluded you were so eloquently explained at the bottom: "This is just for fun! A proof of concept."


The concept it proves is that a string can be hashed, not the concept it presents.


put more levels?

You receive a phrase, then get its hash, enter that hash and geta hashed url?


I get that, but we might keep that in mind while still having a discussion about real-world feasability of such idea :).


I think the point is that it's a dumb concept.


"and the primary source of frustration is that they are mostly taken by various squatters and other scums of the Internet"

"Scums of the Internet"? Oh please.

Where are you getting this all from exactly? You've just decided that since you weren't able to buy a domain [1] that you wanted at a price that you could afford to pay that all domains "are mostly taken by various squatters and other scum of the Internet".

I mean "scum"? How unfair that something that you want isn't available at a price YOU can pay. And if that price was affordable that someone else wouldn't have beaten you to buying it (which is already what happened, right?). I mean it would just be sitting there because nobody else ever thought of using or buying, say "hackernews.com" until PG decided to start Hacker news.

Or perhaps you think that domains are a "public trust" and that there should be some official board designated that decides who is worthy of a particular domain and whether they are "using" that particular domain "the right way". You know to make things fair.

Is that it? Further you are talking about .com because in general and with maybe a few exceptions, you can find many names in other TLD's (you just don't want them) or make a slight modification and have the domain you want in .com.

By the way are you aware that google owns duck.com and refuses to sell it [2] at any price at all? (And has turned down $500,000 for it iim.) Of course they aren't "using it" [3] and only have it because they bought the company that previously owned it

At least if it was owned by a person such as you refer to it would be available for sale at some price.

[1] Or perhaps that wasn't even the case maybe you have just read about other people or know someone that this was the "aggrieved" party?

[2] I was involved in trying to do this. And I communicated and had back and forth with high level people at google who in the end simply said "sorry not interested at any price". And this isn't the first time this has happened with a company either.

[3] It redirects to google.com as if they need that traffic.


I get it, you work for a registrar, so you are naturally defensive (which I understand).

But like individuals who buy empty lots from the Forest Service to resell at a premium, can't you understand why this seems like an inefficient market outcome? Sure, it may be desirable/profitable, but not ideal?

Squatting may be a result of our domain registration system, but is it really desirable? to me it seems like a negative externality, that over-uses free domain names and which sells them for 100x times the price from a registrar, despite their non-use.

Why is a squatter adding any value? Should all domains be bought by one person who uses none for his one purposes, and sells each for 1k?


Explain what you mean by ideal? I'm not sure I get where you are going with that. Domain pricing is determined by economic forces.

"Why is a squatter adding any value?"

Value? What is the value of gambling at the casino or horse racing? Is value the demarcation point of economic activity that is acceptable?

What value does anyone provide who has enough knowledge (and or capital) to be able to buy something in advance anticipating that someone else might find it of value at a later date? We aren't talking about cornering the market on insulin here are we? Am I allowed to buy high volume scanners on craigslist and then sell them on ebay and make money? Am I providing "value"?

"Should all domains be bought by one person who uses none for his one purposes, and sells each for 1k?"

Well what prevents you from doing this to make money? Is it that you a) don't have the capital or b) don't have the knowledge to determine what would sell at a later date or c) you just find it objectionable and desire to not be in that business. (Like porn for example..)

If "c" then can you understand that it's a valid business model, is not illegal and in a sense is about as "fair" as someone buying real estate years ago in a hot area and now expecting to make a profit off that real estate? After all there is a risk in using your capital "a" to take this chance, right? You certainly don't believe that buying a bunch of domains that you think might go up in value is guaranteed do you?


<i>I get it, you work for a registrar</i>

Or AFLAC.


I don't know what "the right way" of "using" the domain name is. But I don't think sitting on the domain without actually using it is the right way.

Who is worthy of the domain? At least the one actually intend on using it is more worthy than the one intending to sit on it to ask for rip-off money.

Squatter are scums.


Domain squatters are no better than investment bankers. They really do the same thing, they make money without creating anything useful.


Would you mind substantiating your generalisation that investment bankers make money without creating anything useful?


What on earth do you think Investment Bankers do? build playgrounds for the local children?

Creating nothing useful is in the definition of "Investment Banker".


Umm, yes actually? Where do you think the playground equipment manufacturer got their initial capital?


From the three Fs? From a customer who wanted some playground equipment? From a crowdfunded philanthropic project that wanted to build some playgrounds? By saving up their income from previous jobs before making a go of a new company?

Basically, from the same places that the manufacturer gets their money from in order to pay dividends to the investors.

Investment banking is _a_ lubricant of industry, not _the_ lubricant, certainly not the fuel.


Wow. How much do you know about business and how long have you been around business?

Do you think that crowdfunding has replaced needing to raise capital through the legacy process of initial public offerings and also that companies that use investment bankers to not seek out a merger or acquisition of another company don't serve a purpose?

What do you think you just need millions to expand and walk into the bank or go to kickstarter?


Aren't investment bankers the ones providing money when one needs to build a new shipyard, oil rig or a power plant? It's definitely out of range of "Three Fs" or Kickstarter.


I think you are confusing "investing in" with "producing". They are in fact different activities.


I believe "creating anything useful" in this context means "doing any useful task"; I don't believe the original poster intended to put nurses, cops, or any service job in the same group as investment banker and domain squatter.

In that sense, investment banker is still a useful and necessary job, unlike domain squatter.


So in your opinion is a domain squatter worse, the same, or better than a real estate investor? That is someone who identifies something that has value that might be able to be sold at a higher value at a later date and buys it for less than they intend to sell at that later date?


IMO domain squatters are worse (and definitely more annoying). While real estate investing still seems like a parasitic activity and I'd be happy for it to disappear, at least when it comes to houses, a buyer usually doesn't care about a particular building - one can equally well live in a house next door, or next street. Whereas domains are almost never interchangable; if someone squats on my-company-name.com (and similar forms), I won't settle for company-my-name-friendshipismagic.com; I am pretty much forced to either buy from them or change the company/product name.


With respect to real estate investors provide liquidity as there is not always an end user who is willing to buy at the time you want to sell.

As far as "squatting on my company name" the majority of the vitriol on HN regarding domain names is not directed at "squatting on my company name" (to which there are clearly defined rules and procedures for recovering a domain (UDRP)) but just at the general idea of someone getting a domain and holding it to sell at a later date.

As far as "to either buy from them or change the company/product name" we are talking the year 2014 here. If you are starting a new company you should be taking into account whether the domain name you want is available. People don't, I know this for multiple reasons. One is that I get assignments to buy domains for startups that have already branded (which they shouldn't have done) and then come and say "I need this domain what can you do for me?" (in so many words).

Now if you are an established company and all the sudden woke up in 2014 and want your domain well then I guess that's to bad. Even back 10 years ago big corporations had this problem because the people they hired didn't know enough to lock up their domains. Either because they were inept or because they didn't feel it was important to have (so what can you say about that?)


I feel like you're being unfair to domain squatters here. Yes, they're scum - but at least they're honest scum.


Squatters are scum. They add nothing of value and make a resource artificially scarce for their own profit. If domain names had no value and people could just buy another one, then squatters wouldn't be making money in the first place.


I can't reply to you for some reason, nick2021, so replying to myself.

It's different because the squatter is essentially leeching off of everyone else. If it wasn't for them the people who wanted the domains could have gotten it for free or at least less. They add nothing of value at all.

One could argue the same for people who squat other scarce natural resources that they paid nothing for.



I agree with you. However making a resource artificially scarce to push the price up is what humans do. From where I am sitting I can see multiple items where this happens gold, diamonds (wife's ring), water (in a glass) electricity (well, a turned in light), several things with brand names on them (the copyrighted logo seems to keep that price up by ensuring that only one supplier exists, keeping supply low). I'd be quite surprised if there was much in the room which wasn't artificially price inflated.


Sort of but it's not exactly the same thing. Physical items generally take effort to build or to extract, and they generally pay for the land or materials or whatever. Copyright is meant to artificially inflate the value, for the benefit of the author who wrote it.

If there is a case of someone just inflating the price and adding literally no value at all then I would say that is just as bad.


Squatters took the .com.au domain that I owned for my old business that didn't get re-registered due to the partnership folding. I went to get it 6 months later, and literally some squatting company had taken it and wanted to "auction it off" -- despite the fact that prior to me, no-one wanted it (its weirdly specific) and seeing as 5 years later they still have it and have just plastered it with ads, no-one still does.

Oh, and that goes against Australian domain regulations, but auDA refuse to do anything about it, sigh. Oh well, they can own a useless (to them) domain if they want to. I just think its silly.


First-to-claim is a really poor way of allocating any kind of resources, and yes, someone who just claims a bunch of stuff under such a system and then waits for it to become valuable due to other people's efforts is scum.

Solutions? I'd like to see something like a tax proportionate to asking price on domains, analogous to a land value tax, to discourage claiming domains that you're not actually using.


You're right, looks like someone already bought f02970848a63988965aa40cd368ffcf9046209ca.com


..and my company's proxy server doesn't like it "Your request was denied because of its content categorization: "Malicious Sources/Malnets"


LoL xD


Some light-hearted stats on domain names

(characters used, length, common sub-strings ...)

http://www.datagenetics.com/blog/march22012/index.html


use this for secret info transfer if you know the right phrase. imagine the phrase being a hash itself.


Reminds me of "RealNames". Dot-com era company. $130 million in funding.

http://en.wikipedia.org/wiki/RealNames

RealNames was a company founded in 1997 by Keith Teare. Its goal was to create a multilingual keyword-based naming system for the Internet that would translate keywords typed into the address bar of Microsoft's Internet Explorer web browser to Uniform Resource Identifiers, based on the existing Domain Name System, that would access the page registered by the owner of the RealNames keyword.


Thanks for the reminder of the name of this company. I was racking my brains to remember the exact name. I visited them back in the day (we were going to sell them IP location technology - deal never happened). They had awesome offices (foosball tables, nice cubes, etc.). Unfortunately they had zero ability to create user adoption. The lesson? Doing a proprietary thing that competes with a universally accepted thing is hard to be successful at. Even with $130 million in funding.


Also, AOL Keywords.


And new.net, though I think that was basically malware. There were a lot of "DNS Alternatives" in the early 2000s.


New.net was terrible. It used to inject DLL into IE, hijack Winsock LSP and whatnot!


Yup, a bad idea implemented poorly.


Google Plus has the same deal now. Search for +Pepsi on Google and it takes you to Pepsi's Google Plus page.

I'm certainly glad they stopped treating + as a search operator so we could get that feature in return.


Any more info? I opened a private tab, went to Google.com, searched on +Pepsi and the results look like what I'd find for Pepsi.


Really? Searching for Pepsi gives me www.pepsico.com, www.pepsi.com and the Pepsi wikipedia page as the top three results, while +Pepsi gives me Google Plus pages for Pepsi as the top three results.

The name for this is Direct Connect, and they announced it in 2011. http://googleblog.blogspot.com/2011/11/google-pages-connect-...


My favourite alternative domain name startup is "Bango," which back in the early days of the mobile internet wanted to make domain names easier to type on phones by replacing them with numbers: http://www.theregister.co.uk/2000/07/20/numeric_domain_name_...


So intensely patent encumbered, then? :)


The is a horrendously horrible idea, for the same reason why unicode domain names are a bad idea. Domain names are important because they provide a reasonable amount of trust. If I type http://apple.com, I'm 99.99999% certain that I've connected to Apple's website. This gets nasty with unicode, because a person can spam your email account and get you to click on a URL which looks very similar to something like apple.com, but really points to a malicious site (thank you cyrillic characters).

Hash based domain names would be even worse. You have no idea what site is lurking behind some big string of hex digits. You could argue that a person should just compare the hash to some known set of hashes, but that's a. cumbersome and b. unrealistic. If it's done by humans, it's error prone (a malicious site could spoof the first few chars to point to their site), and if it's done by computers, what's the point? You've now effectively created a really shitty replacement for DNS.


That's pretty harsh, although you may be entirely correct. I'm not smart enough to know. Please remember that the author did this for fun and despite whatever flaws it may have, it is still interesting to think about.

Is it impossible to overcome the flaws you pointed out? Is there a way to abstract away the risk from the end user? Are there other applications for this where trust is not an issue? At risk of sounding like an idiot, could some sort of distributed proof-of-work/proof-of-stake protocol alleviate some of the trust problem?


>The is a horrendously horrible idea, for the same reason why unicode domain names are a bad idea.

So, you suggest that non english speakers should just "learn it" to use DNS?


Until we can figure out something that doesn't suck, yes. Look, I'm sympathetic with a huge chunk of the world's population having to deal with a (potentially) unfamiliar character set, but what can you do about it? There has to be some standard that everyone can agree to which doesn't compromise the integrity of the net.


This might at first sound like a xenophobic, anglocentric position, but it actually makes quite a bit of sense. There are a number of instances in which it is advantageous / critical to adopt a lingua franca -- that is, a single language that everyone in the world agrees to use for a particular purpose. In the case of domain names, Patrick is right: If we allow characters that appear to be one thing but are actually another, it opens up a whole bunch of evil possibilities.


Couldn't this also be mitigated by making all domains mandatorily delegated from a national ccTLD? Eliminate/redirect apple.com to apple.com.us, then make sure it conforms to the rules for US domains (Latin character set only, etc) whereas apple.com.ru comes under the rules of the Russian registrar?


Language and nation are not the same thing. Sadly, a policy like this would open up a can of worms.

Should the Cherokee syllabary be permitted in .us domains? If so, you are still open to homograph spoofing against the Latin character set(e.g. Ꭹ for y or Ꭲ for T). If not, isn't it a trifle rude to declare that writing system "unamerican"?

What about immigrant languages other than English? Why are Latin-charset language users more American than e.g. Hebrew ones like the long-standing and well-known Yiddish population of New York?

You could ban mixing of code ranges in domains. That might help, but how do you sensibly restrict a code range? Turkish is a Latin charset language, but contains a few extra characters that pose a homograph risk. How do you work out whether a domain is Turkish (and allowed to contain ı) or not Turkish? Also, what if you wanted to differentiate the website for your California-based Yiddish-named restaurant from a similarly named competitor in New York?

Should the governments of Morocco and Algeria be empowered to blanket-refuse Tifinagh domain names? What about when Georgia was part of Russia?


I like this solution. However, ICANN already made profit on .us/.ru domains, when I really think that they should have come as 'free' suffixes to registrations.

e.g.

I buy 'apple.com' and while if I want to leave it as this, fine. However, I should also have 'apple.com.us' and 'apple.com.ru' so that I can handle these appropriately. It's not perfect, but it at least gives my users a chance to say "hey, I probably prefer (english|russian), so please give me that page."

Of course, this is also a bit lazy and somewhat of a non-solution, as this only addresses the issue for English speakers. A russian speaker using the .ru namespace is already willing to "play by the ascii rules."

People going to 'apple.com' really expect to go to the webpage of the American electronics company. One could assume this by the TLD. Users sending a request to 'apple.рф' would be doing something somewhat strange (user sends english base label, followed by a cyrillic tld). This isn't that absurd though, as english company names become loanwords (at least in russian -- see "xerox" or even ask a russian if he owns a 'yabloko makkniga pro' or an 'apple macbook pro' for example). Should the presence of a non-unicode TLD trigger country-specific mode in browsers for the sake of security? How do we handle loanwords (spoiler to above: russians say 'apple' when referring to the brand, even though it shadows the actual Russian word for apple) with non-ascii TLDs?


IMO different language versions of a site should not be based on TLD, but rather a subdomain: us.apple.com, ru.apple.com


_Which_ Latin charset? "ASCII == Latin charset" is somewhat, um... naïve (Yes, that's a part of a Latin charset, and it's even English).


I prefer an unfractioned internet


That's not fractioned. Are you being flippant?


There is some middle ground between opening up all of UniCode and just Latin characters.

It seems that generally a subset of sufficiently distinct characters should mostly suffice. I don't think e.g. Latin, Hebrew and Chinese have much visual overlap.


This is already a solved problem in every major browser. They will show mixed script domains as punycode instead of their unicode equivalent[1][2]. ICANN does not even allow all unicode characters[3]. There's so much FUD going around.

[1] http://www.chromium.org/developers/design-documents/idn-in-g...

[2] http://www.mozilla.org/en-US/about/governance/policies/secur...

[3] https://tools.ietf.org/html/rfc5892


Great links. I'm not sure I'd go so far as to say it's a "solved problem" when there are four different behaviours from four separate browsers, but I'm glad each browser is taking homograph attacks seriously. In the first link, I compared Chrome and Firefox and they do work differently.


> I'm sympathetic with a huge chunk of the world's population having to deal with a (potentially) unfamiliar character set, but what can you do about it?

Well, seeing as that "huge chunk" is a large majority, then the solution isn't "learn english because I'm used to typing URLs _this_ way."

I understand that English is the current lingua franca, but it's aggressive to expect everyone to deal with it just to use the internet.

Why not use our country tlds? It might mean that ICANN has to actually do some work, but I think that the uppermost tld for countries should actually be reserved for suffixes.

e.g.

apple.us #should have never been sold apple.com.us #there, none of that scary unicode apple.com.ru #same unicode problem abound (but at least it addresses the first issue)


Who says you have to learn English?


Punycode.


I hate to break it to you but Unicode domain names are here and have been for a while. For instance this English language page has a couple of graphs about registrations in the .РФ domain. http://кто.рф

Note that you can't just type it in because kto.p? is not the right letters and that last one is obviously not on your keyboard. But cut and paste should work fine.


What is there to learn? Learning to type English character? We are not requiring them to learn English.

Using phone number doesn't require you to "learn" Math.


The alphabet isn't restricted to English. Also, see: punycode.


I think the popularity of url shorteners shows that people are willing to click on links where they have no idea what is lurking behind an unintelligible string.

As for the apple site, there are other (better) systems in place for supplying identity information than just the url.


Unicode domain names are no more dangerous than HTML emails, which can also be used to fool people into clicking links that look like one site but go to another.

Unicode or not, if you type in apple.com on your English keyboard, you will go to the website of Apple, Inc. (Unless your DNS cache has been poisoned.)


> Unicode domain names are no more dangerous than HTML emails, which can also be used to fool people into clicking links that look like one site but go to another.

Except in the case of a carefully selected unicode domain, the address bar will say 'www.paypal.com', not 'www.paypallolimstealingyourlogin.com'.


This mechanism is half way to a suggested scheme for domains that are less vulnerable to single-actor take-downs, posted here on HN a few days ago; https://news.ycombinator.com/item?id=6964090 .

In short; instead of merely mapping to [hash].com the extension could map to [hash].com, [hash].se , [hash].ly, [hash].is, [hash].ch and then use a quorum consensus of whatever answer 3 or more of those names agree on. Effectively each TLD registry (and each of your registrars), along with their regulatory environment, would lose the ability to take down your name without international agreement.

For certain niches, such a feature might be a good enough value proposition to ordinary users to convince them to install an extension.

Other observation; 36-ary is probably a better encoding for the hash data than hex. DNS isn't great with lengthy answers and every byte is worth conserving. But it's cool to see something interesting like this in the form of a browser extension.


Or even ZCode32 to help with readability for when you need to copy written hashes. :)


This is really cool. This is my favourite kind of idea; one that changes something fundamental in a succinct way.

This makes me wonder how important domains are at all. My mum never even thinks about the domains for the websites she visits, she just types in 'ebay' and Google does everything for her.

The only time I think about URLs (outside of coding) is when I have to share a link with someone, but I wonder if even that could be replaced with a sufficiently advanced search engine.


Google search indexing might be one downside of this system, as Google tends to give a lot of weight to domains that match your search term. But in this case the actual domain is a "nonsense" hash.

Perhaps the browser extension could be set so that whenever a search term is entered, it submits Google searches for both the raw text and its hash. If Google has indexed a domain that is a hash, and that exact hash is submitted as a query, you would get the right result as #1 every time.


According to Moz it's hardly important at all: http://moz.com/search-ranking-factors


Exact match domain has the highest correlation of any on-page factor in that table--even higher than keywords in the title or H1.


I would be in favor of this idea if a little more thought was put into how the hashing function works.

As it stands, someone typing in:

food in Chicago

will get a different URL than:

food in Chicago

And the same goes for: Chicago food, chicago food, food near Chicago, etc.

Every one, with a single character difference (extra space, different word order, capitalization difference, regional spelling like theatre vs theater, etc) will result in a different hash.

You've now made 'humanized URLs' into 'no one will guess your domain'.

It's an interesting approach to avoiding search engines, but it doesn't solve the problem that search engines do solve: multiple similar but different entries resulting in the same "appropriate"/top website result.

With this approach, not even face book, Facebook, and facebook would result in the same .com (and please don't suggest just purchasing a billion domains and redirecting them all).


You could add a normalizing step before hashing in the extension, similarly to what's usually done to email addresses typed in by users:

- Remove duplicate spaces and punctuation - lowercase entire query (just like DNS) - Detect and normalize homographs (is this a impossible problem, or are there solutions out there already?)


>As it stands, someone typing in:

>food in Chicago

>will get a different URL than:

>food in Chicago

Why?


IDN homograph attack.


Are you sure? I just pasted both into my UTF8-encoded Linux terminal running `od -tx1` and got the same hex octets. (Also tried in Chrome's JS terminal "<paste string>".split("").map(function(s) { return s.charCodeAt(0); }) ) It's quite probable I don't know what I'm doing, so I'd appreciate knowing how to do it properly.

Also, since these strings would be typed, I'm not sure the homograph attack applies. Why would someone slip in a Cyrillic letter or something while typing the URL themselves? If extended to clickable links that displayed the pre-hash text, I could see the issue, but pudquick specifically said "someone typing in" the two URLs.


Thanks.


To the extent that TLD's are namespaces of hostnames, it's just adding the equivalent of another TLD, but implementing it as a weird proprietary extension on top of .com.

Why?


Some people don't remember RealNames and other keyword systems, and thus must reinvent them to realise it's a bad idea?


My initial thought: This is terrible, because how would we ever know which sites we can trust? Something as tiny as an extra space would change the hash value.

But on second thought, the real problem is that we (the web technology community) have assumed domain names are even a remotely suitable proxy for trust. I don't think most common web users actually get this point. That's why phishing is so easy (except for the part about getting a phishing email past spam filters).

Do you think most people really know (or notice) the difference between webaccess.bankofamerica.com and webaccess.bankofamerica.x8.co? I doubt it.

So the real fix for this situation is creating a true trust system that most actual end users can understand and rely on.

Then, it seems only natural for something like this to be the future. UUIDs will act as the underlying addressing technology with "whatever you want" as your display name.

And as a bonus, it will really cut down on the cybersquatters' profitability.


One downside of this is that you're using a secure one-way hashing function. This means that if for some reason you have the hashed url you can't get the clean one back.

You could use something something like base64 instead.. might work better but it would remove the ability to use files as domain names.


A TXT DNS entry could identify the unhashed text, eg:

  @    TXT   "v=sha1reverse; food in chicago"
The browser could look this up, verify it, and display "#:// food in chicago" in the location instead of the hashed domain name.


Fun story, some of the older (hehe, older as in "older than 30 or 35) people here might remember that in the 90s there was a startup that did exactly this but with a browser plugin as I recall (well, not exactly, they didn't hash the text, but they took arbitrary plain text and mapped it to a URL). The idea was to sell short sentences to companies, so "seinfeld TV show" (or whatever) in the address bar would have gone to the NBC "Seinfeld" web site, etc. I think the idea was to make "deep" links easier for people to remember, but I don't remember the details, I just remember that it existed and I probably read about it in PC Magazine.


This reminds me about how many people don't use domain names at all anymore. Many people probably type the name of their bank into the search bar and visit the first result. I've seen people literally pull up google to search for yahoo mail or ebay.

Domain names are still useful, for a start they provide some level of authentication when mixed with cryptography. (If you visit https://news.ycombinator.com, you can be relatively sure there is no MITM with certain conditions present).

It would be interesting to see how this system can be adapted to work with our current Internet infrastructure.


  --2014-01-01 16:45:59--  https://news.ycombinator.com/
  Resolving news.ycombinator.com (news.ycombinator.com)... 198.41.191.47, 198.41.190.47
  Connecting to news.ycombinator.com (news.ycombinator.com)|198.41.191.47|:443... connected.
  ERROR: The certificate of `news.ycombinator.com' is not trusted.
  ERROR: The certificate of `news.ycombinator.com' hasn't got a known issuer.


This won't work because to me this is similar in concept to URL shorteners. The difference being in the shortening algorithm and the use of expensive domains.

So for example with current shorteners you have:

http://shorturl.com/{algorithm for unique URL goes here}

In the above case using a browser plug in can also eliminate any server side resolution of domains.

With this proof of concept:

http://{algorithm for unique URL goes here}.com

... Except the implementation costs $ if it is to be accepted... And to be accepted it needs to have a benefit that isn't solved by URL shorteners.


Aaand another Chrome extension that bundles jQuery just to do a couple of element selections that could have been done using querySelectorAll...


Fortunately, it is open source. Sending a pull request later this evening when I fix this.


In the interview that Eric Schmidt did to Julian Assange a few years ago, Julian talked about a similar system that I found quite interesting: http://wikileaks.org/Transcript-Meeting-Assange-Schmidt#602


Well, DNS is nothing but a mapping from a domain name to an IP address. All this is is a mapping from a piece of text, to a domain name to an IP address. Alternatively, a mapping from a piece of text to an IP address. In other words, it's nothing but a domain name with different syntax.


Neat idea! One quibble: since the essence is specifying a domain-name in a new way, it'd be good if the 'escaping' convention didnt' clobber/assume a single protocol/scheme. As it stands, it's not clear how this would be used for other schemes, even 'https'.

Perhaps allow 'scheme#' (where naked '#' implies 'http#'), or move the convention entirely to the domain-name area rather than scheme area. ('#food in chicago' -> 'http://#food in chicago' -> 'http://f02970848a63988965aa40cd368ffcf9046209ca.com')


Nice! reminds me of the "4 little words" thing I put together a few years ago http://blog.rabidgremlin.com/2010/11/28/4-little-words/


I dont really want my mid-level domains to potentially be hashes - I want domains at all levels to be intelligible and, optimally, to be named what they are, i.e. foodinchicago.com or food_in_chicago.com or food in chicago.nlp_name

Perhaps enabling spaces in domain names is possible? Since spaces in filenames are allowed I don't see why spaces in names shouldn't be allowed. And then you could have a default root domain for natural language names - .nlp, for instance, and then just assume that name when someone types in a natural language URI with no tld.

We could use something like NameCoin for this TLD to avoid collisions.


As a tangent, I read this earlier today and then got annoyed at not having a quick URL shortener on hand (I got spoiled at my last job, where I could use internal shortcuts for complex URLs like create new Google Doc / link to specific doc, etc).

So, decided to write my first Chrome extension, modelled loosely on your domain name hashing, and here it is: https://github.com/jennielees/jump

It's entirely a personal itch-scratcher, but thank you for the inspiration!


I think this could be accomplished without creating a new system of domain names by using visually similar non-ascii characters in an IDN[1].

"food in chicago.com" becomes "food⋅in⋅chicago.com" becomes "xn--foodinchicago-lj4hc.com"

[1] https://en.wikipedia.org/wiki/Internationalized_domain_name


IIRC these "visually similar" characters cannot be registered anymore due to widespread abuse in phishing/spam emails (päypa1.com, e.g).


They can, but there are limitations. For example, ä can only be used in certain countries (for example, a country where a large number of people speak a language that uses ä).


I like the concept but it still doesnt the solve the problem:

The concept is that if it were accepted by browsers, devs wont have to struggle with squatters for domain names. So instead we register the hash for a word or phrase we want to use and us that as the domain.

BUT. nothing stops the squatters doing the same thing on this new concept. the squatters will just register the hash leaving you in the same problem as before


I don't get the benefit .. the only 'pro' I can think of (spaces in domain names) would be better answered by allowing a space-to-double-hyphen transcoding so

hxxp://food in chicago.com/ encodes to hxxp://food--in--chicago.com

Pros: * Domains can now have spaces

Cons: * Domains are now case sensitive * You visit a domain and it isn't reversible * The google-juice assigned to domain names is gone


just think, if you add a salt that you can change to switch "virtual DNS networks" then everyone can own their own google.com!


Domain names are already a layer of indirection, a friendly way to specify IP addresses. This layer would be a friendly way to specify domain names that are a friendly way to specify IP addresses. And you gain not much else besides the ability to add spaces.

Still, the implementation approach is interesting.


It would be really cool if a tool like this could be used to resolve TOR services' names into hidden service urls. That would make TOR more useful in general, if you could #://wikileaks, for instance.


Hidden service URLs are intrinsic to the security of connecting to them. That's why they're complicated. By adding a second resolution step, you introduce a lot of security issues. How is a user assured that "bla:wikileaks" is the "real" wikileaks, for whatever value of "real" you choose?


I love the idea, I've been thinking along similar lines.

I would add less strict spelling, ie. spelling correction for existing domains, and for domains that are not recognized, go straight to search engine search (ie. google).


My interest was piqued at document archival/confirmation uses.


There was a Chinese company call 3721. They did a similar thing about 10 year ago. They were acquired by Yahoo. Yahoo 3721 was closed about 5 years ago.


The first thing that came to my mind when I saw this: hash collisions. Could problems arise from two keywords that hit the same domain?

Really cool idea, though.


If you find a hash collision, let us know. As security people, we'd be very, very concerned if you can find even one collision or even engineer a collision in SHA1 or especially SHA256.


With SHA1 the chances of that happening are so close to zero that you'd have to create trillions of keywords before you even approach a minuscule chance of hitting a collision.

One of my favorite analogies for SHA collisions: http://stackoverflow.com/a/4014407/690258


This is awesome! I wonder if this could be integrated with "I'm Feeling Lucky"? It would be good for most Google searches IMO.


759730a97e4373f3a0ee12805db065e3a4a649a5.com is available, someone inform cutts


this is a bad idea that will never work

/s


Why do you think that? Please elaborate! HackerNews isn't supposed to be about trolling.

Personally, I like the idea and i'm going to use it. However, it relies on people downloading the extension. If there are enough people using it (which is definitely possible) then it would be successful.


Maybe because it says that on the page that was submitted.


Okay, true. I concede. It's nevertheless interesting.


/s indicates sarcasm


You are entirely wrong. It is a good idea that will never work.


Wrong again! It's an interesting concept but only an ok idea that has no real world application given its limitations.


It need demonstrate only one useful real world application for you to be wrong. It does not need to become universal. As others have said, a web site that validates the consistency of its own content seems to have potential. I would also consider the Internet of Things; a Thing having its own IPv6 address and its own domain name. QR Codes can help take care of the intractability of long hashes.


Agree, it's a good idea that, unfortunately, deals too much with big fishes (in private and gov sector)


This would have some interesting implications for MVC architectures.


Nice idea, but I can see the hash clashing a bit with HTML anchors.


This is quite an interesting experiment, and a step in the good direction, which should and must lead us to the complete removal of domain names.

Why are domain names bad? That should be obvious.

The main symptom of domain names' inherent brokenness is that the law must patch it so that an unknown squatter cannot kidnap some domain, e.g. register "france.com" and ransom it to the people who are most qualified to claim it. This is ridiculous: the squatter should not have had the opportunity to squat this (I know it doesn't apply for "France" but it applies for many other names). Nowhere in the world we see kids grab the seat in front of the fireplace and not let their grandma have it.

Moreover, what if a single ascii string refers to two different things equally claimable by two groups of people? E.g. what about "francfort.com"? Which city would it refer to? A contrieved case: If Chinese people chose a translitteration scheme for their language so that "google" would mean China, wouldn't they have some rights over google.com?

This level of brokenness is not even because of a leaky abstraction, this is a sunken boat everyone has to use to cross the river.

On a more philosophical stance, domain names are wrong because they build a kind of universal language out of nowhere, grounded on nothing, whitout any kind of democratic digestion and acceptance by human beings. We could have a universal language shared by all humans, but it would be a very long process of slow acceptance, with a percolation through all societies all over the world. In this way, there would be many adjustments, reverts, and eventually we would come up with a set of names that is good enough, but right now domain names are just a musical chairs game that is ridiculous and must be stopped.

So I think using a string's hash is a nice step, because it starts blurring the domain name.

However, I think a much better scheme should be to use the hash of the page content as the domain name. In this case, once the hash is determined, who cares where it is, who care which domain it has? It would just be way to download the content. And the job of search engines would be to point us to these hashes.

And dynamic content you tell? Which dynamic content? Does one really care about changes in wiki pages? And for the twitter feed, each tweek is a fixed content snippet, and the javascript fetching them is also fixed, or could be a browser extension. And an up-to-date search engine would have the latest hash for a keyword such as "twitter" or "The Guradian".

A nice side-effect would be that domain name based censorship would become ineffective. And downloading content could be just some p2p checkouts.


How does this solve anything? Instead of registering france.com, I'll register the hash of "France". Adding a level of indirection hasn't provided any benefits.

People can already register domains like "food-in-chicago.com" or "for-sale-baby-clothes.com".

Your contrived example about "Google" meaning "China" in Chinese, is irrelevant. The .CN registrar can enforce whatever rules they want. The US .COM registrar can have its own rules. There's no issue there.


The problem is that .COM is de facto the universal entry point.


Is it, though? I get the impression that people at large don't even care about domain names anymore, let alone whether they end in .com or something else.

In fact, most non-technical users I know go to the sites they visit daily by clicking the first result of the corresponding Google search.


De jure too, isn't it? .us exists for US-specific content; .com ought to be reserved for international sites.


They ought, but aren't. Unfortunately, .com and most (all?) of the other non-national TLDs are under US jurisdiction.


The concept just covers hash-n-slash but you also touched a very different concept of p2p content delivery.

But talking about hash-n-slash why it is bad. Just like domains have the issue of being kidnapped so would be the keywords. For example with the hash-n-slash you would never know where you will end up being when you search for "france". By giving search engine the liberty to direct me to a site I lose the ability to manually choose france.com when some SEO guy has made sure that #://france would lead of francegiggly.com

Same goes with every other keyword, we already have a keyword battle on search engines and it would be better limiting that battle to search engines only. If we push that to browser itself it would be just be chaotic and misleading to people who don't really understand domain authority.

Imagine this being done for pushing phishing website when trying to go to your bank's login page. I get it most bookmark it but many don't and new account holders?

Its just a proof of concept and in reality it has many constraints, the search engine and domain world isn't that broken yet that we need an alternate solution.

As much as its difficult to get relevant domain names its still not impossible to settle for something similar to what you wanted.


Yes hash-n-slash is bad for domain names, that's what I meant: it is a good poison, it will accelerate it's death.


And start of another new challenge for users/visitors to no be 100% about a site's security and authenticity.


Domain names are a low-level technical detail. Their purpose is to provide a level of indirection, so that you can retain a consistent reference to a server while changing the IP address (which is more tightly connected to how the network is organised). That domain names are alphanumeric rather than just numeric has the convenient property that they can serve as mnemonics for the technical workers who use them; this was indeed why they were originally introduce (back when everyone using the internet was a technical worker), but is no longer significant. It doesn't really matter whether France's official website is located at france.com or visitfrance.com or republique.fr or whatever, because it's a low-level technical detail irrelevant to most internet users.


"And dynamic content you tell? Which dynamic content? Does one really care about changes in wiki pages?"

I care about new versions of wiki pages. If you write a page about good French restaurants in Beijing, I would read it. If I want to go back to the same page (= same hash) later, I will get the same page.

However, if there is an updated page, how will I know for sure? In the absence of domain names, a search engine might return some newer pages, but how can it rank them if there are multiple ones with the same title (and claiming the same hash as their predecessor)?

Maybe your server can return something in the HTTP header (like the hash of _your_ updated page)?


rot13 domain names are the future? Humorously, tbbtyr.com is already taken.

I wonder about memfrob based domain names.


This is like pet names but pointless.

https://en.wikipedia.org/wiki/Petname




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: