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
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.
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.
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".
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.
Prepay for hosting, preferably with a bigco that won't go out of business or pivot.
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 :)
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.
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’?”
— Going Postal, Terry Pratchett
In terms of working in future browsers you probably use pretty much any spec-compliant CSS. They pretty much never remove anything.
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
https://en.wikipedia.org/wiki/Annuity
You need to invest some quantity of money and then spend some fraction of it every year. I used
https://www.bankrate.com/investing/annuity-calculator/
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.
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".
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.
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.
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.
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.
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.
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.
Websites don't require a domain name.
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.
However, you still need to ensure the domain and hosting provider are paid to deliver their services.
Even if you add a credit card and enable auto-renew, the credit card will expire long before 30 years are over.
https://www.spacejam.com/1996/
There is a principle of internet standards called 'don't break the web' which may be useful to you.
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.
And all the other comments about plain html and nothing new or fancy.
However, there is a way to make minimal maintenance websites.
Make a static website and upload it to a provider that you believe won’t go away for at least 30 years.
Checkout Astro.js for this purpose, you can then upload it to any CDN. I prefer to use bunnycdn due to costs but there are other providers too.
That's how I wrote this
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.