October 2026

There were 49 posts published in October 2026 (this is page 3 of 5).

What If We Could BookCross the Internet?

I stumbled upon a website the other day that I hadn’t thought about in years: Bookcrossing (https://www.bookcrossing.com/). Remember BookCrossing? The idea is wonderfully simple. You take a book you’ve finished reading, register it on the website, and leave it somewhere for a complete stranger to find. That might be a park bench, a café, a train station, or wherever you think someone might come across it. Inside the book is a unique identification number. If the person who finds it visits BookCrossing and enters that number, they can leave a message. Perhaps they’ll tell you where they found it, whether they enjoyed reading it, or where they plan to leave it next. And so the book continues its journey.

I remember the idea from years ago. But I had absolutely no idea that BookCrossing was still around. It turns out that it is. Very much so.

More than twenty years of books travelling around the world

BookCrossing started in 2001, which means it has been around for a quarter of a century. Just think about that for a moment. Facebook didn’t exist. Twitter didn’t exist. YouTube didn’t exist. Smartphones, at least as we know them today, were still years away. Yet people were already using the internet to connect complete strangers through something as ordinary as a paperback. And they’re still doing it.

BookCrossing has attracted more than a million registered members over the years, and books are still being released into the wild. There are dedicated BookCrossing locations, local meetups, online discussions, and people who have been participating for decades. Of course, that doesn’t necessarily mean BookCrossing is experiencing some huge revival. It may simply be a community that never really went away.

I actually like that possibility even more. Not everything on the internet needs to grow exponentially. Sometimes, an idea is simply good enough to keep people interested for twenty-five years.

There’s something wonderful about not knowing what happens next

The part of BookCrossing that appeals to me most isn’t necessarily the book itself. It’s the uncertainty. You leave a book somewhere, and that’s it. You have no idea who might find it. Perhaps a student picks it up on the way to university. Perhaps a tourist takes it home to another country. Perhaps it ends up on a bookshelf for ten years before someone decides to release it again. Or perhaps nobody ever registers it. That’s fine too.

For me, the interesting thing is that you’ve put something into the world without knowing who will receive it or what they’ll do with it. No followers. No likes. No algorithm carefully selecting an audience for you. Just a book and a stranger. And, with a little luck, a story that continues.

Then there’s Postcrossing

While looking into BookCrossing, I came across another project that follows a remarkably similar idea: Postcrossing (https://www.postcrossing.com/). This one started in 2005 and revolves around postcards. You sign up, request an address, and send a real postcard to a randomly selected participant somewhere in the world. When your postcard arrives and gets registered, you become eligible to receive a postcard from another random participant. It’s such a simple concept. And yet millions upon millions of postcards have travelled around the world because of it.

What fascinates me is that the internet is only part of the process. The website helps people find each other, keeps track of the postcards, and makes the whole thing possible. But the actual experience happens away from the screen. Someone chooses a postcard, writes a few words, attaches a stamp, and drops it into a mailbox. Days or weeks later, somebody else discovers it among their regular mail. I can easily imagine the pleasure of opening your mailbox and finding a postcard from a stranger in Japan, Brazil, or Finland. Not because you bought something. Not because somebody wants to sell you something. Just because another person somewhere in the world decided to send you a postcard.

People are doing similar things digitally

Naturally, I started wondering whether people had come up with digital versions of these ideas. And of course they have. Take Bottled (https://www.bottledapp.com/), for example. It’s essentially a digital version of putting a message in a bottle and throwing it into the sea. You write a message, place it in a virtual bottle, and send it on its way. A random stranger receives it and can decide whether to keep it and start a conversation or let it continue its journey.

Then there’s Slowly (https://slowly.app/), an app that brings back the idea of pen pals. You write digital letters to people around the world, but there’s a twist: delivery takes time. The farther away the recipient lives, the longer your letter takes to arrive. Which is slightly ridiculous when you think about it. We’re deliberately slowing down technology that could deliver a message in milliseconds. But that’s exactly the point. Not every digital interaction needs to happen instantly. Sometimes waiting is part of the fun.

These projects aren’t identical to BookCrossing or Postcrossing, of course. They have their own rules and communities. But there’s a common thread. They use technology to introduce a little unpredictability into our lives. To connect people who otherwise wouldn’t have met. To make receiving something from a stranger feel like a small event.

And that got me thinking.

What if we did this with digital content?

Here’s an idea I can’t seem to get out of my head. Why couldn’t we do something similar with blog posts? Or essays, short stories, photographs, little digital magazines, or whatever else people create and publish online?

Imagine writing a blog post and registering it with something we might call DigitalCrossing. You publish your article on your own website, just as you normally would. The content stays there. Nothing needs to be uploaded to another platform. But you also give that article a unique identification number and release it into the digital wild. Somewhere in the world, another participating blogger or reader receives a link to your article. Not because they follow you. Not because an algorithm has decided your interests are similar. And certainly not because you’ve paid to reach them. They receive it simply because someone has released it into the wild.

Perhaps they read it. Perhaps they leave a comment. Perhaps they discover that they really like your writing and decide to explore the rest of your website. And then they have a choice. They can keep the link, ignore it, or pass it along to another randomly selected participant. Just like a BookCrossing book.

Imagine following the journey of your blog post

This is where it gets really interesting. Suppose I publish an article here on Just Me about one of my experiments with Linux or some obscure corner of the internet. I register the post with DigitalCrossing and release it. The first person to receive it lives in Finland. They read it, leave a short message, and pass it along. Next, it arrives in Brazil. The Brazilian reader happens to know somebody in Japan who might enjoy the article, so they send it there. That person forwards it to someone in Canada. And suddenly, my little blog post has travelled around the world.

I could visit a page showing its journey. Not a dashboard full of impressions, engagement rates, conversion funnels, and all the other stuff that seems to dominate the modern internet. Just a simple record of where my article has been and, if people choose to leave them, a few comments from the people who encountered it.

Of course, it wouldn’t really be tracking every visit. It would record the people who voluntarily acknowledge receiving and passing along the article. That’s perfectly fine. BookCrossing doesn’t know about every person who picks up a book either. The gaps are part of the story.

This could actually be quite simple

The more I think about it, the less complicated it seems. You’d need a website where people can register their own content, a way to assign unique IDs, a mechanism for randomly passing links between participating users, and a simple page showing where each item has travelled. That’s basically it.

And there’s no reason it would have to become another giant social platform. In fact, I’d prefer it didn’t. The whole thing could be built around RSS, links, and perhaps Webmentions to allow participating websites to communicate with each other. You wouldn’t need to copy anyone’s content or store everybody’s articles in one central database. The original piece would remain on its creator’s website. And perhaps individual bloggers could run their own little DigitalCrossing nodes, connected to others.

It would take some work to build something reliable and prevent spam and abuse, obviously. People would also need control over what they receive and whether their participation is visible. But the basic concept doesn’t seem particularly difficult to implement. Especially now that AI-assisted coding makes it easier for people like me to experiment with software ideas without having to become professional developers first. And experimenting with ideas like this is something I enjoy doing anyway.

Not another recommendation engine

There’s one thing I would absolutely want to avoid. I wouldn’t want DigitalCrossing to become a recommendation engine. We already have plenty of those. You read about Linux? Here’s more Linux. You like photography? Here’s another photography blog. You follow someone who writes about retro computers? Here’s a list of other retro-computing enthusiasts. There’s nothing necessarily wrong with that. But it tends to give us more of what we already know.

One of the lovely things about BookCrossing is that you might find a book you would never have chosen for yourself. Maybe you’re interested in technology, but the book you discover on a train is about gardening in the nineteenth century. You pick it up anyway. And who knows? Perhaps you enjoy it.

I’d want DigitalCrossing to work in much the same way. Someone who normally reads about cooking might receive one of my posts about a strange Linux experiment. I might receive a beautifully written story about somebody restoring an old boat in Norway. Would I ever have searched for that? Probably not. Would I read it? Quite possibly. And that’s what makes the idea interesting to me.

Perhaps we should let our content go travelling

I don’t know whether somebody has already built exactly what I’m describing. I’ve found several projects that do parts of it, but not a well-established community where digital content travels from person to person in quite the same way as a BookCrossing book. Maybe it exists somewhere in a forgotten corner of the internet. And perhaps I’ll stumble across it one day.

But if it doesn’t, I think it would be a fun thing to build. Not as a business. Not as a new social network. And certainly not as yet another way to maximise traffic to our websites. Just as a small experiment in connecting people and helping them discover things they weren’t looking for. After all, isn’t that one of the reasons many of us fell in love with the internet in the first place?

BookCrossing has been sending physical books around the world since 2001. Postcrossing has been doing something similar with postcards since 2005. Maybe it’s time we gave our blog posts the same opportunity. Write something. Release it into the wild. See where it goes. I rather like that idea.

The IndieWeb Needs More Builders and AI Can Help

I came across an interesting discussion about AI and the IndieWeb today. And I have to admit, I was a little surprised by it.

It started with Brennan Kenneth Brown (https://brennan.day/the-indieweb-now-has-genai-and-claude-built-in-what-do-we-do/), who noticed that Aaron Parecki, one of the people behind the IndieWeb movement, had been using Claude Code to rebuild several important IndieWeb tools.

Brennan wasn’t particularly happy about this. To him, the IndieWeb is about people building their own little corners of the internet, away from the influence of Big Tech. Using generative AI from a company like Anthropic to build those websites and tools seems to go against that idea. Aaron responded (https://aaronparecki.com/2026/10/17/5/rebuilding-my-indieweb-projects) with a blog post explaining why he uses Claude Code and why he doesn’t see a problem with it.

I understand Brennan’s concerns. But I’m definitely on Aaron’s side here.

Does everything have to be handmade?

I love the IndieWeb. I like personal websites, blogs, RSS feeds and people who build strange little things simply because they feel like building them. I also like the idea that my website is mine, my content is mine and I decide what happens to it. And yes, I understand that some people want to keep the IndieWeb pure. Whatever that means. They want websites built by humans, with code written by humans, without AI getting involved. Fair enough. If that’s how you enjoy building websites, please continue doing exactly that. But why should everybody else have to work the same way?

I’ve been using WordPress for years. I didn’t write WordPress. I didn’t write the theme or most of the plugins I use. Does that make my website less personal? Of course not. The same goes for people using Hugo, Jekyll or one of the many other tools available. We all use software that somebody else created. We copy bits of code, read tutorials, borrow ideas and use libraries that save us from reinventing everything ourselves.

So why is asking an AI to help write some code suddenly such a big problem? I don’t see the difference as being quite as fundamental as some people apparently do.

I have more ideas than programming skills

I’m a big fan of AI. I use it for all kinds of things, including coding. Or vibe coding, if you prefer that term. I’m not a professional programmer. I understand quite a bit about technology, but that doesn’t mean I can sit down and write a complete application from scratch.

What I do have is ideas. Lots of them. I regularly think of little tools that might be useful for my work as a journalist, for my blog or simply because I want to see whether something is possible. In the past, many of those ideas went nowhere. I could search for existing software, try to modify something or spend a lot of time figuring out how to write the code myself. Sometimes that worked. Quite often it didn’t.

Now I can sit down with an AI coding tool and start experimenting. Sometimes I have something working in an evening. Sometimes it takes days. Sometimes the AI makes a complete mess of things and I have to start again. But I’m building things I probably wouldn’t have built a few years ago. For example, I’ve been experimenting with software that collects IT news from websites in more than 23 languages. I also play around with Hugo, Docsify, local AI models and various little tools for my own publishing projects. I enjoy the process enormously. Not because every experiment produces something useful, but because I can finally try out ideas that would otherwise have remained ideas. And isn’t that exactly the sort of thing we want people to do on the IndieWeb?

Think about all the people who aren’t programmers

This is what I think is missing from some of the discussions about AI and the IndieWeb. Not everybody knows how to code. And not everybody wants to spend months learning. Someone might have a wonderful idea for a personal website but no idea how to build it. Someone else might want to add a special feature to an existing blog. Or create a small application that lets friends share photographs, book recommendations or whatever else they find interesting.

Without programming skills, those ideas can be difficult to turn into something real. AI changes that. Not perfectly, and certainly not without risks, but it does make building software much more accessible. I think that’s fantastic. Imagine someone who has never built a website discovering that, with a little help from AI, they can create something of their own. Perhaps they start with a simple page. Then they add a blog. Then an RSS feed. And before they know it, they’re experimenting with features they never thought they could build. They might even become interested in learning how the code actually works. I would much rather see thousands of people experimenting with their own websites, even with AI-generated code, than see them spend another ten years publishing everything on Instagram, TikTok or Facebook.

There’s a difference between AI code and AI slop

Now, I do think there’s an important distinction to make. Using AI to help build a website is not the same as using AI to fill that website with hundreds of meaningless articles. I don’t particularly enjoy visiting a personal blog only to discover that the content is generic AI-generated text with no real personality, experience or interesting ideas behind it. I visit personal websites because I want to read what people think, what they’re working on, what they’ve discovered or what made them laugh.

That’s the human part I care about. But if someone uses AI to create a clever publishing tool, improve the design of their blog or add some functionality they couldn’t have built themselves, why would that bother me? The same applies to writing, by the way. AI can help with research, editing, translations and getting a difficult paragraph into shape. The interesting part is still what the person behind the blog has to say.

Of course, AI can also produce terrible code. It can introduce security problems, misunderstand requirements or create software that is difficult to maintain. If you’re publishing a tool that other people depend on, you have a responsibility to check what you’re putting online. And that’s another reason I found Aaron’s response interesting.

What if the alternative is shutting things down?

Aaron explains in his blog (https://aaronparecki.com/2026/10/17/5/rebuilding-my-indieweb-projects) that some of his IndieWeb projects are around fifteen years old. They were built with technologies that are now outdated and increasingly difficult to maintain. Two examples are Webmention.io and IndieAuth.com, services used by many independent websites. He wanted to modernize them, but there was always something else to do. Sound familiar? With Claude Code, he has finally been able to tackle much of that work. He has rewritten old software, introduced new features and dealt with problems that had been sitting on his to-do list for years.

And here’s the important part: Aaron says that without these rewrites, he might eventually have had to shut some of those services down. That would hardly have been good news for the IndieWeb.

There’s another issue here. Many open-source projects depend on a surprisingly small number of people. People who maintain software in their spare time, often without being paid. They have jobs, families and other things to do. If AI helps them maintain their projects, fix bugs or finally implement features they’ve wanted to add for years, I see that as a good thing. Of course, AI doesn’t magically make software maintenance free or effortless. Someone still has to understand what the software does and take responsibility when something goes wrong. But if it helps keep useful projects alive, why reject it?

And what about Big Tech?

Brennan does have a point when he questions the use of AI services provided by large technology companies. I share some of those concerns. I’m not particularly interested in replacing our dependence on large social media platforms with a new dependence on a handful of AI companies. But I don’t think the answer is to reject AI altogether.

For one thing, we increasingly have open-weight AI models that can run on our own computers. I find that particularly interesting, and I’ve been experimenting with local AI myself. For another, using a commercial tool to build something doesn’t automatically mean that the thing you’ve built belongs to the company providing that tool. If I use Claude Code to help create a website that runs on my own hosting, uses open standards and stores my content in formats I can easily move elsewhere, I still have a considerable amount of control. And if I can replace Claude with another coding tool tomorrow, even better. For me, that’s much more important than whether every line of code was typed by a human.

There is also something rather nice about the fact that AI can help people create alternatives to the big platforms. We can use these tools to build more independent websites, more personal applications and perhaps even better ways for those websites to communicate with each other. That doesn’t solve every problem with AI. But it certainly makes the discussion more interesting.

Please, let’s not make the IndieWeb a club for programmers

Perhaps that’s what bothers me most about the idea that IndieWeb projects should be entirely handmade. It risks turning something that should be open to everybody into something primarily for people with the right technical skills. I don’t think anybody actually wants that. But it could easily happen if we start judging personal websites by the tools used to build them.

One of the things I enjoy about the personal web is how different everything is. Some websites are beautifully designed. Others look as though they haven’t changed since 1998. Some people write long essays. Others publish photographs, short notes or lists of interesting links. And I would love to see more people joining in. If vibe coding helps someone create their first personal website, that’s great. If it helps an experienced developer maintain an old IndieWeb service, that’s great too. And if someone prefers writing every single line of HTML by hand, that’s equally fine. There’s room for all of them.

After all, the IndieWeb is supposed to be about having your own place on the internet and doing things your own way. So let’s not start telling people that their way is wrong because they used AI. The IndieWeb doesn’t need fewer tools. It needs more people building things, experimenting, writing and sharing. And if AI helps make that happen, I’m all for it.

Just Me Wanderer: An experiment in random discovery, unexpected blog posts, and the wonderful variety of the independent web

One of the things I love about the IndieWeb is that you never really know what you are going to find. One moment you’re reading about someone building a tiny computer in their garage. A few clicks later, you’re looking at photographs of abandoned railway stations in Japan. And before you know it, you’ve spent twenty minutes reading a detailed account of someone’s attempts to grow tomatoes on a balcony.

None of these subjects were on your mind when you started browsing. You weren’t searching for them. You probably didn’t even know you were interested in them. And yet, here you are.

I think that’s one of the most enjoyable things about the independent web. It is full of people writing about whatever interests them. Not necessarily because there’s an audience for it. Not because some algorithm has identified a trending topic. But simply because they have something they want to share. And the variety is enormous.

A web that doesn’t fit into categories

We tend to talk about the web as if it consists of a relatively small number of subjects. Technology, politics, entertainment, sports, travel, food, and so on. But spend some time exploring personal websites and you’ll discover that these categories barely scratch the surface. People write about restoring old radios, collecting unusual maps, learning forgotten programming languages, identifying birds, experimenting with homemade musical instruments, or documenting the history of a single street in their hometown. Some blogs are beautifully designed. Others look as if they haven’t changed since 1998. Some authors publish several times a day. Others return after three years with a new post about something completely unexpected.

There is no editorial calendar to satisfy. No need to optimize every headline for search engines. No requirement to build a personal brand. Of course, some independent bloggers do care about traffic and visibility. Nothing wrong with that either. But the beauty of the IndieWeb is that people can decide for themselves what their websites are for. I find that incredibly refreshing.

The problem with looking for things

There is, however, a small problem. How do you discover all this wonderful stuff?

RSS helps enormously. I use it all the time. And services that encourage serendipitous discovery can take you to websites you would probably never have found otherwise. But even then, there’s a limitation. You tend to follow people whose interests overlap with your own. And when you discover new websites, they often come through people you already follow. That’s not necessarily a bad thing. It just means that your little corner of the web can gradually become rather familiar.

Search engines don’t completely solve this problem either. They are excellent when you know what you’re looking for. But what if you have absolutely no idea what you want to find? How do you search for something you don’t know exists? You can’t, really.

Which brings me to a little experiment I’m starting here on Just Me.

What if we let randomness do the work?

I’ve been playing with a simple idea. What if I built a system that searches for a completely random blog post somewhere on the independent web, reads it, and publishes a short introduction to it here on Just Me? Not a recommendation based on my interests. Not a carefully curated selection of the best articles of the day. And certainly not another algorithm trying to predict what I might want to read. Just a random blog post. It could be about photography, knitting, astronomy, a programming experiment, a family holiday, or someone’s thoughts about a book they finished yesterday. I genuinely don’t care. In fact, that’s the whole point. I want to discover subjects I wouldn’t normally look for. And I want to show just how incredibly diverse the independent web really is.

So I decided to automate the process.

A little script, an LLM, and a WordPress blog

The technical setup is relatively straightforward. A script searches for a blog post on an independently published website. It retrieves the content and passes it to a large language model, which produces a very short English introduction explaining what the post is about. The system then publishes that introduction on Just Me, together with a link to the original article.

The idea is to publish two of these discoveries every day, one at 10 in the morning and another at 5 in the afternoon (Amsterdam time. I do not manually select the subjects. I don’t tell the LLM to prefer technology, open source, privacy, or any of the other subjects I usually write about. The whole idea is to get away from my own preferences.

Of course, completely random discovery is harder than it sounds. The script still needs a way to find websites, and the sources it uses will inevitably influence what it discovers. It also needs to avoid spam, duplicate posts, and content that isn’t suitable for republishing even as a short introduction. So this isn’t mathematically perfect randomness. But it is an attempt to remove my own interests from the selection process as much as possible.

And just to be clear: the LLM isn’t writing new versions of other people’s articles. It is simply creating a short introduction and pointing readers to the original author’s website. That’s important to me. I want people to visit these websites, not replace them with AI-generated summaries.

I’m curious about the results myself

Here’s another thing I like about this experiment. I have no idea what will appear on Just Me tomorrow. Or next week. I might discover a fascinating blog about medieval architecture. Or a website dedicated to old railway timetables. Or a personal account of someone’s attempt to repair a thirty-year-old coffee machine. Maybe some of these posts will be fascinating. Others might be completely uninteresting to me.

Actually, I hope some of them will be about subjects I have absolutely no interest in. Because the purpose isn’t to build a collection of articles I personally enjoy. It is to demonstrate how many different interests, hobbies, ideas, experiences, and opinions exist outside the relatively small part of the web most of us visit every day. And perhaps someone reading Just Me will discover a new blog they want to follow. If that happens, the experiment has already achieved something worthwhile.

Giving a little attention back to the independent web

There’s also a broader reason why I want to do this. So much of our online attention is concentrated on a handful of enormous platforms. Their algorithms decide which posts we see, which subjects become popular, and which creators receive attention. Meanwhile, there are countless independent websites publishing interesting things that most of us will never encounter. Not because the content isn’t good. Simply because we don’t know these websites exist.

I don’t expect my little experiment to change that in any meaningful way. Just Me isn’t exactly a gigantic traffic generator. But perhaps it can send a few visitors to a website they’ve never heard of. Perhaps someone will subscribe to a new RSS feed. Perhaps a blogger somewhere will notice that a complete stranger has linked to something they wrote.

And I particularly like the idea of using AI for something like this. Not to produce an endless stream of synthetic content, but to help people discover things written by other people. AI as a tool for discovery rather than a replacement for the original work. That seems like a rather nice use of the technology.

Let’s see where this takes us

So, over the coming weeks, you’ll notice some rather unusual posts appearing on Just Me. They’ll be short. They’ll link to their original sources. And they’ll cover whatever subjects the script happens to stumble upon. There won’t necessarily be any connection between them. One day might bring a post about astrophotography followed by one about homemade bread. The next day could be about a forgotten video game or an unusual species of mushroom. I won’t know in advance. And that’s precisely what makes this fun (I hope).

The posts will appear on the Just Me homepage, just like my regular blog posts. But, if everything works as planned, they will also be collected on a separate page called Just Me Wanderer. That way, anyone who enjoys a bit of random exploration can browse through all these unexpected discoveries in one place. Think of it as a little doorway to corners of the web you didn’t even know existed.

What If an App Only Needs to Make One Person Happy?

As a student, you probably don’t need to explore every feature of your school’s digital platform at 7:15 in the morning. You need to know whether your first lesson is happening and which room you’re supposed to be in. Preferably before you leave the house.

That is the starting point of a project by Markus Haack (https://markus-haack.com/bessere-schule/) that caught my attention. His daughter’s school uses a platform called beste.schule for timetables, grades, announcements and various other things. The information she needs is there, but the app serves teachers, administrators, parents and students – all at the same time. You can imagine how many menus and options that involves. Way too much for his daughter at 7 in the morning.

So he built a different interface. One that puts students first and makes their everyday questions easier to answer. His daughter uses it daily and has shared it with some friends. According to Haack, the audience may be somewhere between one and three students a day, plus himself for testing.

Small can be enough

I like the idea that software can be worth building even when its entire intended audience fits around the kitchen table. We often talk about software in terms of numbers. How many users does it have? How quickly is it growing? Could it become a business? Those are reasonable questions if you’re running a software company. But if you’re building something for yourself or your family, you can measure its value much more directly: Does it help? Does someone actually use it? Does it make an annoying task a little easier?

That feels familiar. I have a daily job, and Just Me is one of my side projects. I also build tools for my journalism and writing, usually because there is something specific I want to do. Search through my own articles. Follow sources across different languages. Gather material that might otherwise disappear into a growing pile of bookmarks.

These projects begin with something in my own working day. Sometimes the result becomes useful enough to keep using. Sometimes I already suspect that I won’t use it very often, but I want to see whether I can get it working. There is value in that experiment too. I learn something, understand a problem better, or discover an approach I can use elsewhere.

Haack’s project has a particularly clear measure of success: his daughter opens it every day. For an app built to help her, that seems like a perfectly sensible result.

A different window onto the same information

Another thing I like about this example is that Haack didn’t build an entire school management system. The school continues to use its existing platform. His app provides a different window onto the information already stored there.

That distinction matters. A teacher and a student may need access to the same system, but they approach it with different questions. The teacher has administrative work to do. The student wants to check a room change or find out what homework is coming up. Putting every function into a single interface inevitably means some people spend time navigating around things they don’t need.

A personal tool can make different choices. It can give one question most of the screen. It can leave out entire categories of features. It can show next week’s timetable on a Saturday because that is more useful than the week that has just ended.

Those are small decisions, but they are the sort of decisions that make software fit someone’s routine. And they become easier to make when you know the person using it.

I recognise that in my own experiments. A tool built around how I work can be fairly simple because it doesn’t have to accommodate every possible workflow. I know where my files are, what sources I want to follow and what I need the output to look like. That gives me a useful starting point.

AI helps, but access makes it possible

Haack says he built the first version with Claude Code in two hours. That is an interesting part of the story, particularly given my own experiments with AI and tools for journalism. It is becoming easier to turn a specific idea into something you can actually try.

But another detail deserves attention: beste.schule has a documented API and encourages people to build tools around it. Without that access, the project would have been much harder, perhaps impractical. An AI coding tool can help create an interface, but that interface still needs a way to reach the information it is supposed to show. The API provides that connection.

This is where the story becomes bigger than one school app. If services provide documented ways to access our information, we have more room to choose how we use them. We can keep the underlying service while changing the part we interact with. We can build a simpler view, connect it to another tool or adapt it to a particular need.

That connects closely to why I like open formats and keeping my files somewhere I control. I want room to change tools as my needs change. An accessible API offers a related kind of freedom: the possibility of using the same information through a different application.

Someone still has to look after it

Of course, building a personal app doesn’t make maintenance disappear. Haack points out that changes to the underlying API could break his application. There are also limitations in what it can display, and some calculated information has to be clearly labelled as an estimate. Those details belong in the story too. Getting a first version working is one step. Keeping it useful is another. I have enough experiments of my own to recognise that difference.

Still, I find this a very appealing direction for personal computing. A parent sees a small problem, builds something around it, and a child finds it useful enough to use every day. The existing platform provides the data, and the new interface makes that data easier to use.

Perhaps more of our everyday software could work like that. Small tools, made for specific people and specific tasks, with enough access to the underlying information to be useful. And if one of them saves a teenager from walking to the wrong classroom before the first lesson, that sounds like a good morning’s work to me.

What If AI Had to Pay for the Web It Reads?

This is a long one, so bear with me. But I’ve really wanted to write about this for a while now, because it’s been on my mind for quite some time. So, here we go!

I love AI. I use it almost every day, experiment with local language models, and build little tools with it. Some of those experiments are useful. Others are simply fun to build. And quite a few are related to journalism, which is how I make my living.

But there is something about the AI industry that has bothered me for quite some time. AI companies have built incredibly powerful products using enormous amounts of information from the web. Articles, blogs, tutorials, research papers, discussions, documentation. Much of that material was written by people who never received a penny from the companies using it.

Whether all that training was legally permitted is still being debated in courts and elsewhere. But regardless of the legal arguments, there is an economic question here. If AI becomes one of the main ways we consume information, shouldn’t some of the money flow back to the people who create that information? Especially when those people are independent writers, bloggers, journalists and small publishers who don’t have the resources to negotiate licensing agreements with companies like Google or OpenAI.

Recently, I came across something called x402. And it made me wonder whether we might finally be seeing the beginnings of a different model. The interesting thing is that x402 isn’t the only initiative moving in this direction. There are experiments involving machine-readable journalism, new licensing standards and even marketplaces where publishers could sell their information to AI companies and others. Individually, these developments are interesting. Put them together, and something rather fascinating begins to emerge.

Two Cents for an Article? Why Not?

The idea behind x402 (https://x402.org/) is surprisingly simple. When your browser requests a webpage, the website normally sends the requested information back. Sometimes it refuses access, perhaps because you need to log in or don’t have permission. There is also an HTTP status code called 402, which stands for Payment Required. It has existed for decades but has never become a widely used way of paying for things on the web.

x402 builds on that idea. Imagine an AI agent looking for information about a particular cybersecurity vulnerability. It finds a relevant article on an independent technology website and requests access. Instead of simply handing over the article, the website responds: this will cost you two cents. The agent pays, the website verifies the payment, and the article is delivered. No subscription. No registration form. No credit card details to enter. No human intervention. The payment becomes part of the normal communication between two pieces of software.

Technically, x402 can use digital currencies such as stablecoins, which are designed to maintain a relatively stable value. That doesn’t mean a publisher has to become a cryptocurrency enthusiast. It does mean that wallets, payment providers and conversion into ordinary money are practical issues that need to be solved.

And two cents is just an example. A publisher could charge a fraction of a cent for a short piece of information or considerably more for access to a specialist report. For humans, paying separately for every article would probably be rather annoying. For software that automatically collects and processes information, however, such payments could be perfectly manageable.

This is what makes x402 interesting. It was originally developed by Coinbase and is now being developed as an open protocol under the Linux Foundation (https://www.linuxfoundation.org/press/linux-foundation-is-launching-the-x402-foundation-and-welcoming-the-contribution-of-the-x402-protocol). That matters because the web doesn’t particularly need another proprietary payment system controlled by a single company.

The Web Is Getting Some New Customers

There is another reason I find this interesting. For years, websites have largely been designed around human visitors. We write articles, people find them through search engines or social media, and hopefully they visit our websites. Those visitors might see advertisements, subscribe to a newsletter or pay for content.

AI is changing that relationship. Increasingly, people ask an AI assistant a question and receive an answer without visiting the websites where the underlying information originated. And AI agents are taking this further. They can search, compare sources, retrieve documents and process information without a human opening a browser at all.

For publishers, that creates a rather strange situation. Their information might become more useful than ever, while the number of people visiting their websites declines. A small specialist publication could produce an excellent article that is consulted by dozens of AI agents. Yet the publisher might receive no traffic, no advertising revenue and no indication that the article was used. That doesn’t sound like a particularly sustainable future for independent journalism.

But what if AI agents became paying customers? A specialist publication might offer its articles free to human readers while charging commercial AI services for automated access. Or it could offer a paid feed containing structured information specifically intended for machines. The website would no longer depend entirely on persuading humans to visit it. It could also earn money when software uses its work.

x402 Is Only One Piece of the Puzzle

Of course, the problem is more complicated than simply asking an AI agent to pay two cents. And x402 isn’t the only initiative trying to address it. Cloudflare, for example, has been developing several approaches to monetizing content used by AI. One is Pay Per Crawl (https://blog.cloudflare.com/introducing-pay-per-crawl/), which allows website owners to charge AI crawlers for accessing their pages. Another is Pay Per Use (https://blog.cloudflare.com/pay-per-use/), which takes a different approach. Rather than charging when information is collected, it aims to charge when that information is actually used by an AI service.

That distinction is important. An AI company might collect a thousand articles but use only a handful to produce an answer. Should it pay for collecting all thousand? Or only for the information it actually uses? There are arguments for both approaches, and they might eventually coexist.

Cloudflare has also introduced a Monetization Gateway (https://blog.cloudflare.com/monetization-gateway/) that supports x402, bringing automated payments closer to the infrastructure websites already use. Some of these services are still experimental or geographically restricted, so they are not yet ready-made solutions for every European blogger.

Then there is Tollbit (https://tollbit.com/), which focuses on licensed access to publishers’ content. Its approach includes different ways of charging for different uses, such as summarizing an article or reproducing more of its contents.

Another initiative worth watching is Really Simple Licensing (https://rslstandard.org/), or RSL. I particularly like the thinking behind this one. RSL is about making licensing conditions understandable to machines. A website could specify whether its content may be used for AI training, whether commercial AI services must pay, and which conditions apply. Think of it as a way for a website to tell automated visitors what they are allowed to do with its content. RSL could describe the rules, while x402 could handle a payment.

Another interesting development is SPUR, the Standards for Publisher Usage Rights coalition (https://www.spurcoalition.org/). It brings together more than 80 publishers and media organisations, including the BBC, Financial Times, The New York Times and AFP, to develop common standards for how AI companies use journalistic content.

One of its first initiatives is the Content Telemetry Standard, which aims to make AI systems record and report how they use publishers’ information. That addresses another important question: how can publishers charge for the use of their content if they don’t even know when or how it is being used? SPUR doesn’t solve that problem overnight. AI companies would still need to adopt these standards, and publishers would need ways to verify the information they receive. But it could provide another important piece of the puzzle: transparency. After all, before you can expect someone to pay for using your work, you need to know what they’re doing with it.

These initiatives don’t all solve the same problem. Some focus on payments, others on licensing, access control or measuring usage. But together they suggest something interesting: we may be moving towards a web where machines can negotiate access to information instead of simply taking whatever they can retrieve.

What If We Stopped Selling Articles and Started Selling Knowledge?

There is another idea that I think fits beautifully into this discussion: News Atom (https://reutersinstitute.politics.ox.ac.uk/introducing-news-atom-metadata-blueprint-journalism-age-ai). Developed by journalist Sannuta Raghu, News Atom starts with a rather interesting observation. Journalism isn’t just a collection of articles. Every article contains smaller pieces of information: facts, statements, figures, events, sources and context.

Those pieces of information have value of their own. Imagine a journalist writing about a new data center in Europe. The article mentions the investment, the planned power capacity, the location, the companies involved and the expected opening date. Now imagine an AI agent that only needs to know the power capacity of that data center. Why should it retrieve and process an entire article when it could obtain that particular piece of information directly?

More importantly, why shouldn’t the journalist or publisher who researched and verified that information receive something in return? News Atom proposes a way of making such information machine-readable while preserving the details that make journalism valuable in the first place. Where did the information come from? Who verified it? When was it published? Has it been corrected? What licensing conditions apply?

That last point is particularly interesting. Combine the thinking behind News Atom with machine-readable licensing and a payment protocol such as x402, and something new becomes possible. Not just for publishers, large and small, but also for the many other organisations that produce valuable content, from research institutes and industry bodies to all kinds of specialist organisations. An AI agent could potentially find a specific piece of verified information, check where it came from, understand the conditions for using it, pay for access and retrieve it. All without human intervention. Of course, News Atom itself is not a payment system, and this combination is still more of a possible future architecture than an established business model.

There is also an important distinction between facts and the journalism that produces them. A bare fact may not be protected by copyright, but the reporting, verification, context and structured data services surrounding it can still have commercial value. And that is precisely why I find this idea so interesting. Perhaps journalism’s future isn’t just about finding new ways to sell articles. Perhaps it is also about recognising that the knowledge journalists produce can have value independently of the articles in which it originally appeared.

For someone like me, who spends quite a bit of time experimenting with AI, journalism and automated news websites, that opens up some fascinating possibilities.

And What If Publishers Joined Forces?

There is another experiment worth mentioning, this time from Finland. Sitra, the Finnish Innovation Fund (https://staging.sitra.fi/en/articles/ai-can-create-new-business-opportunities-for-media-a-pilot-project-tests-the-marketplace-concept/), has been exploring something that sounds remarkably logical: a marketplace where news organisations can license their content to AI developers. And this isn’t just a theoretical exercise. Several Finnish media organisations, including Sanoma, Alma Media and public broadcaster Yle, are participating in a pilot that tests how journalistic content can be licensed, what AI developers actually need, and how much they might be willing to pay.

I find this particularly interesting because it addresses a problem that protocols such as x402 cannot solve on their own. A small publisher might have valuable information, but how does an AI company discover it? How does it know what rights are available? And how does the publisher find potential customers without employing a team of lawyers and salespeople? A shared marketplace could help solve those problems.

There is also a fascinating observation in Sitra’s research. AI developers training models often care more about having large quantities of usable information than about obtaining one particularly well-written article. That is not necessarily encouraging for an individual journalist or a small publisher. But it suggests that publishers might have more opportunities if they work together. Imagine hundreds of independent European publications making their journalism available through a shared marketplace. Each would retain control over its content and licensing conditions, while AI developers could discover and purchase information from many different sources. Combine that with ideas such as News Atom, machine-readable licensing and automatic payments through x402, and you can begin to imagine a rather different information economy.

Of course, we aren’t there yet. Sitra’s initiative is still testing the market, and nobody has demonstrated that this approach will generate substantial revenue for small publishers. But I like the direction. Instead of every publisher individually trying to negotiate with a handful of enormous AI companies, perhaps we could create an infrastructure where even the smallest independent publication can participate.

That sounds like a much more interesting future for journalism than simply putting another paywall in front of another article.

What About All the Content AI Has Already Consumed?

There is, however, an uncomfortable issue. Much of the content used to train today’s AI models has already been collected. And in many cases, the people who produced it weren’t asked for permission or offered compensation. I don’t think x402 solves that problem. A payment protocol cannot retroactively compensate millions of writers for material used in previous training runs. Nor can it decide whether a particular use of copyrighted material was legal. Those questions involve copyright law, licensing, transparency and, probably, a fair number of court cases.

But x402 and the other initiatives could help establish a different arrangement for the future. And I think that matters. I am not against AI companies making money. I use their products myself, and some of the technology is genuinely remarkable. But journalism costs money. Research costs money. Maintaining specialist knowledge costs money. Even writing a personal blog requires time, effort and usually a few hosting bills.

If AI services increasingly depend on information created by others, there should at least be practical ways for those creators to receive something in return. Not necessarily for every sentence an AI system reads. And not necessarily through one universal payment model. But the current situation, in which much of the economic value accumulates around the companies operating AI systems, deserves to be questioned.

Could This Work for a Tiny Independent Website?

This is where my curiosity really kicks in. Imagine a small independent technology publication that produces original reporting about European data centers, industrial automation or cybersecurity. It doesn’t have millions of readers. It doesn’t employ a sales team. And it certainly doesn’t have the negotiating power of The New York Times or the Financial Times. But it does produce information that might be valuable to AI services.

With an open payment protocol, the publisher could theoretically make that information available to automated customers without negotiating individual contracts. An AI agent requests an article. It receives a price. It pays. It gets access. That sounds almost too simple.

And perhaps it is. There are still plenty of unanswered questions. How does a website distinguish a legitimate paying AI agent from a crawler that ignores the rules? How do publishers know what their information is worth? Who pays the transaction fees? How do they prevent someone from buying an article once and redistributing it indefinitely? And perhaps most importantly: will AI companies actually be willing to pay? A technically elegant payment system is not much use if nobody wants to use it.

The economics are also uncertain. Ten thousand paid requests at one cent each would generate €100 before costs. That might be a nice contribution towards hosting expenses, but it isn’t going to finance a newsroom. A specialist publisher would need either substantial demand, higher prices, or other sources of revenue.

Still, I wouldn’t dismiss the idea just because the first numbers might be small. The important development is that a small publisher could potentially participate in a market that previously required direct commercial agreements with large technology companies.

Please Don’t Turn the Entire Web Into a Paywall

There is one thing I would hate to see happen. Imagine an internet where every article, blog post, tutorial and personal website demands a payment before anyone can read it. That would be awful. One of the things I love about the independent web is that people publish information simply because they want to share it. Someone writes about an obscure music genre. Someone else documents a strange Linux experiment. Another person explains how they built a little tool that nobody else thought of. There is no business plan. No marketing funnel. No expectation that every page must generate revenue.

I certainly don’t want to lose that. But I don’t think we have to choose between an open web and a web where creators can get paid. A personal blog could remain completely free for human visitors. The owner could allow non-commercial crawlers to access it, while requiring payment from commercial AI services that use the material in their products. Or the owner could decide not to charge anyone.

The important thing is that the website owner gets to decide.

That fits rather nicely with the whole idea of the IndieWeb. Own your website. Own your content. Choose your tools. Decide how your work may be used. And, perhaps, decide whether someone should pay for using it commercially.

Maybe This Is a New Opportunity for Journalism

I have been experimenting with AI and journalism for quite some time. One of my projects is an automated technology news website that collects information from sources in more than 23 languages, using two local language models running on a server in my own workroom. Experiments like this have made me increasingly aware of how much modern information systems depend on the work of other people. Without those sources, there is very little for the software to work with.

That is one reason I find this whole development so fascinating. I can imagine independent publishers offering machine-readable news feeds, specialist databases, research archives or individual articles through systems like x402. I can also imagine AI agents with small budgets that decide which information is worth buying. Some information might be free. Some might cost a fraction of a cent. Some highly specialised material might cost considerably more. And perhaps we could finally develop business models that don’t depend entirely on advertising, subscriptions or the goodwill of readers.

Will that happen? I have no idea. x402 might become an important part of the web’s infrastructure. Or another standard might take its place. Perhaps licensing systems and payment services will develop in completely different directions.

But something is clearly changing. For years, the conversation about AI and publishers has largely revolved around whether AI companies should be allowed to collect and use content. Now we are beginning to discuss how they might pay for it. And thanks to initiatives such as News Atom and Sitra’s marketplace experiment, we are also beginning to think differently about what exactly journalism could sell. Not just articles, but verified information, context and knowledge.

That is a much more interesting conversation. And for someone who loves both AI and the independent web, it is one I intend to follow closely. Because I don’t want a future without AI. But I certainly don’t want a future where AI has consumed the very web that made it possible.

A Children’s Story About AI Reminded Me Why I Like Making Things

A children’s story about the Hugging Face swarm. Remember that security incident? The Hugging Face swarm was a group of OpenAI AI agents that escaped their isolated testing environment and worked together to gain unauthorised access to Hugging Face’s systems.

The combination of that incident and a children’s story alone was enough to get my attention. I spend quite a lot of time reading about technology, experimenting with AI and building tools. But explaining an AI topic in the style of a children’s book? That immediately made me curious.

I came across the project through a post on Aceso Under Glass (https://acesounderglass.com/2026/10/10/before-i-could-read-i-would-write/). The author has published “Frog and Toad and the Increasingly Capable Machines” (https://frogandtoad.ai/), which explains the Hugging Face swarm through the familiar format of a children’s story. What stayed with me was both the idea itself and the personal story behind it.

As a small child, the author wanted to write. Before she could do that herself, she invented stories and her parents wrote them down for her. Eventually, she learned to put those stories on paper independently. Later, fiction largely slipped out of her life, although the desire to write it occasionally resurfaced. Publishing this project brought something back: the pleasure of making a story that her younger self would have wanted to read.

I like that. A technical subject becomes the starting point for storytelling, and storytelling becomes a way of reconnecting with something personal. There is a lot going on in what initially looks like a wonderfully unusual little project.

It also made me think about how we explain technology. In my work, I come across plenty of explanations that assume the reader already understands most of the vocabulary. You start reading because you want to understand something, only to discover that you first need to understand five other things. Sometimes I find myself opening so many browser tabs that I almost forget what the original question was.

Not just a simplification

Storytelling offers another way in. A story gives you characters, actions and consequences. Something happens, someone responds, and the situation changes. That structure can help a reader follow an unfamiliar idea before encountering all the terminology associated with it. You have something to picture and a reason to keep reading.

Of course, a story is a simplification. Characters can suggest intentions that a machine does not have, and a neat sequence of events can make a complicated system appear more predictable than it really is. The useful question is whether the story gives you a starting point from which you can ask better questions. Does it make you curious enough to explore further?

As a journalist, I find that an interesting challenge. Explaining something simply is hard work. You have to decide which details matter, what the reader needs to know first and where your explanation might create the wrong impression. Turning it into a story adds another task: making the explanation readable enough that someone actually wants to follow it. Storytelling can be a way of testing how well you understand the subject yourself.

The pleasure of making the thing

That part feels familiar. I have been building quite a few tools of my own, combining journalism, scripts, locally running language models and websites. Some projects begin with a practical problem. I want to find sources, organise information or make a publishing process simpler. Others begin with a question that is much less structured: could I get this to work?

I do not always know whether I will use the result every day. Sometimes I already suspect that I won’t. But I still want to try, because the process itself is interesting. I learn how the pieces fit together. I discover that an apparently simple idea contains three unexpected problems. Occasionally, solving one of those problems gives me an idea for something else.

Reading about this children’s story reminded me that a project can also give you something you did not know you were looking for. In the author’s case, it brought back a connection with an early ambition. In my experiments, it is often the satisfaction of turning a vague thought into something I can actually open, run or show to someone.

Strangers who want to help

The response to the story adds another layer. The author describes strangers volunteering to translate it, with German and Bengali versions becoming available. Someone else offered to improve the website. A personal project became something other people wanted to help with and share. I find that a very nice example of what can happen when you put an unusual idea on the web.

We spend a lot of time discussing what AI can produce, how much time it can save and which tasks it can automate. Those are questions I explore myself. But this project prompted a different one: what would I enjoy making, simply because I would like it to exist?

Apparently, in this case the answer was a children’s story about the Hugging Face swarm. And now I am wondering which of the technical subjects sitting in my own browser tabs might benefit from a little storytelling.

Please Rewind Before Playing Doom

I tend to think of VHS tapes as things you watched. You put one into a video recorder, pressed play and hoped nobody had recorded something else over the film you wanted to see. Gaming belonged to another device under the television. At least, that was the arrangement I understood.

Then I came across this article on hackaday (https://hackaday.com/2026/10/05/porting-video-games-to-vhs/) about bringing video games to VHS. Which is certainly an unusual way to spend an evening gaming. Somewhere between finding the controller and remembering what the tracking button did.

The project is by a creator called Throaty Mumbo. After trying ActionMax, an older VHS gaming system with a light gun and footage that played the same way each time, he decided to build something more interactive. His setup uses a VHS tape containing both video streams and binary game data, with additional electronics decoding that information and processing controller input. The tape supplies the material; modern hardware makes interaction possible.

The demonstrations include Super Mario Bros. with video backgrounds, Night Trap and a version of Doom built around prerecorded footage and timed button presses. That last detail matters: this is a different interpretation of playing Doom, rather than the familiar game simply running inside a video recorder.

What caught my attention was the choice of medium. A tape moves forward through a sequence. A player, meanwhile, expects to make decisions, change direction and interfere with what happens next. Putting those two things together creates a rather interesting design problem. How much interaction can you build around something that keeps rolling?

I like coming across projects that start with a question like that. Most of us look at an old video recorder and see a device whose working life has ended. Someone else sees a collection of mechanisms, signals and possibilities, then wonders whether it could become part of a game system. I recognise a little of my own approach here. Some of my projects begin with something I want to try, even though I already know I am unlikely to use it in everyday life. I will happily spend time figuring it out anyway. Much of the fun is in experimenting, solving the little problems along the way and seeing whether I can actually get the thing to work. That moment when it finally does what I hoped it would do can be enough reason to have built it.

It also makes me think about how easily we accept the intended purpose of technology. A video recorder plays films. A browser displays websites. A text editor lets us write. Those descriptions are useful, but people keep finding ways to stretch them. Sometimes the result becomes a practical tool. Sometimes it becomes a wonderfully peculiar experiment involving Doom and a magnetic tape.

Would we replace a modern gaming system with this? I suspect the novelty would have to carry quite a lot of the experience. But I would certainly be curious to try it. There is something appealing about having to rethink a familiar activity because somebody has deliberately chosen an awkward piece of hardware.

And if the game goes badly, at least there is finally a plausible reason to say: perhaps I should rewind and try again.