How the URL Was Built(welcometothejungle.com)
welcometothejungle.com
How the URL Was Built
https://www.welcometothejungle.com/en/articles/btc-url-internet
25 comments
Makes more sense but we’d have too many urls starting with com; it would be a bit of a cognitive waste. When the rotaty phone was around more important areas were startig with low digits to save on dialing time. Perhaps a similar type of consideration was used for the current form of urls
Why is it an issue to have too many urls starting with com? We type those at the end anyway
I thought we just press Ctrl+Enter so we don't have to type `.com`. It would feel weird to have that fill in a prefix instead of a suffix, as one's text caret is typically at the end of what you typed so its cognitively similar to performing an insert than an append currently...
Much prefer the first letter I type into a browser bar be one in 26 letters, not 3 at best for most of the internet. Would make random tld's in oppressive countries somehow even more desirable than they already are.
It's a silly idea in the age of url suggestions. I can reach most things I want on the internet with 2 key presses. Everything common in one.
N: Hacker News
C: Cloud Console
M: Gmail
R: Reddit
X: Well you get the idea
It's a silly idea in the age of url suggestions. I can reach most things I want on the internet with 2 key presses. Everything common in one.
N: Hacker News
C: Cloud Console
M: Gmail
R: Reddit
X: Well you get the idea
In this hypothetical where the host name starts with the TLD, I think you could assume browsers would change the way this works, because it is obviously broken lol
In opposition to both the article and the comment above, Usenet (actually uucp) bang-paths are VERY different from domain names, in that they don't represent any kind of organizational (in this case, naming) hierarchy at all, but rather a source-routed path of how to get there. For instance, a uucp email address might look like:
well-known-host!next-host!third-host!fourth-host!mailhost!username
(another syntax for the last 2 nodes above might be username@mailhost, depending - this became popular later on...)
Although this might work just as well: well-known-host!other-host!mailserverhost!username
Note that each hostname in such an address is a short, local hostname, not an FQDN. As shown, the first host was usually a "well-known" host in the uucp world, something like say, ucbvax. While uucp addresses were sometimes rewritten (some intermediate hosts tended to get hammered, and remember, this was back when bits weren't free), this was frowned upon for obvious reasons.
well-known-host!next-host!third-host!fourth-host!mailhost!username
(another syntax for the last 2 nodes above might be username@mailhost, depending - this became popular later on...)
Although this might work just as well: well-known-host!other-host!mailserverhost!username
Note that each hostname in such an address is a short, local hostname, not an FQDN. As shown, the first host was usually a "well-known" host in the uucp world, something like say, ucbvax. While uucp addresses were sometimes rewritten (some intermediate hosts tended to get hammered, and remember, this was back when bits weren't free), this was frowned upon for obvious reasons.
It might be. Many things that use domain names do reverse them. See [0] and [1] for some examples. For many systems, reversing domain names is better, so that is presumably why they do it, because it makes more sense to do it that way for those systems. (It might also help when indexing anything related to domain names; you will want the broadest part first, so that when you search by prefix, you will find anything in that domain and its subdomains.)
[0] https://en.wikipedia.org/wiki/Reverse_domain_name_notation
[1] (My own "Unusenet" specification also uses reverse domain names in NNTP newsgroup names; they specify where the newsgroup originated (not necessarily the same server you are accessing them from), and are used to avoid namespace collisions.)
[0] https://en.wikipedia.org/wiki/Reverse_domain_name_notation
[1] (My own "Unusenet" specification also uses reverse domain names in NNTP newsgroup names; they specify where the newsgroup originated (not necessarily the same server you are accessing them from), and are used to avoid namespace collisions.)
What is "Unusenet" supposed to be? All I can find by searching is you casually referring to it here on HN[0], on Wikipedia[1], and on Usenet[2], as if it's actually a thing.
[0] https://news.ycombinator.com/item?id=21849200 | https://news.ycombinator.com/item?id=22040140
[1] https://en.wikipedia.org/wiki/Talk:Comparison_of_Usenet_news...
[2] http://al.howardknight.net/?ID=160223384800
[0] https://news.ycombinator.com/item?id=21849200 | https://news.ycombinator.com/item?id=22040140
[1] https://en.wikipedia.org/wiki/Talk:Comparison_of_Usenet_news...
[2] http://al.howardknight.net/?ID=160223384800
gopher://zzo38computer.org/0textfile/miscellaneous/unusenet
(copied that gopher link's contents into a pastebin)
https://pastebin.com/raw/qJhSKGyv
Thanks. Interesting, though I'm not exactly sure what problem it's solving or what improvement it's making to Usenet.
It is solving the problem of namespace collision when creating newsgroups that are not part of the main Usenet hierarchies.
If you are setting up your own discussion forums (or blog, or whatever) based on NNTP, this avoidance of namespace collision is useful. (They can still be federated to other servers if wanted; they keep the name where it originated. You can have Usenet and Unusenet on the same server with no collision.)
If you are setting up your own discussion forums (or blog, or whatever) based on NNTP, this avoidance of namespace collision is useful. (They can still be federated to other servers if wanted; they keep the name where it originated. You can have Usenet and Unusenet on the same server with no collision.)
> It is solving the problem of namespace collision when creating newsgroups that are not part of the main Usenet hierarchies.
Thanks for the reply, but you are trying to solve a problem that doesn't exist.
If you run nntp.example.com and someone else runs nntp.example.org, and you both create the local group example.talk.general there will be no "collision", there will simply be same group on two different servers.
That is literally how Usenet functions; different servers carrying the same groups.
If the issue is you don't want posts from other servers on your server's local copy of example.talk.general, or vice versa, then you simply don't send or receive articles for example.talk.general to or from other servers.
Again, simply how Usenet/news servers work.
> You can have Usenet and Unusenet on the same server with no collision.
So what happens if someone creates the Usenet group un2.org.example.a.b.c which you already have as an "Unusenet" group?
Well nothing, because "Unusenet" is simply a word you've come up with to describe a standard, fundamental feature of Usenet: creating (local) newsgroups.
Thanks for the reply, but you are trying to solve a problem that doesn't exist.
If you run nntp.example.com and someone else runs nntp.example.org, and you both create the local group example.talk.general there will be no "collision", there will simply be same group on two different servers.
That is literally how Usenet functions; different servers carrying the same groups.
If the issue is you don't want posts from other servers on your server's local copy of example.talk.general, or vice versa, then you simply don't send or receive articles for example.talk.general to or from other servers.
Again, simply how Usenet/news servers work.
> You can have Usenet and Unusenet on the same server with no collision.
So what happens if someone creates the Usenet group un2.org.example.a.b.c which you already have as an "Unusenet" group?
Well nothing, because "Unusenet" is simply a word you've come up with to describe a standard, fundamental feature of Usenet: creating (local) newsgroups.
> If you run nntp.example.com and someone else runs nntp.example.org, and you both create the local group example.talk.general there will be no "collision", there will simply be same group on two different servers.
That is correct, but the newsgroups might not be connected, and that can cause confusions. If they are connected then it is not a problem of course, but some servers might not be connected.
> If the issue is you don't want posts from other servers on your server's local copy of example.talk.general, or vice versa, then you simply don't send or receive articles for example.talk.general to or from other servers.
While that is possible, some servers may copy it if you do not want to, and you may have a description or purpose which does not match that on the other server, and it can also cause confusion in the client; you may be using multiple servers, each with a newsgroup called example.talk.general, and you will not tell the difference so easily. This might not be a problem for you, but sometimes these issues are significant. Later they might want to copy messages between the two servers, but what if they don't want that newsgroup? It will cause many confusions.
> So what happens if someone creates the Usenet group un2.org.example.a.b.c which you already have as an "Unusenet" group?
If someone wants such a newsgroup, they can connect it to the example.org server, so that messages will be propagated. Otherwise, you will have distinct local newsgroups with the same name, and there can be confusions as noted above.
Ordinary Usenet newsgroup names do not start with "un" and a number, so such things are not expected to occur unless someone deliberately tries to cause collisions (for which the same thing can happen with UUIDs, as well as URIs to identify namespaces in XML and RDF). (By definition, "un2.org.example.a.b.c" is a "Unusenet" group. If someone creates it on Usenet, they should know to connect it with the example.org server.)
Nobody is required to use this Unusenet specification. If it doesn't help, don't use it. But, it is there if you need it.
If you are creating newsgroups in existing hierarchies according to their policies for doing so, then Unusenet is not helpful and can easily be avoided.
(But, see, for example, the thread starting at <[email protected]> on news.software.nntp for some other points of view. They mention creating their own hierarchy, to avoid problems with adding new newsgroups to existing ones; Unusenet is merely one possible way to do so without collision, should you need or want such a thing.)
> ... "Unusenet" is simply a word you've come up with to describe a standard, fundamental feature of Usenet: creating (local) newsgroups.
Well, not quite. The word "Unusenet" I made up refers to the specific set of namespaces which are named according to the specifications in that document. The fundamental feature of creating newsgroups (local or otherwise) is independent, and can be created with or without Unusenet namespacing.
That is correct, but the newsgroups might not be connected, and that can cause confusions. If they are connected then it is not a problem of course, but some servers might not be connected.
> If the issue is you don't want posts from other servers on your server's local copy of example.talk.general, or vice versa, then you simply don't send or receive articles for example.talk.general to or from other servers.
While that is possible, some servers may copy it if you do not want to, and you may have a description or purpose which does not match that on the other server, and it can also cause confusion in the client; you may be using multiple servers, each with a newsgroup called example.talk.general, and you will not tell the difference so easily. This might not be a problem for you, but sometimes these issues are significant. Later they might want to copy messages between the two servers, but what if they don't want that newsgroup? It will cause many confusions.
> So what happens if someone creates the Usenet group un2.org.example.a.b.c which you already have as an "Unusenet" group?
If someone wants such a newsgroup, they can connect it to the example.org server, so that messages will be propagated. Otherwise, you will have distinct local newsgroups with the same name, and there can be confusions as noted above.
Ordinary Usenet newsgroup names do not start with "un" and a number, so such things are not expected to occur unless someone deliberately tries to cause collisions (for which the same thing can happen with UUIDs, as well as URIs to identify namespaces in XML and RDF). (By definition, "un2.org.example.a.b.c" is a "Unusenet" group. If someone creates it on Usenet, they should know to connect it with the example.org server.)
Nobody is required to use this Unusenet specification. If it doesn't help, don't use it. But, it is there if you need it.
If you are creating newsgroups in existing hierarchies according to their policies for doing so, then Unusenet is not helpful and can easily be avoided.
(But, see, for example, the thread starting at <[email protected]> on news.software.nntp for some other points of view. They mention creating their own hierarchy, to avoid problems with adding new newsgroups to existing ones; Unusenet is merely one possible way to do so without collision, should you need or want such a thing.)
> ... "Unusenet" is simply a word you've come up with to describe a standard, fundamental feature of Usenet: creating (local) newsgroups.
Well, not quite. The word "Unusenet" I made up refers to the specific set of namespaces which are named according to the specifications in that document. The fundamental feature of creating newsgroups (local or otherwise) is independent, and can be created with or without Unusenet namespacing.
Thanks for explaining some more. So it's basically an attempt to standardize group naming, to address a fairly specific use case (as with my previous comments, that's not a criticism, just how I'm trying to understand it) of someone not wanting messages from different servers in a particular group?
This goes against how Usenet works in general, allowing people from different servers to have discussions with each other, but I can see how it's useful in some cases, for server specific groups.
This goes against how Usenet works in general, allowing people from different servers to have discussions with each other, but I can see how it's useful in some cases, for server specific groups.
At the time the DNS was being designed, there was some discussion of this, and at least one person was outraged we were doing it the "wrong way." I don't remember the arguments. I think it had something to do with putting the least significant component first being considered more natural. DNS came along a couple years after Usenet switched from a flat to heirarchical name space.
That was neat! Next, maybe you could do ones on URNs. They are much rarer in the wild, compared to URLs, but you can find them in torrent magnet files, isbn: numbers, etc.
They are a powerful concept - give a resource a universal name, regardless of how you locate it. I'm surprised this hasn't taken off as a way to universally point to assets (outside bittorrent), but I guess the challenge there is the resolver, and the lack of a pressing need when URLs do most of what you want.
I just want a way to refer to a file that might be local, http, s3, what-have-you, and always refer to it with the same string, regardless of where it's located.
There's XRIs, but there's, erm, some drama going on there.
https://en.m.wikipedia.org/wiki/Extensible_Resource_Identifi...
They are a powerful concept - give a resource a universal name, regardless of how you locate it. I'm surprised this hasn't taken off as a way to universally point to assets (outside bittorrent), but I guess the challenge there is the resolver, and the lack of a pressing need when URLs do most of what you want.
I just want a way to refer to a file that might be local, http, s3, what-have-you, and always refer to it with the same string, regardless of where it's located.
There's XRIs, but there's, erm, some drama going on there.
https://en.m.wikipedia.org/wiki/Extensible_Resource_Identifi...
Is there a character to demark the end of a url?
If I write into my smartphone notes a url, I prefer to write something like:
Http://google.com/search?q=How to bake cakes$
Than
Http://google.com/search?q=How+to+bake+cakes
iOS Notes treats the second one as a URL and the first one partially as a URL
If I write into my smartphone notes a url, I prefer to write something like:
Http://google.com/search?q=How to bake cakes$
Than
Http://google.com/search?q=How+to+bake+cakes
iOS Notes treats the second one as a URL and the first one partially as a URL
An old convention is <http://google.com/search?q=How+to+bake+cakes>. Really helps with ending periods.
Markdown copied that too: https://spec.commonmark.org/0.29/#autolink
Markdown copied that too: https://spec.commonmark.org/0.29/#autolink
This worked in iOS notes!!
<http://google.com/search?q=How to bake cakes>
Thank you!
<http://google.com/search?q=How to bake cakes>
Thank you!
URLs can't contain spaces
Actually they can, though it is not recommended as URLs appear in running text, which may break lines at space characters. Just look at appendices A and B of RFC 3986.
Although it's recommended that you encode them in user representation (for this reason) you can certainly should be able to send a space character through at the protocol level and if not it's a bug.
Note that a space is not valid in the host name portion if you are using DNS (which most URLs do, of course).
Although it's recommended that you encode them in user representation (for this reason) you can certainly should be able to send a space character through at the protocol level and if not it's a bug.
Note that a space is not valid in the host name portion if you are using DNS (which most URLs do, of course).
The EBNF in appendix A does not allow any spaces. Specifically, there is also this section in RFC 3986.
> 2.4.3. Excluded US-ASCII Characters
> Although they are disallowed within the URI syntax, we include here a description of those US-ASCII characters that have been excluded and the reasons for their exclusion.
[...]
> space = <US-ASCII coded character 20 hexadecimal>
You can certainly encode spaces in URLs but the URL will not contain spaces.
The regular expression in appendix B is irrelevant because it assumes a well-formed URL so spaces do not need to be explicitly excluded.
And at the protocol level you certainly can't use spaces in URLs (in HTTP 1.1) because the request line uses spaces to delimit the URL or path.
> 2.4.3. Excluded US-ASCII Characters
> Although they are disallowed within the URI syntax, we include here a description of those US-ASCII characters that have been excluded and the reasons for their exclusion.
[...]
> space = <US-ASCII coded character 20 hexadecimal>
You can certainly encode spaces in URLs but the URL will not contain spaces.
The regular expression in appendix B is irrelevant because it assumes a well-formed URL so spaces do not need to be explicitly excluded.
And at the protocol level you certainly can't use spaces in URLs (in HTTP 1.1) because the request line uses spaces to delimit the URL or path.
"The www part of the domain identifies the address as a website. We merely use it because of historical convention. Back then, a single server served multiple purposes, the www indicated that a particular subdomain of the server was for website hosting. This is no longer true because we now have dedicated web servers."
Inaccurate.
Inaccurate.
> we use the two words “Internet” and “Web” synonymously.
"We" do? Especially so-called tech blogs like the one that hosts this article?
"We" do? Especially so-called tech blogs like the one that hosts this article?
Instead of news.ycombinator.com we would use com.ycombinator.news, similar to how a news group might be rec.arts.punkrock or comp.os.linux. This makes more logical sense to me, as you start from the broadest on the left (tld) and work your way to the most granular part (the path, query, or fragment of the resource).