A Library That Fits on a USB Stick

Imagine a school with a computer lab and no internet. The machines work. The students are curious. But every time a question comes up, like how vaccines work, why rivers flood or who drew the first map of the world, the answer is one click away on a network that isn't there.

Now imagine a teacher walks in with a USB stick. They plug it into each computer, and a few minutes later every student can open thousands of Wikipedia articles, search them and follow the links between them. No connection, no data bill, no waiting.

That isn't science fiction. It already happens, thanks to an open-source project called Kiwix, which reads Wikipedia from a single file on a phone, a laptop or a small box that acts as a local hotspot. I spent the end of October building OfflineShelf, a tool for one small step in that story: deciding what goes on the stick.

---

#The suitcase problem

The whole of English Wikipedia, with pictures, is a download of roughly a hundred gigabytes. That's more than most old phones and cheap laptops can hold, and much more than a school needs. A nursing course doesn't need every football season since 1888. A geography class doesn't need every pop single.

So someone has to choose, the way you choose what goes into a suitcase. You can't take the whole wardrobe, so you pack for the trip you're actually taking.

Choosing well is harder than it sounds. Wikipedia has millions of articles in English alone. Nobody is going to pick a few thousand of them by hand, one by one, and then do it all again next year.

#Four ways to pack

OfflineShelf gives you four ways to describe what you want, because people think about lists in different ways.

By topic. Wikipedia already sorts its articles into categories, like "Vaccines" or "Rivers of Pakistan", and categories hold smaller categories inside them. You pick a category and how deep to go, the way you might say "the whole biology shelf, including the smaller sections inside it".

By facts. Wikipedia has a sister project called Wikidata, which stores facts in a form a computer can search: this is a university, it's in Pakistan, it was founded in this year. You can ask it a precise question, like every university in Pakistan, and OfflineShelf turns each answer into the matching article.

By a list you already have. A teacher's reading list, a syllabus, a list from a ministry. You paste it in, and OfflineShelf finds each article, follows old names to their current pages, and tells you which ones it couldn't find instead of quietly skipping them.

By what people actually read. The most-read articles of a given month. It's a surprisingly good starting point for a general library, because it reflects what people really look things up.

#Lists that add and subtract

Real requests are rarely one simple topic. A clinic might want everything about vaccines, but not the articles about the companies that make them. A science teacher might want physics and chemistry together.

So lists can be combined, the way you might have drawn overlapping circles in a maths class. Everything in either list. Only what's in both. Everything in the first one, minus anything in the second. "Vaccines minus Companies" is a real list you can make.

#Wikipedia doesn't stand still

Here's the part I didn't fully appreciate until I started building. Wikipedia is edited all the time. Articles are merged, renamed, split in two, deleted, and new ones appear every day. A list that was right in March can be quietly different by June.

So OfflineShelf can rebuild a list every month, and each time it keeps a note of exactly what changed: these articles are new, these ones are gone. If you're the person preparing the USB stick, that note is what tells you whether it's worth updating.

There's one more promise behind that. If a rebuild goes wrong, because Wikipedia's servers were busy or a category was renamed halfway through, the old list stays exactly as it was. It's like not throwing away last year's textbook until the new one has actually arrived.

Also readThe Discount That Knew You Were Hesitating: Rule-Based Personalisation in an Online Pharmacy
One Seat, Two Buyers: Race Conditions, IDOR and Keys in a Cinema Booking System

#Carrying it out of the room

A list on a website doesn't help a classroom. It has to leave the browser in a form that works offline, so there are three ways out:

• A spreadsheet file, a simple list of titles that opens anywhere and works with other tools, including the ones the Kiwix project uses itself.
• A folder of web pages, zipped. Unzip it onto a USB stick, open the first page, and every article on the list opens in any web browser, with links between them that work offline.
• A single file for Kiwix, the format the Kiwix apps read, with search built in.

I want to be honest about one limit. For now, the offline copies carry the text but not the pictures. Pictures are linked rather than copied, so they appear when a device happens to be online and are missing when it isn't. Adding them, while keeping the files small enough to be useful, is one of the first things on the list after launch.

#Saying thank you properly

Every Wikipedia article was written by volunteers. Their work is shared under a licence called CC BY-SA, which in plain words says: you can copy this, change it and share it, as long as you say who made it and let others share your version the same way.

That's a generous deal, and it's easy to break by accident. An offline copy that strips out the credits is exactly that. So every page OfflineShelf exports ends with where it came from: the article, the exact version of it, the licence and a link to everyone who edited it. Every bundle has a page that explains this, and the spreadsheet file carries it in its first lines.

#Being a polite visitor

Wikipedia is run by a non-profit and paid for by donations. Its servers have rules for tools like mine, and the most important one is simple: don't be greedy.

OfflineShelf introduces itself by name, with a way to contact me, every time it asks Wikipedia for something. And it asks Wikipedia to tell it when the servers are under strain. When they are, it waits and tries again later. I watched that happen once while testing: Wikidata was busy, OfflineShelf stepped back, and a few minutes later the list built as if nothing had happened.

It's a small thing. But a tool that hammers a volunteer-funded website gets blocked, and then it stops working for every school that relies on it.

---

#What it taught me

Three ideas stayed with me after building this, and they apply far beyond Wikipedia.

Choosing is the real work. Copying information is cheap now. Deciding which information matters for a particular group of people, and being able to explain and repeat that decision, is where the value is.

Keep the old version until the new one is proven. Whether it's a reading list, a price list or a timetable, a half-finished update is worse than no update at all.

Give credit as part of the product, not as a footnote. If something is built on other people's work, the credit should travel with it automatically, so nobody has to remember to add it.

OfflineShelf is open source, and the public version goes live in February 2027, after a round of testing with many simulated users at once. If you work with a school, a library or a clinic that could use it, I'd genuinely like to hear what your list would look like.

The full build, with the architecture, the tests and the mistakes I made along the way, is in the OfflineShelf case study.