It seems like that the first website http://info.cern.ch/ (made almost 30 years ago) still works in a today's browser, but is it possible to build a website that will really last 30 years without any kind of maintenance (i.e. a website that will stay up for 30 years after the author passes away)?
I think about this a lot. My site is now 28 years old [1], older than wikipedia or google or even slashdot. People still read the gamedev pages, and I still update them. Coincidentally, I was just writing some notes on this topic last week [2].
1. Hosting. I was lucky in that Stanford gave me a place to put pages. I think it was more common back then for universities to do this. Now I have a domain name which I register for 10 years at a time. But that's not going to last 30 years after I pass away. And even if I had the domain name, my server (currently AWS) won't stay up if I don't pay the monthly bills. My Stanford pages will stay up longer than my RedBlobGames pages.
2. Compatibility. Use tech that's been around for a long time. Static HTML is best. JPG or GIF, not WebP etc. My older pages don't use Javascript but my newer pages do, and they do require occasional maintenance. I've also had to update things to make my pages work with mobile and HTTPS.
3. Dependencies. Don't link to external resources like fonts, scripts, images, etc. Everything should be on the same site, because you don't know that other sites will stick around.
4. Archivability. Test the pages on Internet Archive to make sure they work there. Most of mine do. A few of mine don't, and I'm working to fix that. I think once your domain name expires, it's the archives that will have the only copies, so you want to make sure your pages can be mirrored/archived.
In addition to the "30 years after the author passes away" problem, I also want to update my pages over time. For example, in August I updated a page that I had written in 1997. I try to minimize external build dependencies. The common build tools in use today are unlikely to still work long into the future. I have some of my own build scripts that I can keep working. For longevity I use "old" tech as much as possible (bash, python) and stay away from nicer newer languages and tools.
Thank you for creating redblob -- I've personally benefited from that resource, and TIL that you explicitly designed it for longevity (which makes sense in hindsight).
If “without any kind of maintenance” is the test, then no.
At a minimum you need to sign a contract with an organization and pre–pay for the term you expect them to maintain the site. And you probably need a third party to monitor that organization to ensure they’re meeting the terms of that contract. And pay them as well.
Systems fail. Systems get hacked. Organizations evolve, change, get bought, get shut down, or just die.
I bet someone, somewhere in Switzerland, is tasked with maintaining info.cern.ch and keeping the systems its on up to date and secure, even if the content is HTML 1.0 and the server is responding with HTTP/0.9. Same with the spacejam site.
Barring Internet Archive going into long term site hosting (and not just archiving content under web.archive.org, but archiving under the original host name) I don't think it's realistic to expect any site to stay up once the author/owner/originator stops maintaining it.
The oldest extant site I had anything to do with appears to be https://park.org/. My bit was the IBM Chess Challenge that seems to have evaporated. But you can see one problem with keeping a site up for 26 years. park.org is heavily imagemap dependent. Imagemaps used to be processed server side, and eventually flipped to be browser side, but required the map to be sent to the browser. No one has updated the park.org HTML to reflect this so the imagemap based navigation doesn't work.
And someone does appear to be doing some sort of maintenance because the links to the 1996 Chess Challenge site appear to have been removed whenever IBM lost interest in keeping that site up.
Some of the sibling answers focus on the data format -- e.g. plain HTML etc.
But I believe you're actually asking about durable institutions of people without realizing it:
>(i.e. a website that will stay up for 30 years after the author passes away)
Having a server stay up for 30 years is about hardware constantly staying on with electricity and ongoing maintenance (e.g. replace dying harddrives). This also means domain name registrations being renewed ... which is another people process. Many domains registrars only offer max 10-year limits. Some have 45-year terms but such long timelines kicks the question back to people because you have to trust the registrar to be still be around and not go bankrupt.
Consider your example of "http://info.cern.ch/" -- That's the CERN institution with people & money to maintain the computers to serve those old webpages.
To eliminate most of the "people problem"... you can re-frame the problem to be, "How to make the data between <HTML></HTML> as durable as possible without domain registrars and specific computers?"
This means looking at things like embedding the data into IPFS, Bitcoin blockchain, or have it copied by archive.is or The Wayback Machine. This converts your problem from a "institution issue" into more of a "crowdsourced viral data replication issue".
That's a great point about the domain registration.
So if you want to have a standalone website (not use IPFS, etc), then you are really looking at setting up an organization to perpetuate your website.
Such organizations, which exist past the lifetime of the founder, are self-perpetuating, and have missions, are well-known technology. They are called foundations.
Setting up a foundation to keep a website running feels like using a sledgehammer to kill a mosquito, but I suppose the long term value of a website does depend on the data it is conveying.
One of the things I love about the world is that for almost any random subject under the sun, you can find people who are deeply invested. The breadth of diversity of humanity is staggering.
So a 15-year-old coding a website about library cards so many years ago is wonderful, although not even close to the weirdest example :)
The best bet is to get a job with a university and get a home page there. They're the most likely to still be hosting that homepage in 30 years, and the most likely to do migrations to new hardware while keeping the home directories.
Any commercial provider has a risk of going out of business. If you must go with a commercial provider, AWS is probably your best bet, as they are the most likely to still be around in 30 years and still able to run whatever you've set up, since they almost never deprecate a product. And connect it with a credit card that can update it's expiration date automatically and hope to stay in the free tier.
And of course use web technologies that are already at least 10 years old so they have the highest likelihood of longevity in the standards.
Make a site that becomes more valuable the more hosted copies there are of it.
License it for others to copy and rehost forevermore.
“We keep that name moving in the Overhead,” he said, and it seemed to Princess that the wind in the shutter arrays above her blew more forlornly, and the everlasting clicking of the shutters grew more urgent. “He’d never have wanted to go home. He was a real linesman. His name is in the code, in the wind in the rigging and the shutters. Haven’t you ever heard the saying: ‘A man’s not dead while his name is still spoken’?”
If there was a way to fingerprint the site's data and have that fingerprint stored on a blockchain, then have some way to have a small amount paid each time the fingerprint's corresponding data is confirmed to be hosted somewhere. The hosted site has an address in its robots.txt to pay the funds into.
There are no promises but I think plain HTML 5 w/o Javascript or an interactive bacn end is likely to hold up well. (I'd be afraid of Google knocking over the chessboard though)
I'd think that storage in Amazon S3 and distribution via a CDN would be low maintenance but I'd think some discontinuity would be inevitable in 30 years. (The worst thing that happened in the last 30 years of the web was the transition from http to https, in another 10 years web browsers might quit supporting http entirely.)
The other question is how to pay for it, and the financial tool for this is a
and assumed expenses were $10 a month and the investment gets an 8% yearly growth rate and found I had to put in $1,371.92 for the money to last 30 years.
> (The worst thing that happened in the last 30 years of the web was the transition from http to https, in another 10 years web browsers might quit supporting http entirely.)
Enforcing HTTPS was one of the best things to happen to the web, when attacks by tools such as Firesheep and nation states doing dragnet surveillance was (is) rife.
Enforcing HTTPS is bad enough, but refusing to support plain HTTP for trivial sites is just arrogant and user hostile.
Say I don't care about the possibility of some of my magazine subscriptions being tampered with. Sure, put some kind of security in place for things that are delivering me important sensitive information — like official government information? I don't know. Forcing that down my throat for Fishing Weekly though, is just pointless. Oh, did hackers change the weight of that record fish? Oh no!
"But security!" is the new "Think of the children".
I didn't mean to make a moral judgement in "worst" except that it was the "worst" in terms of being some event that would require somebody to make changes. Those changes are certainly not covered in the $10 / month budget I'm suggesting.
When I build a project, I want it to be as low maintenance as possible. So that even if it never becomes a big commercial success, I can keep it running indefinitely.
The approach I took for my latest project is that I wrote a new static site generator in Python. I could have used Jekyll or something, but all static site generators I tried are much too complex for my liking.
Some of the characteristics of my generator are:
# File based
The content, templates and assets are stored as files on disk. No database is involved.
# Single script
Turning templates, content and assets into a website is not a complex thing. Basically it just means some templating of the content according to the templates. The python script I wrote for it is around 200 lines of code and offers me all the flexibility I need.
The html files it outputs stand a good chance to still function in 2053, just like info.cern.ch still functions today.
Will the Python script still function in 2053? Maybe not with the Python interpreters that ship with the OS, but it will probably still be possible to get a python 3 interpreter.
And it will probably not take more than a few hours to update it to Python 17 or whatever is the current version then.
The only truly effective way to keep something for a long time is to get people to care about it enough to make sure it remains available. To quote Linus Torvalds “Only wimps use tape backup. REAL men just upload their important stuff on ftp and let the rest of the world mirror it.”
Setup a trust or other organization with enough funding and a mandate to keep the site going.
Make sure there are backups of the site available in various archives and libraries where it could be accessed if the technology, or maintenance thereof, were to ever fail.
It's kind of like asking how you can build a server that will last 30 years without maintenance. There are a few examples of long-running servers around, but they've all had lots of parts replaced - but how about Voyager 1 and Voyager 2?
A well-shielded server on a spacecraft in a distant orbit (maybe around Mars) hooked up to the Deep Space Network, powered by satellite solar panels - that might be the ticket.
I honestly don’t believe the web as we know it today will exist in 30 years. The internet will, and browsers will, but we are headed toward a future of completely walled gardens and proprietary protocols. The web will probably live on as an “underground” thing akin to Tor today. But commercial use will probably cease.
If the web will go "underground", then i REALLY want to make use of simpler technology to avoid any crap that exists today (like, pinging out to privacy killers, etc.)...immediately i thought of the tactics that the folks use (relatively speaking of course) to broadcast their signals in the Matrix movies!
It is possible but there are some caveats. The example shows what is needed: conservative technology and conservative hosting. A website built with the simplest and oldest Web templating will be parseable by all browsers now and into the foreseeable future. Cloud hosting providers come and go but a dedicated IP directed to a bare metal server you own will remain online so long as the electric bill is paid. Given this you’ll want to write a rather sparse HTML page(s) with interactivity driven by hyperlinks, then find some stable institution like a university to give you a static IP and an electrical socket for your bare metal server.
It’s a bit of a lost art but still well in the realm of practicability.
Design the website. Really be sure you've got it right. It's going to be very painful to get it wrong.
Burn the website into an ASIC. The ASIC should have multiple, redundant communications channels (starlink, cat5, etc). Sign a contract with a 30 year period with an existing, well regarded, US-based registar. Make sure it is fully lawyered.
Power the thing with the geomatic waves of the earth like they do in Alert, Canada. May require some effort to bring the power close enough to the coms.
Build a large anti-ICBM and anti-Asteroid system to ward off planetary threats.
Edit: Or burn it as a QR code into the moon with lasers.
When you're done that, you're doing pretty good. But watch out for sharknados.
I didn’t see this mentioned but I think something critically important is the domain itself. How to guarantee 30 years of domain control? I think the longest Go Daddy will let you register your domain is maybe 10 years.
Either way, you would need to make sure the domain is tied to a payment process that will continue to renew it.
There is also ICANN verification updates that someone has to go in and verify.
That means contact information has to be up-to-date, and you don’t get hit with a UDRP violation.
Therefore I suppose the result is to first set up a trust that will last for 30 years to pay an outside lender to make sure that the domain is always up-to-date and pointed in the right direction.
You can't permanently buy a domain name. Most registrars only let you register one for up to 10 years. Web hosting wouldn't even last that long.
HTML itself will fair well, it's human readable and trivial to parse.
Your best bet is you or the content being important enough for other people to take care of it for you, copying and sharing it, converting it to their media. Of course cultures change, and by 2050 the planet will be barely habitable, so they will change a lot. A culture that decides to preserve your website might get wiped out, or the infrastructure does. There might not be even an internet anymore.
You can request IPv6 addresses from a RIR, but that won't last forever either, and nobody will visit your site, not even the search engines. People wouldn't be even able to open it for long, since most browsers are going to require SSL, and who knows what other changes are coming in the future that require a domain name.
As many others have said, static html and css are your best bet for having your site continue to function.
As for having it continue to be hosted, I suggest IPFS. https://docs.ipfs.tech/how-to/websites-on-ipfs/single-page-w...
So long as your site continues to be interesting, people can continue to pin replicas of your site. The domain will lokely lapse without maintenance, but the content will still be out there.
Is it possible to pay for domain and hosting for 30 years ahead? Is it possible to set some script which will auto-update the https theatre of security? What about security updates of everything?
It's hard to form a good expectation on the liklihood of success, but the Arweave [1] project is trying to create a permaweb system built on top of a "Proof-of-Storage" cryptocurrency where you pay once and have permanent storage. I think something like this will eventually succeed. It's worth reading their whitepaper to decide for yourself if it is feasible.
Your best bet would be to piggy-back on something else that is maintained, because someone needs to handle domain registration and hosting and all that stuff.
It is hard to ensure that a website would survive for 30 years without requiring maintenance. There are too many components involved in running a website and I think it is quite likely that at least one of them would break if no maintenance is done. I think a breakage is especially more likely if it is a personal website. For example, the domain name may expire, the server hosting the website may go down due to a hardware malfunction in your own server or a payment failure for your server provider, TLS certificates (if any) may fail to renew due to a breaking change in a certificate management tool, etc.
But I think it is possible for the HTML pages of a website to survive. If this can be done, then the website can survive in its original form even when it may not be available in its original domain name.
Here are some things I have done to increase the odds that my personal website would survive for several decades even if the primary website disappears some day:
- The entire website is a collection of static HTML pages.
- All internal links and path references, are relative. In fact, the paths to CSS files, images, videos, audios, etc. are also relative.
- The HTML pages do not loaded any resource from another domain.
- Since I use MathJax on my website to render mathematical content, MathJax is bundled within the website. Further, MathJax is loaded into the pages that need it using relative links only. (This is an example of the previous two points.)
- Stick to text as much as possible. Most pages are just text marked up with HTML. Use images, videos, audios, etc. only when absolutely necessary. Similarly, load MathJax using a relative link only on those pages that have mathematical content.
- Test that if the website is copied to a directory on the local filesystem, one can still navigate the website locally using a web browser. This is possible due to using relative links/paths (instead of absolute ones).
- While the primary copy of the website is hosted at a personal domain name I have registered, I publish a mirror copy on my GitHub account via GitHub pages. Should the primary domain name disappear someday (which did happen once for a few days due to a sinkhole incident), the mirror would still be available via GitHub pages as long as GitHub continues to maintain their service.
Finally, and I don't do this, but one could consider http://web.archive.org/ as well as IPFS to archive the pages of one's website to ensure that tertiary copies of the website also remain on the web.
Well there is Github Pages, where you could host a static site, although I'm not so sure it will still be around in 30 years time. Then there's the 10 year ICANN domain renewal limit, which means you have to 'be there' in two other 10 year intervals to renew the domain.
At least in theory you can put an insulated web server in the forest with a battery large enough to last 30 years (assuming the server goes to sleep when unused). But how would you ensure it stays connected to the internet and is reachable through a known ip address?
...Well, of course, you'd need an insulated starlink (and a clear view of the sky) in the forest with a battery large enough to last 30 years...ah, nevermind. :-)
Use only static content and a webserver you don't have to configure (no htaccess files, no nginx try_files etc.). Do not use special file formats like webp, but old standards like jpg or png. Do not use Javascript.
Websites aren't articles in a newspaper you can cut out, nor artworks you can hang on your wall, even if they contain only text and/or some images.
Websites are shopping windows. Think about what would be required to keep the same shopping window alive for 30 years. It's exactly the same with the web.
Can someone actually describe what you would have to do? Literally nobody here gave any practical advice like, “you’re going to have to self-sign your certificates” or whatever. If you did this on prem obviously there’s a lot of networking techniques that you must use to just set up a bare bones server without updating dependencies.
1. Hosting. I was lucky in that Stanford gave me a place to put pages. I think it was more common back then for universities to do this. Now I have a domain name which I register for 10 years at a time. But that's not going to last 30 years after I pass away. And even if I had the domain name, my server (currently AWS) won't stay up if I don't pay the monthly bills. My Stanford pages will stay up longer than my RedBlobGames pages.
2. Compatibility. Use tech that's been around for a long time. Static HTML is best. JPG or GIF, not WebP etc. My older pages don't use Javascript but my newer pages do, and they do require occasional maintenance. I've also had to update things to make my pages work with mobile and HTTPS.
3. Dependencies. Don't link to external resources like fonts, scripts, images, etc. Everything should be on the same site, because you don't know that other sites will stick around.
4. Archivability. Test the pages on Internet Archive to make sure they work there. Most of mine do. A few of mine don't, and I'm working to fix that. I think once your domain name expires, it's the archives that will have the only copies, so you want to make sure your pages can be mirrored/archived.
In addition to the "30 years after the author passes away" problem, I also want to update my pages over time. For example, in August I updated a page that I had written in 1997. I try to minimize external build dependencies. The common build tools in use today are unlikely to still work long into the future. I have some of my own build scripts that I can keep working. For longevity I use "old" tech as much as possible (bash, python) and stay away from nicer newer languages and tools.
[1] http://www-cs-students.stanford.edu/~amitp/ [2] https://www.redblobgames.com/making-of/little-things/#site