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 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 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.

Public is public. But does that mean everywhere?

I came across an interesting little post by Kev Quirk about something I had never really thought about before: privacy and Webmentions. And the more I thought about it, the less obvious the answer became.

Kev’s post started with a reader raising a privacy concern about Webmentions. In particular, the reader had stopped using them because people posting replies on the Fediverse may not realise that those replies can subsequently appear on somebody else’s website through Webmentions. You can read his post here: https://kevquirk.com/privacy-and-webmentions?utm_source=chatgpt.com

For those who have never encountered Webmentions (https://www.webmentions.com/), the basic idea is rather nice. They are part of the collection of technologies and conventions generally associated with the IndieWeb. If I write something on my website that refers to something on your website, your site can be notified. Similarly, interactions elsewhere can sometimes be brought back to the original article.

Kev himself once described Webmentions rather neatly as comments that can “traverse the IndieWeb”. Which sounds exactly like the sort of thing I should like. Except that I don’t actually use Webmentions on Just Me.

Public means public, doesn’t it?

Kev’s initial reaction to the privacy argument was more or less: if somebody posts something publicly on Mastodon, it is already public. And there is clearly something to that argument. Mastodon isn’t a private messaging service. If I publicly reply to somebody, that message can already travel between servers because that is how federation works. People can link to it. Search engines may find public web pages. Someone can quote it in a blog post.

So why would displaying that same public reply underneath the blog post it discusses suddenly create a privacy problem? That seems a perfectly reasonable question. But then there is another way of looking at it.

I said it there

Imagine I walk into a pub and loudly tell a story to ten people. I clearly can’t claim that the story was private. Other people in the pub may hear it. Someone may even repeat it. But that doesn’t necessarily mean I expected someone to record what I said and put it on a noticeboard outside the supermarket.

Perhaps that distinction matters online as well. When I post a public comment on Mastodon, I am making a public statement. But I am also making that statement in a particular place and within a particular context. Does public therefore automatically mean public everywhere? I don’t know.

And that is exactly why I found the discussion around Kev’s post interesting. The comments and responses don’t simply turn this into a technical discussion about Webmentions. They lead to a much broader question about context, consent and what “public” actually means on the open web.

There is also an interesting cultural element here. Manton Reece, writing about similar questions around blogging and the Fediverse, points out that there is a culture on Mastodon in which posts can sometimes be treated as semi-protected within that environment, even though technically they are published on the open web. That distinction between what technology allows and what people expect is important.

Context is part of publishing

Perhaps location is part of the message. If I leave a comment underneath a blog post, I deliberately put my words underneath that particular article. If I reply to something on Mastodon, I deliberately put them into that conversation. Both may be publicly accessible. But they aren’t necessarily the same thing.

We have become accustomed to thinking about privacy as a binary choice: something is either private or public. The web has always been much messier than that. There is technically public. There is socially public. There is searchable. There is discoverable. There is likely to be seen by the people hanging around here. And there is copied automatically to another website where an entirely different group of people may encounter it. Those aren’t necessarily equivalent.

But isn’t this exactly what the open web is for?

Then again, we should be careful not to take this argument too far. The open web works precisely because things can be linked, quoted, referenced and discussed elsewhere. I regularly write about things other people have written. Bloggers have been doing that since blogging began.

In fact, that is one of the things I like most about the personal web. Someone writes something. Someone else responds on their own website. A third person joins in. Suddenly you have a conversation spread across several independent websites rather than locked inside Facebook, LinkedIn or some other corporate platform. Webmentions are, in a way, simply an attempt to connect those conversations. And that is a very attractive idea.

Interestingly, Kev himself has gone back and forth on Webmentions over the years. He once removed IndieWeb support partly because of its complexity and limited use, and later experimented with Webmentions again. He has also built his own ways of showing what other bloggers have said about his posts. Which perhaps tells us something. This isn’t a solved problem.

I don’t have an answer

I don’t use Webmentions myself. And although I read quite a few personal blogs, I hardly ever leave comments. So this isn’t a problem I urgently need to solve for Just Me. But I find the discussion fascinating because it touches on something much bigger than Webmentions. What exactly do we consent to when we publish something publicly?

If I put a comment on website A, have I implicitly agreed that website B can automatically reproduce it? My first reaction is probably: well, yes. You published it publicly. My second reaction is: hmm. But I published it there. And now I am no longer quite so sure. Which is usually a good indication that a discussion is worth having.

Personal Computing 2.0 a.k.a. Local First: Can We Please Have Our Data Back?

Something went slightly wrong with personal computing. Not all at once, of course. It happened gradually. We started with personal computers that were, well, personal. Our programs ran on them. Our documents were stored on them. Our photos were on our hard drives. And if we wanted to move something somewhere else, we copied it ourselves.

Then came the cloud. And the cloud was fantastic. No more worrying about which computer contained that particular document. No more carrying USB sticks around. Email, photos, documents, notes, calendars and eventually almost our entire digital lives became available everywhere.

There was just one rather important side effect: Our data moved away from us.

Somehow, our data became their data

Today, an enormous amount of personal information sits inside infrastructure operated by a surprisingly small number of very large technology companies. We created that information. We wrote the emails. We took the photographs. We made the documents. We entered the appointments. We built the contact lists. We generated the browsing histories.

Yet increasingly it feels as though these companies own the environment in which our digital lives exist, while we are merely being granted access to it. Sometimes for free, in exchange for data and attention. Sometimes through a subscription. Sometimes both. That is a rather strange arrangement when you think about it. And now AI makes the question even more interesting. Suddenly all those documents, emails, photographs, notes and other pieces of personal information are extremely useful as context for AI systems.

Personal Computing 2.0

So perhaps this is a good moment to reconsider the architecture. There are different names floating around for this idea. Some people talk about Personal Computing 2.0. Others prefer local first. Others simply talk about bringing personal computing back to where it started: with the individual. Although I often use the term “local first”, the terminology doesn’t matter much to me. The principle does: My data is mine.

That doesn’t necessarily mean everything has to sit on the SSD inside my laptop. That would be unnecessarily restrictive. My data could be on my laptop. It could live on an SSD connected to a small server somewhere in my home network. It could be on a NAS. Or it could even be stored at a hosting provider that I have deliberately selected.

The important difference is control. I decide where the data lives. I decide which software can access it. And I decide when somebody else gets access.

And then there is local AI

This is also one of the reasons why I am so interested in running open-source and open-weight AI models locally. AI makes local first much more interesting. Imagine an AI assistant that can search your documents, summarize your notes, analyse your personal archive or help you write something based on years of your own material — without uploading that entire digital history to somebody else’s cloud.

That is a fundamentally different model. And yes, I would happily pay for good local AI models.

In fact, there is an interesting parallel with my recent post about shareware. Let me download a model. Let me experiment with it. Let me see whether it actually helps me with the things I want to do. If it does, I’ll pay for it. That seems like a perfectly reasonable transaction. I pay for the software. The developer gets paid. And my data remains mine.

We need trusted hosting as well

There is one complication. Local first shouldn’t have to mean everything must be physically inside my house. There are perfectly good reasons for storing data elsewhere: backups, availability, collaboration and simply not wanting to maintain yet another little server.

But then I would like to know something about the company storing my data. Does it really leave my files alone? Is my information analysed? Can it be used for training? Who technically has access? What happens when authorities request data? What jurisdiction applies?

Perhaps what we need is some kind of genuinely useful certification for hosting providers that offer this kind of personal cloud. Not another logo created by a marketing department, but a clear and independently verified promise: we store your data, but we don’t use it. That could make local first much more practical for ordinary users.

Can we have our computers back?

I don’t want to get rid of the cloud. I don’t want to stop using AI. And I certainly don’t want to return to computing as it existed in 1995. Quite the opposite. I want better computers, better AI, better synchronization and better services.

The next big step in personal computing isn’t putting even more of our digital lives into a handful of gigantic clouds. It is about bringing control back to the edges: our laptops, our home servers, our chosen hosting providers, our local AI models. Call it Personal Computing 2.0. Call it local first. Call it whatever you like. I would simply call it my data.

The Personal Web Isn’t Dying; It’s Getting Older.

There is something slightly ironic about reading a blog post about the disappearance of personal websites (see here: https://widdershins.verja.net/the-old-personal-web-is-going-quiet/). Especially when you are reading it on a personal website.

But that is exactly what happened when I came across The Old Personal Web Is Going Quiet on Widdershins. The author asks an interesting question: are personal websites and blogs slowly disappearing as their owners get older, lose interest, move to social media or simply stop paying for their hosting?

There are some numbers to support at least part of that idea. Pew Research looked at web pages archived between 2013 and 2023 and found that about a quarter were no longer accessible by October 2023. The older the page, the greater the chance that it had disappeared. Of pages that existed in 2013, roughly 38 percent were gone ten years later.

Those are impressive numbers. But I am not entirely convinced they tell us very much about the state of the personal web.

A missing page is not necessarily a dead website

There is an important distinction here. These figures are about web pages in general. They include all kinds of pages, including pages on corporate websites, news sites and probably enormous numbers of URLs that were never intended to remain online forever.

Websites are redesigned. CMS systems change. Companies disappear. Products are discontinued. News sites reorganise their archives. URLs change. Pages without permanent links vanish. As the Widdershins article itself points out, most of the missing pages were actually from websites that were still online. A disappearing page therefore isn’t necessarily evidence of a disappearing website, let alone a disappearing personal blog.

The personal web feels surprisingly alive

My own impression is actually rather different. I spend quite a lot of time wandering around the less corporate corners of the web. And perhaps that gives me a distorted view, but the personal web seems remarkably lively to me.

There are blogs about programming, Linux, photography, books, retrocomputing, science, writing, electronics, personal knowledge management and dozens of subjects that are almost impossible to categorise.

Some people publish every day. Others write something once every three months. Some websites look as if they were designed last week. Others proudly look as if CSS was still considered an exciting new technology.

I like that. These sites aren’t optimised by a social-media algorithm. Nobody is desperately trying to keep you scrolling. Often there isn’t even an advertising banner. It is simply someone saying: I found this interesting, so I wrote something about it. That is pretty much my definition of the personal web.

But there may be an age problem

There is, however, one part of the Widdershins article that I find more worrying: age.

Pew found that in 2006 more than half of the bloggers it surveyed were younger than 30. Those people are now, of course, roughly twenty years older. Meanwhile, blogging among teenagers and young adults already declined sharply between 2006 and 2009 as social networks became more important. More importantly, there doesn’t appear to be much recent research telling us who is maintaining personal websites today.

So perhaps the problem isn’t that the personal web is dying. Perhaps the people maintaining it are simply getting older. And if that is true, we should probably spend less time worrying about whether blogs are disappearing and more time showing younger people how much fun having your own little corner of the internet can be. A place where you decide what to publish. Where you decide what it looks like. Where there is no algorithm deciding whether twelve people or twelve thousand people will see what you made. Where your old posts don’t disappear into an endless timeline after three days. And where you can experiment, write, draw, code, photograph or simply collect things that interest you.

So how do we tell them?

That brings us to the slightly bizarre part. If we want to convince teenagers and twenty-somethings to build personal websites instead of putting everything on giant social platforms, we probably have to go where they are. TikTok. Instagram. Snapchat.

Perhaps the best way to save the independent personal web is to make TikTok videos explaining why people should spend less time on TikTok. There is something wonderfully absurd about that. But it might just work.