Signed!
We, the undersigned, call on the record labels and members of the Recording Industry Association of America (RIAA)—including UMG, Capitol Records, Concord Bicycle Assets, CMGI Recorded Music Assets, Sony Music Entertainment, and Arista Music—to drop your lawsuit against the Internet Archive.
Practice Progressive Enhancement.
Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.
All content should be readable without scripting.
If it’s worth building on the web, it’s worth building it robustly, and building it to last.
The web is open, apps are closed. The majority of web users have installed an ad blocker (which is also a privacy blocker). But no one installs an ad blocker for an app, because it’s a felony to distribute that tool, because you have to reverse-engineer the app to make it. An app is just a website wrapped in enough IP so that the company that made it can send you to prison if you dare to modify it so that it serves your interests rather than theirs.
About halfway through this talk transcript, Aaron starts dropping a barrage of truth bombs:
I understand the web, whose distinguishing characteristic is asynchronous recall on a global scale, as the technology which makes revisiting possible in a way that has genuinely never existed before the web.
What the web has made possible are the economics of keeping something, something which has not enjoyed “hockey stick growth”, around long enough for people to warm up to it. Or to survive long past the moment when people may have grown tired of it.
If your goal is to build something which is designed to flip inside of ten years, like many things in the private sector, that may not seem like a very compelling argument.
If, however, your goal is to build something to match the longevity of the cultural heritage sector, to meet the goal of fostering revisiting, or for novel ideas to outlast the reluctance of the present and to do so at a global scale, or really any scale larger than shouting distance, then I will challenge you to find a better vehicle for doing so than the internet, and the web in particular.
AI has the same problem that I saw ten year ago at IBM. And remember that IBM has been at this AI game for a very long time. Much longer than OpenAI or any of the new kids on the block. All of the shit we’re seeing today? Anyone who worked on or near Watson saw or experienced the same problems long ago.
This magnificent piece by Maxwell Neely-Cohen—with some tasteful art-direction—is right up my alley!
This piece looks at a single question. If you, right now, had the goal of digitally storing something for 100 years, how should you even begin to think about making that happen? How should the bits in your stewardship be stored with such a target in mind? How do our methods and platforms look when considered under the harsh unknowns of a century? There are plenty of worthy related subjects and discourses that this piece does not touch at all. This is not a piece about the sheer volume of data we are creating each day, and how we might store all of it. Nor is it a piece about the extremely tough curatorial process of deciding what is and isn’t worth preserving and storing. It is about longevity, about the potential methods of preserving what we make for future generations, about how we make bits endure. If you had to store something for 100 years, how would you do it? That’s it.
Speaking of serendipity, not long after I wrote about making a static archive of The Session for people to download and share, I came across a piece by Alex Chan about using static websites for tiny archives.
The use-case is slightly different—this is about personal archives, like paperwork, screenshots, and bookmarks. But we both came up with the same process:
I’m deliberately going low-scale, low-tech. There’s no web server, no build system, no dependencies, and no JavaScript frameworks.
And we share the same hope:
Because this system has no moving parts, and it’s just files on a disk, I hope it will last a long time.
You should read the whole thing, where Alex describes all the other approaches they took before settling on plain ol’ HTML files in a folder:
HTML is low maintenance, it’s flexible, and it’s not going anywhere. It’s the foundation of the entire web, and pretty much every modern computer has a web browser that can render HTML pages. These files will be usable for a very long time – probably decades, if not more.
I’m enjoying this approach, so I’m going to keep using it. What I particularly like is that the maintenance burden has been essentially zero – once I set up the initial site structure, I haven’t had to do anything to keep it working.
They also talk about digital preservation:
I’d love to see static websites get more use as a preservation tool.
I concur! And it’s particularly interesting for Alex to be making this observation in the context of working with the Flickr foundation. That’s where they’re experimenting with the concept of a data lifeboat
What should we do when a digital service sinks?
This is something that George spoke about at the final dConstruct in 2022. You can listen to the talk on the dConstruct archive.
When I went up to London for the State of the Browser conference last month, I shared the train journey with Remy.
I always like getting together with Remy. We usually end up discussing sci-fi books we’re reading, commiserating with one another about conference-organising, discussing the minutiae of browser APIs, or talking about the big-picture vision of the World Wide Web.
On this train ride we ended up talking about the march of time and how death comes for us all …and our websites.
Take The Session, for example. It’s been running for two and a half decades in one form or another. I plan to keep it running for many more decades to come. But I’m the weak link in that plan.
If I get hit by a bus tomorrow, The Session will keep running. The hosting is paid up for a while. The domain name is registered for as long as possible. But inevitably things will need to be updated. Even if no new features get added to the site, someone’s got to install updates to keep the underlying software safe and secure.
Remy and I discussed the long-term prospects for widening out the admin work to more people. But we also discussed smaller steps I could take in the meantime.
Like, there’s the actual content of the website. Now, I currently share exports from the database every week in JSON, CSV, and SQLite. That’s good. But you need to be tech nerd to do anything useful with that data.
The more I talked about it with Remy, the more I realised that HTML would be the most useful format for the most people.
There’s a cute acronym in the world of digital preservation: LOCKSS. Lots Of Copies Keep Stuff Safe. If there were multiple copies of The Session’s content out there in the world, then I’d have a nice little insurance policy against some future catastrophe befalling the live site.
With the seed of the idea planted in my head, I waited until I had some time to dive in and see if this was doable.
Fortunately I had plenty of opportunity to do just that on some other train rides. When I was in Spain and France recently, I spent hours and hours on trains. For some reason, I find train journeys very conducive to coding, especially if you don’t need an internet connection.
By the time I was back home, the code was done. Here’s the result:
The Session archive: a static copy of the content on thesession.org.
If you want to grab a copy for yourself, go ahead and download this .zip file. Be warned that it’s quite large! The .zip file is over two gigabytes in size and the unzipped collection of web pages is almost ten gigabytes. I plan to update the content every week or so.
I’ve put a copy up on Netlify and I’m serving it from the subdomain archive.thesession.org if you want to check out the results without downloading the whole thing.
Because this is a collection of static files, there’s no search. But you can use your browser’s “Find in Page” feature to search within the (very long) index pages of each section of the site.
You don’t need to a web server to click around between the pages: they should all work straight from your file system. Double-clicking any HTML file should give a starting point.
I wanted to reduce the dependencies on each page to as close to zero as I could. All the CSS is embedded in the the page. Likewise with most of the JavaScript (you’ll still need an internet connection to get audio playback and dynamic maps). This keeps the individual pages nice and self-contained. That means they can be shared around (as an email attachment, for example).
I’ve shared this project with the community on The Session and people are into it. If nothing else, it could be handy to have an offline copy of the site’s content on your hard drive for those situations when you can’t access the site itself.
What are your own scribbles, your own ordinary plenty, not worth much to you now but that someone in the future may treasure?
For many archivists, alarm bells are ringing. Across the world, they are scraping up defunct websites or at-risk data collections to save as much of our digital lives as possible. Others are working on ways to store that data in formats that will last hundreds, perhaps even thousands, of years.
I like this framing:
If you’ve ever corrected a typo in an Open Source readme, or added alt-text to an image, or tidied up some broken references in Wikipedia - you’re doing Digital Litter Picking. You’re cleaning up after others. And I think that’s a marvellous way to spend a little time.
When I write a blog post, I want it to live on my blog, rather than a platform. I can thus invest my time thinking about how to make my blog better and backing it up, rather than having to worry about where my writing is, finding ways to export data from a platform, setting up persistent backups, etc.
It would be much harder for a 15-year-old today to View Source and understand the code structure that built the website they’re on. Every site is layered with analytics, code snippets, javascript plugins, CMS data, and more.
This is why the simplicity of HTML and CSS now feels like a radical act. To build a website with just these tools is a small protest against platform capitalism: a way to assert sustainability, independence, longevity.
Owning your own piece of the Internet (to borrow a recent phrase from Anil Dash) is itself a radical act. Linking to others at will is subversive all on its own. Or as Jeremy Keith once put it, “it sounds positively disruptive to even suggest that you should have your own website.” The web still exists for everyone. And beneath this increasingly desiccated surface, there is plenty of creators still simply creating.
People create these sites simply so that they exist. They are not fed to an algorithm, or informed by any trends. It is quieter and slower, meant to tether us to a more mechanical framework of the web.
This is the analog web.
One of the reasons to own your content is to make it last. When you have control of the text you write or the photos you post, it’s up to you whether that content stays on the internet. When you post to someone else’s platform, you’ve given up that control. It’s not up to you whether the company that hosts your content will stay in business or change everything to break your content.
The Session does very well in terms of performance. You can see the data from the Chrome UX Report (CRUX).
What’s good for performance is good for the environment. Sure enough, The Session gets a very high score from the website carbon calculator:
Hurrah! This web page achieves a carbon rating of A+
This is cleaner than 99% of all web pages globally
But under the details about hosting it says:
Oh no, it looks like this web page uses bog standard energy
The Session is hosted on DigitalOcean, who tend to be quite tight-lipped about their energy suppliers. Fortunately others have done some sleuthing to figure out which facilities are running on green energy.
One of the locations to get the green thumnbs up is the Amsterdam facility housed by Equinix. That’s where The Session is hosted.
I’m glad that I was able to find out that the site is running on 100% renewable energy, but I wish I didn’t need to go searching to find this out. DigitalOcean need to be a lot more transparent about the energy sources for their hosting facilities.
Here’s the inside scoop on why Github is making a bizarre move from working web components to a legacy React stack.
Most of what I heard in favor of React was a) it’s got a good DX, b) it’s easy to hire for, and c) we only want to use it for a couple of features, not the entire website.
It’s all depressingly familiar, but it’s very weird to come across this kind of outdated thinking in 2023.
My personal prediction is that, eventually, the company (and many other companies) will realize how bad React is for most things, and abandon it. I guess we’ll see.
Five lovely monospaced variable fonts.
I love this timeline of internet firsts. Best of all:
You may touch the artifacts
The websites on display work—even the ones that used Flash!
If you, like me, feel that view transitions—especially on multi-page apps—would be a good thing for browsers to prioritise for interoperability, give this issue a thumbs-up.