Hacker News Reader

Comment by diggan | Hacker News Reader

URLs (uniform resource locator) cannot ever last forever, as it's a location and locations can't last forever :)

URIs however, can be made to last forever! Also comes with the added benefit that if you somehow integrate content-addressing into the identifier, you'll also be able to safely fetch it from any computer, hostile or not.

View on HN

I've been making websites for almost 30 years now.

I still don't know the difference between URI and URL.

I'm starting to think it doesn't matter.

> I still don't know the difference between URI and URL.

One is a location, the other one is a ID. Which is which is referenced in the name :)

And sure, it doesn't matter as long as you're fine with referencing locations rather than the actual data, and aware of the tradeoffs.

It doesn't matter.

URI is basically a format and nothing else. (foo://bar123 would be a URI but not a URL because nothing defines what foo: is.)

URLs and URNs are thingies using the URI format; https://news.ycombinator.com is a URL (in addition to being a URI) because there's an RFC that specifies that https: means and how to go out and fetch them.

urn:isbn:0451450523 (example cribbed from Wikipedia) is an URN (in addition to being an URI) that uniquely identifies a book, but doesn't tell you how to go find that book.

Mostly, the difference is pedantic, given that URNs never took off.

It's almost like URNs were born in an urn! [1]

[1]: ba dum tss

Too bad that URLs and URNs are generally distinct subsets. It would be better if URLs also uniquely identified the resource they are pointing to so you could find it elsewhere if the original location goes away.

An URI is an standard way to write names of documents.

And URL is an URI that also tells you how to find the document.

URLs in the strict sense are a subset of URIs. They specify a mechanism (like HTTP or FTP) for how to access the referenced resource. The other type of URIs are opaque IDs, like doi:10.1000/182 or urn:isbn:9780141036144. These technically can’t expire, though that doesn’t mean you’ll be able to access what they reference.

However, “URL” in the broader sense is used as an umbrella term for URIs and IRIs (internationalized resource identifiers), in particular by WHATWG.

In practice, what matters is the specific URI scheme (“http”, “doi”, etc.).

A URL tells you where to get some data, like https://example.com/index.html

A URN tells you which data to get (usually by hash or by some big centralized registry), but not how to get it. DOIs in academia, for example, or RFC numbers. Magnet links are borderline.

URIs are either URLs or URNs. URNs are rarely used since they're less practical since browsers can't open them - but note that in any case each URL scheme (https) or URN scheme (doi) is unique - there's no universal way to fetch one without specific handling for each supported scheme. So it's not actually that unusual for a browser not to be able to open a certain scheme.

For example: IPFS URI's are content addresses

https://docs.ipfs.tech/

Does this have any actual grounding in reality or does your lack of suggestion for action confirm my suspicion that this is just a theoretical wish?

> Does this have any actual grounding in reality

Depends on your use case I suppose. For things I want to ensure I can reference forever (theoretical forever), then using location for that reference feels less than ideal, I cannot even count the number of dead bookmarks on both hands and feet, so "link rot" is a real issue.

If those bookmarks instead referenced the actual content (via content-addressing for example), rather than the location, then those would still work today.

But again, not everyone cares about things sticking around, not all use cases require the reference to continue being alive, and so on, so if it's applicable to you or not is something only you can decide.

Reply on news.ycombinator.com