It is actually pretty easy to keep alive URLs if there is a will to do so. Just have tests in place so you can't mess them up accidentally. And convert things that are not changing anymore to static html.
One of my first web projects involved a music forum and I have been keeping the URLs alive for 24 years now:
It's not easy. Part of the instructions would need to contain things like "how to convince your boss to not just delete the old thing" and "what to do when the startup you worked for went bankrupt" among others. Most URLs don't disappear by mistake.
Well, and pay registrar and hosting fees for 100 years, and then just hope the hosting company doesn't fold in the interim after your passing. The problem isn't "can you make sure it stays up while you're alive", the problem is, after you're gone, you're no longer there to keep the flame alive and there are no guarantees anyone else picks up the torch.
In my mind, the part that is most likely to fail is "return an HTML document that still contains the following text." Nowadays, more and more "HTML documents" do not contain any content at all, just some JavaScript that is responsible for then fetching and displaying the content.
I think the parent is referring to the possibility that one day, browsers might put up a blanket security warning for HTTP URLs instead of following redirects. Or they might try to be a little too clever with HTTPS upgrades.
In particular, the automatic upgrade feature in modern browsers is based on several heuristics rather than explicit configuration like HSTS, so there's always a bit of room for breakage there. For example, they don't even check if the server returns a 301 redirect, which can be problematic if the server wants to redirect to HTTPS on a different host/port or make some changes to the path.
> Or they might try to be a little too clever with HTTPS upgrades.
They're not going to get any cleverer than they are now. In October we'll finally be done with heuristics or central databses of https-first websites used by the various browsers or the half a dozen of headers that you must dance around to get the upgrade to work securely and reliably. They will just default to https first.
At a certain bet size it would almost be self-fulfilling, heh, as one side would be very incentivized to keep at least that url working (buying the domain + hosting it if the page were to die)
It's worth noting that some prediction URLs, for instance: https://longbets.org/6/ are offline.
The original long bet was whether or not computers could pass the turing test by 2029: https://longbets.org/1/
You'd think that LLMs fulfill this, but I do wonder if a clever human could still discern between them given their particularities.
https://longbets.org/9/ is another interesting one depending on whether you think covid leaked from a lab or not.
It is actually pretty easy to keep alive URLs if there is a will to do so. Just have tests in place so you can't mess them up accidentally. And convert things that are not changing anymore to static html.
One of my first web projects involved a music forum and I have been keeping the URLs alive for 24 years now:
https://www.gnoosic.com/discussion/ville+valo.html
I feel like I owe it to the people who participated to keep it online forever. Also as a document of history.
It's not easy. Part of the instructions would need to contain things like "how to convince your boss to not just delete the old thing" and "what to do when the startup you worked for went bankrupt" among others. Most URLs don't disappear by mistake.
Well, and pay registrar and hosting fees for 100 years, and then just hope the hosting company doesn't fold in the interim after your passing. The problem isn't "can you make sure it stays up while you're alive", the problem is, after you're gone, you're no longer there to keep the flame alive and there are no guarantees anyone else picks up the torch.
Anyway to find all bets expiring this year? it will be interesting to see. Could not find a way to search for it there.
> entering the characters http://www.longbets.org/601 into the address bar of a web browser or command line tool (like curl)
The part of this that's most likely to fail at some point is the "http://".
In my mind, the part that is most likely to fail is "return an HTML document that still contains the following text." Nowadays, more and more "HTML documents" do not contain any content at all, just some JavaScript that is responsible for then fetching and displaying the content.
I used to be someone, man, I was a dreamer, a programmer, a man!
Now I'm a human slave copying text from web browsers to chat windows to get around JS rendering bullshit.
One of those things is true
The detailed terms of the bet include this:
> A 301 redirect from www.longbets.org/601 to a different URL containing that text would also fulfill those conditions.
I assume this would cover the HTTP->HTTPS redirect scenario.
I think the parent is referring to the possibility that one day, browsers might put up a blanket security warning for HTTP URLs instead of following redirects. Or they might try to be a little too clever with HTTPS upgrades.
In particular, the automatic upgrade feature in modern browsers is based on several heuristics rather than explicit configuration like HSTS, so there's always a bit of room for breakage there. For example, they don't even check if the server returns a 301 redirect, which can be problematic if the server wants to redirect to HTTPS on a different host/port or make some changes to the path.
> Or they might try to be a little too clever with HTTPS upgrades.
They're not going to get any cleverer than they are now. In October we'll finally be done with heuristics or central databses of https-first websites used by the various browsers or the half a dozen of headers that you must dance around to get the upgrade to work securely and reliably. They will just default to https first.
https://blog.google/security/https-by-defau/
Yes this is about Chrome, but all others will follow.
Yeah that was a clever bit of foresight there.
One thing I've done is include my redirect rules with the web application. So my links continue to work even when I change them and forget them.
https://news.ycombinator.com/item?id=46139686
At a certain bet size it would almost be self-fulfilling, heh, as one side would be very incentivized to keep at least that url working (buying the domain + hosting it if the page were to die)
Amazing that Disqus comments are still live for this page. More impressive even than the website itself being live.
I'm not sure how it played out in 2011, but as of now it looks like the win condition hinges on the redirect.
For the heck of it I confirmed "http://www.longbets.org/601" does in fact result in a 301 redirect to "https://longbets.org/601/". I suspected they might have used a 302.
It's all a matter of whether someone is willing to pay for the hosting.
Which is not, in my opinion, how things should be hosted on the Web.
Freenet had a different approach, even back in the early days (two decades ago). I interviewed Ian Clarke about it https://www.youtube.com/watch?v=JWrRqUkJpMQ
I wrote about it for years: https://community.intercoin.app/t/who-pays-for-storage-nfts-...
And recently I built Safecloud to be different: https://safebots.github.io/Safecloud/
On HN, a TLDR would be helpful, because just clicking your links would potentially mean falling for shilling of ones own side-hustle.
I bet there's complexity to the topic, but I am sure you could put it into a few words instead of just leaving a hook for others to click on.