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.

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.

Five Ways to Get Writing When the Words Won’t Come

Writing is what I do for a living. It is also what I do here, on Just Me, when something catches my attention and I want to explore it. You might think that combination would make starting easy. Open a document, put your fingers on the keyboard, and off you go. If only.

Sometimes you know the subject, have your sources ready, and even have a reasonable idea of what you want to say. Yet the first paragraph refuses to appear. Or you write three sentences and immediately start rearranging them, as if the rest of the article will somehow emerge from getting those first fifty words exactly right.

I regularly come across tips for getting the writing process going when the words won’t come. Here are five that sometimes work for me—and might be worth trying when you’re stuck, too.

1. Tell the story before you type it

Imagine someone asking what your article is about. You would probably give them an answer without spending ten minutes deciding on the opening sentence. That is the idea behind talking through a draft. Record yourself explaining the subject. What happened? Why did it catch your attention? What is confusing, surprising, or relevant about it? Allow yourself to ramble a little. You can use a transcription tool afterwards, or simply listen back and pull out the useful bits. A spoken explanation does not have to look like finished writing. It gives you material, and material is much easier to edit than an empty page.

2. Give yourself five minutes to write something imperfect

Set a timer and keep writing until it rings. Leave awkward sentences alone. If you cannot remember a detail, put a note in brackets and move on. The aim is to get a rough version out of your head. Tools can help here. For example, Ilys (https://www.ilys.com/) restricts what you can see while writing, preventing you from endlessly revisiting earlier sentences. Or use an app called The Most Dangerous Writing App, which has a simple yet dangerous approach: stop typing for too long during a session and your text disappears (https://www.squibler.io/dangerous-writing-prompt-app). I think I would start with an ordinary timer. Having software threaten to delete my work sounds like an additional source of stress. But the underlying exercise makes sense: give drafting a few uninterrupted minutes before editing gets its turn.

3. Draw the connections

Sometimes the problem is that there are too many things to say, and they are all trying to become the first paragraph. Put the subject in the middle of a sheet of paper. Around it, add the main questions, examples, consequences, and loose thoughts. Draw connections where you see them. You can do this in a mind-mapping application, but pen-and-paper is perfectly adequate. For a technical article, those branches might include how something works, who uses it, what it costs, and where the limitations are. Seeing those elements together may help you find a route through the subject. You can decide on the sentences once you know where you are going.

4. Ask AI to ask you questions

People often ask AI questions. But let’s turn that around and have AI ask us questions instead. Given my experiments with AI and tools for journalism, this feels like a natural approach. An AI conversation can help you find a way into a subject by asking questions you haven’t yet considered. Try something like: “I want to write about this subject. Ask me one question at a time to help me work out what I want to say.” You could also ask which parts of your explanation are unclear, or what a reader unfamiliar with the topic would need to know. Answering a specific question can be easier than producing an introduction on demand. Those answers become useful raw material. You still need to check facts and decide what belongs in the piece, but you have started exploring the subject in words.

5. Fill eight small boxes

This is probably the simplest experiment of the lot. Fold a sheet of paper three times, unfold it, and you have eight sections. Give yourself one minute per section to write a sentence, a question, an example, or a short phrase. Eight minutes later, you have eight possible starting points. The small spaces make the task feel manageable. One box might contain the central question. Another might hold an anecdote. A third could reveal something you still need to look up. There is no obligation to turn them into eight paragraphs; they are pieces you can arrange and develop.

I like that this requires almost no preparation. No account, no configuration, no new writing environment to spend the evening setting up. Although, knowing my interest in building tools, turning it into a small application would be tempting. Perhaps I should fill the boxes first. That would at least give me something to write about 🙂

My Words Should Outlive My Apps—and Markdown Makes That Possible

I have used plenty of writing applications over the years. What increasingly matters to me is whether I can leave them again. Can I take my words elsewhere, open them with another tool and carry on working? Or does changing applications turn into a migration project?

That is why I am such a fan of Markdown (see https://markdown.org/ for more). An .md file is essentially plain text, with simple conventions for headings, links, lists and emphasis. I can open it in a dedicated writing application, a basic text editor or a terminal. The application can change. My words remain accessible.

That freedom was also the reason I started using Obsidian for notes and personal knowledge management. I came from Capacities.io, which I liked very much. But my files were in their cloud and I really wanted md as my standard format. Obsidian has many features that are very useful (like the graph), but the deciding factor was the foundation: Markdown files in folders I control. If another application suits me better tomorrow, I can “take my files with me”—although that really means leaving them exactly where they are, in Nextcloud, and pointing the new application to that location. My files stay put; I simply choose a different tool to work with them.

I have now taken that approach a step further. A script automatically creates a Markdown version of every DOCX and ODF document in my Nextcloud environment. The originals remain available, while the Markdown copies give me another way to search, process and reuse the text. Complex formatting may not survive the conversion perfectly, but for much of my writing, access to the content matters more than preserving the page layout.

There are practical advantages everywhere. Markdown files are small, easy to back up and usable offline. Ordinary search tools can read them. Scripts and locally running language models can process them. Publishing tools such as Hugo and Docsify can turn them into websites. The same text can move between different workflows without needing to be recreated each time.

Markdown does have different flavours. Tables, footnotes and application-specific features do not always travel perfectly. That is why I prefer to keep the underlying documents fairly simple. The fewer special additions I depend on, the more freedom I retain.

For me, this is what an open format should make possible: choosing my editor, choosing my storage and changing my mind. My files can live on my laptop, in my home network or with a hosting provider I select. They remain my files.

And that is also why Markdown feels like a foundation for the future. New applications and new ways of working can develop around it, while the text remains readable. Even if a favourite application disappears, I should still be able to open what I wrote. A heading marked with a hash sign may not look particularly revolutionary. But being able to keep decades of writing independent of the software used to create it? That is a future I would happily write myself into.

You Can Bomb a Data Center, But the Bots Just Move Elsewhere

There is something fascinating about the way the Internet works. We tend to think of it as an enormous collection of servers, data centers, cables and networks. Destroy enough of that infrastructure and surely whatever is running on it will disappear too. Well, apparently not.

I came across a fascinating analysis by Cloudflare (https://blog.cloudflare.com/yandex-outage/) about what happened when Ukrainian drone strikes reportedly hit three Russian Yandex facilities between October 7 and 11. Yandex, for those unfamiliar with the company, is often described as the Russian equivalent of Google. It operates a search engine, but also provides cloud infrastructure and numerous other online services.

The attacks caused enormous disruption. According to Cloudflare, traffic from Yandex’s search network dropped by an astonishing 99% at one point. Traffic from its cloud network fell by 90%. And almost immediately, people started celebrating the apparent disappearance of Russian bot farms and online influence operations. There was just one problem: the bots hadn’t necessarily disappeared. Many had simply moved.

Not all bots are bad bots

Before getting into what Cloudflare discovered, there is an important distinction to make. Not every bot is malicious. A bot is simply a piece of software that automatically performs tasks on the Internet. Search engines use bots to discover and index websites. Monitoring services use them to check whether systems are working. And, increasingly, AI companies use them to collect information.

Cloudflare distinguishes between different types of automated traffic. One category is called verified bots. The word “verified” simply means that Cloudflare has confirmed that a bot really belongs to the organization it claims to represent. For example, a verified YandexBot is genuinely operated by Yandex rather than someone pretending to be its search crawler.

Being verified doesn’t automatically mean everyone welcomes that bot. It simply means its identity has been established. This distinction turned out to be rather important. Cloudflare discovered that most of the traffic disappearing from Yandex’s search infrastructure came from legitimate search crawlers. These were bots indexing websites, downloading images and collecting information for search results.

In other words, a substantial part of the spectacular traffic collapse was simply Yandex becoming less capable of indexing the web. Not quite the same thing as destroying a Russian army of malicious bots.

The bots that changed address

The situation was more interesting on Yandex.Cloud, the company’s cloud-hosting infrastructure. Here, Cloudflare did observe a significant decline in suspicious activity. Automated attempts to identify vulnerable WordPress plugins, for example, fell by 90%. Other scanning activity dropped by 93%.

That sounds like excellent news. But Cloudflare looked beyond the overall traffic numbers. It examined how individual bots behaved, which websites they contacted and what technical characteristics their connections shared.

One particularly interesting example involved automated traffic targeting gambling websites. Immediately after the disruption, requests originating from Yandex.Cloud disappeared. But almost identical requests started appearing from other Russian hosting providers.

Cloudflare could recognize them through something called a JA4 fingerprint. This is a technical signature based on how software establishes a secure Internet connection. Think of it as a way to recognize the same kind of software even when it starts operating from a different server or IP address. The bots were using the same unusual request patterns, the same identifying information and the same technical fingerprints.

They hadn’t stopped working. They had changed hosting providers. In fact, the total volume of Russian-origin bot traffic targeting gambling accounts remained remarkably stable. It actually increased slightly during the period Cloudflare examined.

The Internet is surprisingly portable

This is what makes the story interesting to me. We have spent decades making computing infrastructure increasingly flexible. Virtual machines, containers, cloud platforms and automation allow applications to move between systems with relatively little effort. That flexibility is one of the great achievements of modern computing.

But it works for malicious software too. If an operator can move an application from one cloud provider to another, why wouldn’t someone running a bot network be able to do exactly the same thing? The physical infrastructure may be destroyed or disconnected, but the software itself can survive somewhere else. Provided, of course, that the operators still have access to their code, data and alternative infrastructure. And apparently, some of them did.

There is also a lesson here about how we interpret Internet statistics. A dramatic graph showing traffic falling to almost zero looks convincing. It creates an impression that something has been eliminated. But what exactly has disappeared? The servers? The network connections? The software? Or merely the traffic coming from a particular group of IP addresses? Those are very different things.

What about Russian disinformation?

Another interesting aspect of Cloudflare’s investigation concerns claims that the attacks had disrupted Russian influence operations on social media. Cloudflare examined traffic associated with social media activity, including automated requests involving posts, replies and likes. It found no unexpected changes that would support claims of a major collapse in these operations.

That doesn’t prove that no influence operation was affected. Cloudflare can only analyze the traffic visible to its own network, and not every social media operation can be identified through HTTP requests. But it does demonstrate why we should be careful about drawing conclusions from spectacular traffic charts.

A decline in traffic from Russian infrastructure does not automatically mean that Russian disinformation has stopped.

Destroying infrastructure is not the same as destroying an operation

What I particularly like about this Cloudflare investigation is that it illustrates something much broader than the consequences of a few drone strikes. We have created an Internet where software is increasingly independent of the physical machines on which it runs. That is exactly what cloud computing was supposed to achieve. Applications should be portable. Services should survive infrastructure failures. Workloads should be able to move between providers. And when we celebrate those capabilities, we usually think about legitimate businesses, websites and applications. But the same principles apply to people using the Internet for less legitimate purposes.

The Cloudflare findings don’t mean that attacks on infrastructure have no consequences. Clearly, Yandex suffered a substantial disruption, and legitimate services were affected. Nor do they mean every malicious operation can relocate without difficulty. They do show, however, that destroying infrastructure and stopping an online operation are two very different challenges.

Perhaps that is the most interesting conclusion of all: we have made software so good at surviving infrastructure failures that even the bad guys benefit from it. And somehow, that seems a very Internet-like outcome.

What If Your Friends Were Your Cloud?

I have a soft spot for local-first software. And for slightly crazy ideas that make you wonder why we accepted the current way of doing things as the only logical option. Yggstore ticks both boxes (https://github.com/peterretief/yggstore).

Yggstore is an experimental open-source project that basically asks a very simple question: what if we could build our own cloud using the computers of people we trust? No Google Drive. No Dropbox. No OneDrive. No giant data centre somewhere. Just computers. Your computer. Mine. A mini PC at my brother’s house. An old laptop at a friend’s place. Maybe a Raspberry Pi somewhere else. Together, they become the cloud.

Your file is everywhere. And nowhere.

The basic idea behind Yggstore is surprisingly easy to understand. Suppose I have a large file that I want to store. Instead of uploading that file to a cloud provider, Yggstore encrypts it and chops it into pieces. Those pieces are then distributed across different computers participating in the network.

Importantly, Yggstore adds redundancy. It doesn’t simply cut a file into four pieces and hope that all four computers remain online forever. It creates additional pieces that can be used to reconstruct missing data. So if one of the machines disappears, breaks down or is temporarily offline, I can still retrieve my file. In that sense, it reminds me a little of RAID. Except that instead of several disks sitting inside one server, the “disks” can be computers sitting in different houses. That immediately makes the idea much more interesting.

The tiny file that matters

There is another clever part. After storing something in Yggstore, you keep a small .ystub file locally. Think of it as a luggage tag. The suitcase itself may be somewhere in the enormous luggage system of an airport. The tag contains the information needed to find it again. The Yggstore stub performs a similar role. Give it back to Yggstore and the software can retrieve enough pieces from the network, reconstruct the data and decrypt the original file.

That also means those tiny stub files are rather important. Lose them and retrieving your data becomes a problem. So yes, you need to back up the information that tells your backup system how to find your backups.

Your own little internet

Yggstore doesn’t do all this over the normal internet in quite the same way that Dropbox does. It uses Yggdrasil, an encrypted IPv6 overlay network. In simple terms, Yggdrasil allows computers to create their own peer-to-peer network on top of the existing internet. That network can consist of machines belonging to people you trust.

Which is where the whole concept becomes particularly appealing. Imagine four or five friends each buying a cheap second-hand mini PC with a reasonably large SSD. Everyone puts one somewhere in their house and makes part of the storage available to the others. My encrypted data might partly reside in Amsterdam, another piece in Brussels and another somewhere in Germany. Your data might partly reside on my machine. Nobody needs to be able to read anybody else’s files.

There is no central cloud company. Because we are the cloud.

I rather like that sentence

Because somewhere along the way, “the cloud” became synonymous with Amazon, Microsoft, Google and a relatively small number of other enormous companies. Technically, of course, it never had to mean that. Cloud computing is fundamentally about abstracting computing resources. Where those resources physically live is a different question. Yggstore takes that idea in almost the opposite direction from Big Tech. Instead of:

my laptop → Big Tech cloud → my data

we get something closer to:

my computer ↔ your computer ↔ his computer ↔ her computer

It is distributed computing brought back down to human scale. And that fits remarkably well with what I find interesting about the current local-first movement.

Local-first doesn’t have to mean local-only

This is an important distinction. When I talk about local-first computing, I don’t mean that everything has to live on one laptop disconnected from the rest of the world. That would throw away many of the genuinely useful things we gained from cloud computing. I want synchronization. I want backups outside my house. I want to access information from different devices.

The interesting question is whether achieving all of that automatically requires handing our data to a giant technology company. Projects like Yggstore suggest another answer. You can have distributed storage without necessarily having centralized ownership. That is a rather important distinction.

And apparently storage isn’t enough

Yggstore is already experimenting with more than simply storing files. There is versioning. There is file sharing. Nodes can exchange messages. The project even experiments with distributed website hosting and receiving email for your own domain.

There is also an interesting “give and use” principle. If I use storage provided by other people, I should provide storage to the network myself. Yggstore keeps track of that balance, although the mechanism is not yet strictly enforced. Instead of paying a company €10 every month for 2 TB of storage, I contribute resources to a community and receive resources from that community in return. It feels surprisingly old-fashioned. In a good way, that is. It reminds me of the earlier internet, when the idea wasn’t necessarily that every useful online activity needed a company, a subscription and a platform sitting in the middle.

Don’t cancel Dropbox just yet

There is, however, a rather large disclaimer attached to all of this. Yggstore is a proof of concept. The developer explicitly warns that the cryptography has not been independently audited. There are also technical limitations. For example, lost storage fragments aren’t yet automatically rebuilt elsewhere.

I would therefore not put the only copy of my life’s work on Yggstore. Actually, I wouldn’t put the only copy of my life’s work on anything. Backups are backups because there is another copy. But that isn’t really why I find Yggstore interesting. I am interested in the idea behind it.

Personal computing 2.0?

Over the past few years we have started seeing lots of small projects pointing roughly in the same direction. Local-first software. Self-hosting. Small servers at home. Open-source AI models running locally. Peer-to-peer networks. Personal knowledge systems where the files remain ours. And now experiments where a group of ordinary computers can collectively behave like cloud infrastructure.

Individually, none of these projects is going to replace Big Tech tomorrow. Together, however, they suggest that another architecture for personal computing is possible. One where the laptop becomes important again. Where a €150 mini PC can actually be useful infrastructure. Where cloud services complement our computers instead of replacing them. And, most importantly, where ownership starts with the user.

Yggstore may never become mainstream. It may remain an experiment. Another project may eventually implement the same idea much better. That doesn’t really matter. The interesting part is the question it asks: What if we didn’t need a cloud provider to have a cloud?

Put a few computers in a few houses, connect them securely, contribute some disk space and distribute encrypted data between them. Suddenly the answer becomes surprisingly tangible. Maybe the cloud doesn’t have to be someone else’s computer after all. Maybe it can be ours.

What If IT News Had a Passport and Could Travel the World?

I have been working at the intersection of journalism, AI and websites for quite some time now. I like all three, but I particularly enjoy combining them. And one thing keeps bothering me. Journalism — or at least the kind of journalism I know best — isn’t exactly overflowing with innovation. Newsrooms do what newsrooms have always done. They find stories, write articles and publish them. Of course, the tools have changed enormously. We have websites, newsletters, social media, analytics and now AI. But the basic process? Not so much.

There is another thing that has puzzled me for years. I live in the Netherlands and work mainly as an IT journalist. When I look at the sources used by Dutch IT media, they are overwhelmingly Dutch or English-language sources. Which is slightly strange when you think about it. Apparently, interesting things in IT happen in the Netherlands, the US and the UK. Perhaps occasionally somewhere else — provided somebody writes about them in English. That cannot possibly be true.

There is a world outside the English-language web

Interesting technology companies exist in Poland. Researchers publish interesting work in Japan. Startups emerge in South Korea. German companies develop new industrial technology. There are cybersecurity incidents in France, infrastructure projects in Scandinavia and interesting IT developments in Brazil, Italy, Spain, Croatia and dozens of other countries. Local journalists write about all of this. We just don’t read most of it.

There is another problem with relying so heavily on English-language sources. IT journalists unintentionally amplify the already enormous marketing power of predominantly American technology companies. These companies have large PR departments, communicate in English and are extremely good at getting their stories into the international technology press.

If journalists mainly watch that part of the information landscape, it shouldn’t surprise us that those same companies dominate the news. So I decided to build something.

IT news from 23+ language areas

The result is a proof of concept: AroundTheITWorld.news (https://www.aroundtheitworld.news). It is an IT news website, but not quite in the traditional sense. Instead of concentrating on a handful of familiar English-language sources, it watches technology websites across more than 23 language areas. Twice a day, a script checks sources scattered around the world. Korea to Croatia. Brazil to the Benelux. Japan to Poland. Germany to Denmark. Australia to Thailand and Hongkong.

The script looks for new and potentially interesting stories. When it finds one, a locally hosted LLM turns the source material into a short English-language news item and includes a link to the original article. Actually, I use two LLMs. One handles Western languages, while another deals with Asian languages. Both LLMs run on a server in my home office. The resulting articles are automatically published on a website built with the Hugo static site generator. The whole thing costs me about €30 a year.

There is no editor sitting there copying and pasting stories into a CMS. The entire process runs automatically. I have written before about using this approach to create fully automated niche news websites. But AroundTheITWorld.news has a slightly different purpose. I built it because I want journalists — including myself — to look further than the English-language information bubble.

And then Croatia beat everyone

Almost immediately, the site demonstrated why this can be useful. AroundTheITWorld.news had only been live for a few minutes when a story appeared about Schneider Electric acquiring PTC. That is not some obscure local story. It is major international technology news that quickly travelled around the world. But the first report I encountered about it through my new system came from…Croatia. An IT publication in Croatia had picked it up.

I loved that. Not because Croatia somehow “beat” the rest of the world. That isn’t the point. The interesting part was that my little experiment had immediately surfaced a source I almost certainly would never have checked myself. Nice work by that Croatian journalist! And exactly the kind of thing I hoped this project would uncover.

Journalism experiment meets technical experiment

For me, AroundTheITWorld.news combines two ideas I keep coming back to.

The first is journalistic innovation. It doesn’t always have to involve enormous projects, expensive platforms or some grand reinvention of journalism. Sometimes innovation can simply mean changing the way we look for information. What happens if, instead of following 30 familiar websites every morning, you let software monitor hundreds of sources across more than 20 languages? Suddenly your information horizon becomes much wider.

The second part is technical experimentation. AroundTheITWorld.news is a fully automated website. Scripts collect the information, LLMs process it, Hugo (https://gohugo.io/) builds the pages and the resulting news service keeps running without somebody continuously operating it.

And, perhaps more importantly, I actually use it. Every morning I take a look. Usually I return several times during the day. Not because I have to maintain the site. Simply because I am curious. What is happening in the global IT world? What is happening today in Poland? What did a Japanese IT publication notice? Is there an interesting cybersecurity story in France? What are German technology journalists writing about? Did somebody in Brazil spot something that hasn’t reached the English-language technology press yet? That has become a surprisingly enjoyable routine.

Then the AI had an idea

There is one more part of this project that I rather like. The website was built through vibe coding. The first version was extremely simple: basically a textual website with a list of news stories and links. Which was fine. In fact, I quite liked it.

Then the AI tool I use to build these kinds of websites and news services made a suggestion. A list of stories was clear and functional, it said, but since the whole idea was about global news, why not make that visible? Why not show where the stories come from on a globe? I hadn’t asked for that. But it was a good idea. So we built it.

And that is what you now see on AroundTheITWorld.news: stories appearing around the world, geographically rather than just chronologically. In a funny way, that small visual change made the original idea much clearer. The IT world isn’t a list of English-language websites. It is a very large place full of people researching, building, experimenting, investing, failing, succeeding — and writing about it. Sometimes in English. Often not. Maybe we should start reading more of the latter.