Hacker News new | past | comments | ask | show | jobs | submit login

Eventually, all domains expire. It's not just url shorteners.

You can't count on anything on the web lasting. You can't count on anything disappearing either.

When you want the web to be ephemeral, "the internet never forgets".

When you want the web to be permanent, the site you remember will be abandoned and lost.




Yes, and everybody dies one day.

But you don't need to double the problem by making a link rely on two domains and shortening its life.

What's more, if you have the complete original URL, you might be able to use an archive service that might have taken a snapshot, or at least try to guess what was behind the link by looking at it. Shortened URLs are usually inscrutable.


> What's more, if you have the complete original URL, you might be able to use an archive service that might have taken a snapshot, or at least try to guess what was behind the link by looking at it

This is the most important part. Now some smart crawlers figured it out and show you the archived version of the redirect if you got lucky, but so much has been lost because more or less everyone found it aesthetically unpleasing to look at long links. I suppose we weren't aware of the trade-off.


Both the Wayback Machine and archive.today handle redirects by recording the redirect under the redirecting URL and recording the actual snapshot under the final URL (neither perfectly, though—see below).[0][1] And a short URL that occurs many times in the web will be picked up by crawls in the same way as other URLs. Thus, the effect of short URLs on archiving isn't entirely disastrous. Still, the cost is paid in the long tail of short URLs that will never be archived.

Both archive services have shortcomings of their own related to URL shortening:

- archive.is ironically encourages the use of shortened URLs to its own archived snapshots![0] Its long URLs, which I've never seen used in the wild, are for some reason hidden away in the 'share' menu.

- archive.is stores the original submitted URL in the final snapshot and shows it in the header if is not the same as the ultimately archived URL,[0] but WBM does not.[1]

- WBM mysteriously doesn't work on bit.ly (returning only the message 'Job failed.'[2]), but does work on tinyurl.com. Unfortunately, opaque errors like this are not uncommon with the WBM, errors sometimes as serious as snapshots becoming completely blank years after being taken! Somewhat concerning considering its role as an archive, I'd say. If only the Internet Archive had open-sourced their server like Wikimedia did from the start…

[0] example: https://archive.today/KWDbr

[1] example: https://web.archive.org/web/0/tinyurl.com/3k8mma8k

[2] For example, try http://web.archive.org/save/https://bit.ly/3vO29UB

Aside: It's a bit interesting, considering both current events and archive.is's notoriously unclear ownership (the only common info being the domain's registration to an individual in Prague) that two of the five social media sites in the 'share' menu are VK and LiveJournal. Are those commonly used outside of Russia in recent years?


> shortening its life.

Oh, is that why it’s called a URL shortener!


there's no reason an url shortener couldn't be an archiving service as well, other than of course where's the money for that coming from.

on edit: this of course does not answer the inscrutability of the url, only the archiving complaint.


Like https://archive.ph/ivKNO ?

I've actually never seen a long link from archive.today in the wild:

http://archive.is/2022.04.26-061642/https://news.ycombinator...

(For the unaware, the Internet Archive's Wayback Machine and archive.today (they've got many TLDs) are well established as the two major general-purpose web archives.)


> only the archiving complaint.

Only partially: to other archiving services, a shortened URL from this shortener which also happens to be an archiving service is the same thing as if the shortener didn't provide archival.

The only solution I see is that archive services resolve these shortened URLs when they archive a page and archive the result with it. The second best and probably more reasonable solution is that they maintain a directory (mapping) of shortened URLs to real URLs assuming the mapping does not change.

But one can see it's rapidly a mess right?


The problem isn't that web sites or domains expire. It's that adding another redirection like URL shorteners makes another point of failure. And URL shorteners create points of failure across many points. It also makes it more difficult for archival services to keep accurate links to those expired sites as it then needs to keep track of every shortener on every website.


It also hides what was being "shortened". If I find expired url science.com/astrologist-dicovers-alien-life I know who owned it and can guess what the content was. Doesn't happen with random characters or 3rd party short-names.


If url shortener is part of the site, that’s not an issue. Another point is: you can (in theory) change location of url shortener destination, so shortener link can actually outlive original link.


That is the theory. But who actually does that? Who actively monitors if link, which is directed to is dead and then tries to find correct location where the content have moved to?

The only possible solution right now would be to point to the dated content at the Web Archive.


And now you've got two problems.. If you see an upvoted short link, how do you know the party controlling the link hasn't changed the destination from a site everyone trusts? The person controlling the short link may not even be the person sharing it on a platform that trusts them.

With normal sites and content manipulation there's at least a reputational aspect that tends to stick.


>You can't count on anything on the web lasting.

Can I theoretically buy a Domain name outright? Or for 99 years?


most registrars will only let you buy a domain for a max of an expiration date 10 years from today, so after 10 years initial registration you'll be able to renew for 9 years at most.




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

Search: