I feel like I owe it to the people who participated to keep it online forever. Also as a document of history.
JoshTriplett 2 hours ago [-]
> 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://".
ludwik 60 minutes ago [-]
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.
bombcar 45 minutes ago [-]
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.
someguyiguess 15 minutes ago [-]
One of those things is true
ywain 1 hours ago [-]
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.
kijin 16 minutes ago [-]
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.
oofbey 15 minutes ago [-]
Yeah that was a clever bit of foresight there.
matsemann 48 minutes ago [-]
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)
firefoxd 41 minutes ago [-]
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.
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.
The part of this that's most likely to fail at some point is the "http://".
Now I'm a human slave copying text from web browsers to chat windows to get around JS rendering bullshit.
> 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.
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.
https://news.ycombinator.com/item?id=46139686
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.
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/