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].<p>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.<p>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.<p>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.<p>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.<p>In addition to the "30 years after the author passes away" problem, I also want to <i>update</i> 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.<p>[1] <a href="http://www-cs-students.stanford.edu/~amitp/" rel="nofollow">http://www-cs-students.stanford.edu/~amitp/</a>
[2] <a href="https://www.redblobgames.com/making-of/little-things/#site" rel="nofollow">https://www.redblobgames.com/making-of/little-things/#site</a>
No.<p>If “without any kind of maintenance” is the test, then no.<p>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.<p>Systems fail. Systems get hacked. Organizations evolve, change, get bought, get shut down, or just die.<p>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.<p>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.
Some of the sibling answers focus on the <i>data format</i> -- e.g. plain HTML etc.<p>But I believe you're actually asking about <i>durable institutions of people</i> without realizing it:<p><i>>(i.e. a website that will stay up for 30 years after the author passes away)</i><p>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 <i>renewed</i> ... which is another <i>people process</i>. Many domains registrars only offer max 10-year limits. Some have 45-year terms but such long timelines kicks the question back to <i>people</i> because you have to trust the registrar to be still be around and not go bankrupt.<p>Consider your example of "<a href="http://info.cern.ch/" rel="nofollow">http://info.cern.ch/</a>" -- That's the <i>CERN institution with people & money</i> to maintain the computers to serve those old webpages.<p>To eliminate most of the "people problem"... you can re-frame the problem to be, <i>"How to make the data between <HTML></HTML> as durable as possible without domain registrars and specific computers?"</i><p>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".
Sure, write plain old html. There are still tripod sites up (like this one: <a href="https://librarycards.tripod.com/" rel="nofollow">https://librarycards.tripod.com/</a> ).<p>Prepay for hosting, preferably with a bigco that won't go out of business or pivot.
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.<p>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.<p>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.<p>License it for others to copy and rehost forevermore.<p>“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’?”<p>— Going Postal, Terry Pratchett
I think the only way to get that would be plain HTML with all CSS embedded directly into the page, which you then get hosted by the Internet Archive.<p>In terms of working in future browsers you probably use pretty much any spec-compliant CSS. They pretty much never remove anything.
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)<p>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.)<p>The other question is how to pay for it, and the financial tool for this is a<p><a href="https://en.wikipedia.org/wiki/Annuity" rel="nofollow">https://en.wikipedia.org/wiki/Annuity</a><p>You need to invest some quantity of money and then spend some fraction of it every year. I used<p><a href="https://www.bankrate.com/investing/annuity-calculator/" rel="nofollow">https://www.bankrate.com/investing/annuity-calculator/</a><p>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.
I think about this a lot.<p>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.<p>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.<p>Some of the characteristics of my generator are:<p># File based<p>The content, templates and assets are stored as files on disk. No database is involved.<p># Single script<p>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.<p>The html files it outputs stand a good chance to still function in 2053, just like info.cern.ch still functions today.<p>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.<p>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.”
Live for 30 years and keep updating it.<p>Setup a trust or other organization with enough funding and a mandate to keep the site going.<p>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?<p>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.
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.<p>It’s a bit of a lost art but still well in the realm of practicability.
I will actually answer the question.<p>Design the website. Really be sure you've got it right. It's going to be very painful to get it wrong.<p>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.<p>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.<p>Build a large anti-ICBM and anti-Asteroid system to ward off planetary threats.<p>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.<p>Either way, you would need to make sure the domain is tied to a payment process that will continue to renew it.<p>There is also ICANN verification updates that someone has to go in and verify.<p>That means contact information has to be up-to-date, and you don’t get hit with a UDRP violation.<p>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.<p>HTML itself will fair well, it's human readable and trivial to parse.<p>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.
As many others have said, static html and css are your best bet for having your site continue to function.<p>As for having it continue to be hosted, I suggest IPFS. <a href="https://docs.ipfs.tech/how-to/websites-on-ipfs/single-page-website/#set-up-a-domain" rel="nofollow">https://docs.ipfs.tech/how-to/websites-on-ipfs/single-page-w...</a>
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.
Write plain HTML, nothing else.<p>However, you still need to ensure the domain and hosting provider are paid to deliver their services.<p>Even if you add a credit card and enable auto-renew, the credit card will expire long before 30 years are over.
It would be to take the example of the sites that have achieved it or are in the process of doing so.<p><a href="https://www.craigslist.org/" rel="nofollow">https://www.craigslist.org/</a><p><a href="https://www.spacejam.com/1996/" rel="nofollow">https://www.spacejam.com/1996/</a><p>There is a principle of internet standards called 'don't break the web' which may be useful to you.<p><a href="https://danburzo.ro/dont-break-the-web/" rel="nofollow">https://danburzo.ro/dont-break-the-web/</a>
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.<p>[1] <a href="https://arwiki.wiki/#/en/main" rel="nofollow">https://arwiki.wiki/#/en/main</a>
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.<p>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.<p>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:<p>- The entire website is a collection of static HTML pages.<p>- All internal links and path references, are relative. In fact, the paths to CSS files, images, videos, audios, etc. are also relative.<p>- The HTML pages do not loaded any resource from another domain.<p>- 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.)<p>- 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.<p>- 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).<p>- 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.<p>Finally, and I don't do this, but one could consider <a href="http://web.archive.org/" rel="nofollow">http://web.archive.org/</a> 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.
No-ones mentioned blockchain yet, but now there's so many blockchains that even if the site was around in 30 years no-one would be able to find it.
30 years is a very long time on the Internet. Your best bet is probably to utilize the Internet Archive in one form or another.<p>And all the other comments about plain html and nothing new or fancy.<p><a href="https://archive.org/developers/index.html#warc-web-archive" rel="nofollow">https://archive.org/developers/index.html#warc-web-archive</a>
Zero maintenance is an impossibility. What happens when hosting provider goes bankrupt?<p>However, there is a way to make minimal maintenance websites.<p>Make a static website and upload it to a provider that you believe won’t go away for at least 30 years.<p>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.
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.
Here is an idea. Set up a VM with 86box for NeXTSTEP. Install omniweb or spiderwoman. Write HTML that displays correctly in those browsers.<p>That's how I wrote this<p><a href="https://navjackknows.neocities.org/index.html" rel="nofollow">https://navjackknows.neocities.org/index.html</a>
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?
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.
Plain vanilla html on something that has already been around for over 30 years?<p><a href="https://sdf.org/" rel="nofollow">https://sdf.org/</a>
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.<p>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.