Hacker News Reader

Comment by jdxcode | Hacker News Reader

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

Or if browsers weren't trying to be too smart enough and use the same box for both searching and addresses. Trips me with .py files all time time.

After ".py", use " ?" (the space is important) to force the search in firefox.

Or just start the query with `?`

Typing `?bla.py` in the omnibar will perform a search for `bla.py` on both Firefox and Chrome

Using a question make in front of the term is traditionally how some browsers trigger search. They usually have a jeybconbe to add it automatically.

For example, in firefox and chrome ctrl-l will clear the URL bar and put the cursor and focus there to take you to the location you enter, and ctrl-k will do similar but pre-fill the location bar with a preceding '?' so a search is triggered on the input.

These shortcuts have existed for quite a while. They used to just focus the respective separate input boxes, when it wasn't all done through one.

What's a "jeybconbe"? It's a googlewhack for this thread.

My best guess is that it looks like a typo for "keycombo".

Yes, thanks. Switched to a new keyboard on my phone, and I'm getting some different typos now. Not necessarily more, I always seem to have a lot that slip through, just different...

And six hours later, as I read this thread, nobody has registered the domain still! ;-)

Press Ctrl+K and browser will be forced to search.

I think that ends up as user unfriendly as requiring the dot after the TLD. I don't read up on all the gTLDs so I didn't realize zip was one for the longest time. I think ICANN just went nuts with TLDs, especially ones like .app and .zip that have long-standing associations with ubiquitous file extensions. That combined with the "smart bar" just leads to trouble.

or go back to left to right reading.

http//com.google.www.

http//com.google.www./file.zip

This is the real answer here. It's widely believed that domains working the opposite way of filesystem hierarchies and even URL paths was a huge design mistake. Think of how many billions of dollars have been lost over the years from account compromises resulting from people not correctly distinguishing yourbank.com/account/foobar from yourbank.com-account.info/foobar.

1. The reason for the change is generally thought to be email: you read least specific to most specific from left to right, like non-American dates, e.g firstname.lastname@group.department.university.edu

2. also I think ! was used rather than . for some networks at some times. Certainly I’ve heard this anecdote from some early users of the internet (or maybe other computer networks)

3. Traditionally the dot is the zero-level or extra-top level domain, a bit like / for root in the Unix file system. Indeed if you use dig you may be familiar that it writes domains like “www.google.com.” My web browser only partly seems to accept this format.

> 2. also I think ! was used rather than . for some networks at some times. Certainly I’ve heard this anecdote from some early users of the internet (or maybe other computer networks)

https://en.wikipedia.org/wiki/UUCP#Bang_path

! was used for manual routing from the source to the destination, when messages were copied from server to server via UUCP. People would write paths like ...!ucbvax!deptserver!myname , which means "you probably know how to get messages to ucbvax; from there, here's how to reach me".

...!mcsun!nuug!fics!el here :-). Of course, those were actual routes, rather than just reverse hierarchies.

And here's an example of an old business card using that format for an email address:

https://en.wikipedia.org/wiki/UUCP#/media/File:UUCP_Email_Ad...

Interesting, and makes sense, seeing as how the Web didn't yet exist when domain names were first invented, but email did. It does make sense that they were thus represented in a manner catering to that use case. In hindsight I guess we'd prefer if emails were backwards too, e.g. com.gmail@cydeweys

Only that the @ ("at") reads terribly than.

So com.gmail/cydeweys maybe?

Or it could be just an object in a global namespace (accesses through a protocol specific facade). So com.gmail.cydeweys

You could easily just use a different symbol, or pronounce it differently. We think it makes sense the way it is now, but that's only because we've all collectively gotten used to the meaning it has in email addresses. If it had had a different meaning all along then that would make sense to us.

com.gmail.cydeweys doesn't really work because you need some way to distinguish that as an email address and not just a subdomain on com.gmail. So it really does need a different delimiter, like how you need a different delimiter in URLs when it switches from the domain to the path (and then also to the querystring and fragment).

'@' was used to mean 'at' or 'each' for a long time before email addresses. Often in pricing. '12 @ $3' means twelve units priced at $3 each. It's referred to sometimes as 'commercial at', including its Unicode name.

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

It was used as 'at' in computing in Algol 68 where it was a shorthand for a keyword 'at'. It has a different application as 'at' in Dyalog APL.

It wasn't remotely as familiar to a broad audience back then as it is now, though. Considering that people accept its non-idiomatic use for website user names even now (which is the same as what I'm proposing no less), I don't think this would be a problem.

Using your example with left-to-right domains and needing a delimiter, one could build a URL structure for mail that changes the protocol but not the path.

https://com.google. for the main page

https://com.google.mail for gmail

https://com.google.mail/localpart for one's own gmail account

mail://com.gmail/localpart to send mail to what is currently localpart@gmail.com

Alternately, we could continue to use '@' and put the localpart first. The URL method of specifying a username or username and password does this for HTTP/HTTPS.

http://username:password@com.site/login

And currently we use mailto:localpart@example.com but we could use mailsend:localpart@com.example instead.

Then of course the web would similarly use

http://homepage.html@org.example

The domain name should definitely still be first. And there are benefits to using a different syntax for domain names than for email addresses, so you can differentiate the two when they're presented out of context (e.g. on a business card or ad).

I was mostly just making a joke about the suggestion that email addresses should look like "com.gmail/cydeweys" from upthread...

But I could _kinda_ of make an argument for it. When I open my browser, I want to go to "the homepage of the company running New Your Times, so homepage@com.newyorktimes - or perhaps the menu from French Laundry - menu@com.frenchlaundry

I would prefer it to read more like UUCP routing. com.twitter@dan

The other nice thing about this system, is that you can drop the domain when the communication is internal.

And if you really wanted to, you could force the communication protocol xmpp//com.twitter@dan vs smtp//com.twitter@dan

This is ironically what’s become popular for service-specific usernames (“on twitter @dan” and “on instagram @danny”). It’s arguably more useful than the email notation because prefixing with the @ is a clear sign that a username is coming next.

> 3. Traditionally the dot is the zero-level or extra-top level domain, a bit like / for root in the Unix file system. Indeed if you use dig you may be familiar that it writes domains like “www.google.com.” My web browser only partly seems to accept this format.

The browser actually handles it just fine, but some webservers refuse to handle it, despite it being a spec. Most famously Traefik and Caddy as webservers refuse to support these, just because their devs don’t understand the spec and think they know better (what a surprise, both are written in go after all)

This actually causes quite a bit of trouble when you have internal systems resolving pretty much everything as local domain first, and some external webservers don’t support the spec. Most famously, caddyserver.com. itself is broken

Or just required the use of the true FQDN - "google.com."

that's what I meant actually—I just forgot it was trailing

Reply on news.ycombinator.com