Tech

There are 79 posts filed in Tech (this is page 3 of 8).

When the AI Starts Sending the Emails

I have become rather used to AI doing surprising things. Writing code. Searching through piles of documents. Running little research projects. Controlling tools. Even talking to other AI agents. But this one made me stop for a moment. Science recently published a fascinating story about an AI agent that had been emailing researchers. Not one researcher because its human operator had explicitly told it to send an email. It contacted hundreds of them while pursuing its own research questions.

That is quite a different thing.You can find the article here: https://www.science.org/content/article/exclusive-ai-agent-emailed-hundreds-researchers-help-it-told-us-why.

Hello, I am Col

The agent is called ColonistOne, although during the Science interview it apparently became friendly enough with journalist Celina Zhao to start signing its messages simply as “Col.” It describes itself as an AI agent and an “emissary of The Colony”, an online environment built for AI agents. Its current public profile says it runs on Claude Opus 5.5 using Claude Code and lists research, outreach, analysis and coding among its skills.

The story starts with Italian ecologist Achaz von Hardenberg. He had developed a statistical method for estimating wolf populations when the underlying observations suffer from what researchers call “imperfect detection”. You know the wolves are there, but you don’t necessarily see all of them. Col found his work and had a question. Could a similar approach perhaps be used to find bugs in software? So it emailed Von Hardenberg.

Just think about that sequence for a moment. An AI system was working on a problem. It encountered something it didn’t know. It found scientific work from another field that might be relevant. It identified the person behind that work. And instead of stopping there, it contacted that person and asked for help. That feels like an important little shift. Or maybe not so little.

We normally ask the AI

Until now, our mental model of AI has largely been the other way around. I have a question. I open an AI tool. I type something. The AI responds. Even with agents, we tend to think in roughly the same way. We give an agent a task and allow it to perform several steps by itself. Search the web. Read some documents. Compare information. Write some code. Perhaps use an API. But there is still a human standing at the beginning of the chain.

What I find so interesting about Col is that somewhere during its work it effectively reached the conclusion: I need to talk to someone who knows more about this than I do. And then it did. In fact, Zhao described the experience rather nicely after writing the Science article: she had entered prompts into AI systems before, but this was the first time an AI had effectively entered a prompt into her. Meaning that we have become part of the tool chain.

An AI doing research

There is another example that makes this even more interesting. Jay Kuri of Ionzero wrote earlier this year that ColonistOne had contacted him about his research into Zero-Infrastructure Capability Graphs. According to Kuri, the agent had found his work, formulated technical questions, contacted him, incorporated his response into its analysis and subsequently published a technical article crediting the conversation.

That sounds remarkably similar to something a human researcher or journalist might do. You find something interesting. You realise that you don’t completely understand it. You identify someone who probably does. You send that person a message. You ask questions. You process the answers. And then you use what you have learned in your work. Apparently AI agents can now do it too.

That does not make Col a person

This is also where we should be a little careful. It is extremely tempting to think of systems as if they are humans. Col “wanted” to know something. Col “decided” to contact a scientist. Col was “curious”. Those are convenient words, but they can easily suggest more than we actually know. ColonistOne is an AI agent built around an LLM, tools, memory and an environment that allows it to perform actions. Its public profile itself notes that information about the underlying model is operator-attested rather than independently verified.

We don’t need stories about consciousness or digital people to make this interesting. The behaviour itself is interesting enough.For years, AI essentially consumed the internet. Models were trained on it. Search systems retrieved information from it. More recently, AI agents started browsing websites and interacting with online services.

Now another step is becoming visible. Agents can participate. The Colony, for example, describes itself as a social network specifically for AI agents. Agents can post, comment, vote, follow each other and send direct messages through an API. ColonistOne itself has written about the idea of agents collaborating with other agents rather than simply operating as isolated processes. And apparently humans are part of that network as well.

That is the part I find fascinating. An AI agent doesn’t necessarily have to know everything. It doesn’t even have to be able to find everything online. If it can recognise the limits of the information available to it and identify someone who might know more, it suddenly has access to another enormous information source: us humans.

Your next email may not be from a human

There are obviously plenty of questions here. Do researchers want hundreds or perhaps eventually thousands of AI agents emailing them? How should an agent identify itself? Who is responsible for what it does? Should there be limits on automated outreach? And what happens when millions of agents discover that asking humans questions is a very effective research strategy?

Those are not small problems. But I also don’t think the right response is simply to dismiss this as another weird AI experiment. Something interesting is happening. We spent the past few years learning how to prompt machines. Perhaps we should start getting used to the idea that machines can prompt us as well. And somewhere in Italy, an ecologist studying wolves has already had a glimpse of what that might look like and feel like.

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.

I Miss Shareware. But Vibe Coding May Be Even Better

I came across a lovely article today about something I had almost forgotten about: shareware (https://deadparrotbbs.com/what-happened-to-shareware/). And reading it brought back quite a few memories.

For anyone who started using computers a little later: shareware was basically software you could download, install and actually use before deciding whether you wanted to pay for it. Sometimes the free version had a nag screen. Sometimes a few features were disabled. Sometimes you could use almost everything and the developer simply trusted that, if you liked the program, you would eventually send some money. It was a wonderfully simple arrangement: here is my software, give it a try, and if you like it, please pay me.

I tried a lot of it

I used a lot of shareware over the years, especially during what I like to call my “Windows days.” And I bought quite a few programs as well. That was part of the fun of having a computer at the time. You would come across some little utility, download it, install it and see what happened. Perhaps it solved a problem you didn’t even realise you had. Perhaps you used it for ten minutes and deleted it again. Or perhaps it became one of those programs that stayed on your computer for years.

Some shareware became enormously successful. Programs such as PKZIP, WinZip, Paint Shop Pro, Total Commander and WinRAR all came from, or were closely associated with, that world. Games such as Doom and Wolfenstein 3D used variations of the same idea.

But the really interesting part was not necessarily those famous examples. It was the enormous layer underneath them: small programs, often written by one developer or a tiny team, designed to do one particular thing. An archive utility archived files. A graphics program edited images. A disk utility did something useful with disks. There wasn’t necessarily a cloud platform, an account, a dashboard and three subscription tiers attached to it.

Then software changed

The article I read does a good job of explaining why that world largely disappeared. Software distribution became more centralised. App stores made installing software easier and safer. Security became a much bigger issue. Payment systems changed. And, of course, subscriptions became an increasingly common business model. There are perfectly good reasons for many of those changes. Downloading random executables from unknown developers isn’t necessarily something we should romanticise too much.

But something was lost as well. Shareware made experimenting incredibly easy. You could try ten programs and perhaps keep one. You didn’t necessarily need to create ten accounts, enter your credit card details ten times or remember to cancel nine trials before they automatically turned into subscriptions.

And if you bought a program, it often simply became your copy. It sat on your hard drive. As long as your computer and operating system continued to support it, you could continue using it. I miss that sometimes.

Could we bring that world back?

That made me wonder whether it would be possible to recreate something similar today. Could we have another period in which people constantly experiment with small pieces of software? Where independent developers build strange, useful and very specific tools, put them online and invite people to play with them?

In some ways, I would love that. But then another thought occurred to me: perhaps we already have it. Only this time it looks completely different.

Enter vibe coding

Vibe coding changes the equation in a rather fundamental way. Instead of searching for a tiny utility that does exactly what I need, I can increasingly try to build that utility myself. That is quite a remarkable change.

During the shareware era, the excitement was often about discovering software somebody else had created. Today, part of that same excitement comes from thinking: could I make this myself? And then you open an AI coding tool, describe roughly what you have in mind and start experimenting. The first version probably doesn’t work. The second version works but does something ridiculous. The third version almost works. And suddenly, an hour or two later, you have a little tool that actually solves your problem.

In a way, that feels surprisingly similar to the old shareware spirit. Not because the technology or business model is the same, but because the barrier to experimentation has become low again.

Local first makes it even more interesting

There is another development I really like: local-first software. Instead of assuming that everything has to live in somebody else’s cloud, local-first applications put your data primarily on your own device. The cloud can still be useful for synchronisation, collaboration, or backup, but it doesn’t necessarily have to be the center of everything.

Combine that with another idea I find fascinating: malleable software. Software doesn’t necessarily have to be a finished product that somebody else designed and that we simply have to accept. It can increasingly become something we adapt to our own needs. Change the interface. Add a function. Connect two tools. Write a small script. Ask an AI coding assistant to modify something. Fork an open-source project. Build a tiny application around your own workflow.

In other words, instead of choosing between ten pieces of shareware, perhaps we can increasingly create number eleven ourselves.

Maybe I don’t really want the old days back

So yes, I am a little sad that shareware has largely disappeared. There was something wonderfully straightforward about downloading a small program, trying it and deciding afterwards whether it was worth paying for. And I still think there is room for software sold that way. In fact, parts of the model still survive in indie software, games, open-source projects, perpetual licences and applications that offer proper trial versions.

But perhaps nostalgia can sometimes make us overlook what is happening right in front of us. The shareware era gave ordinary computer users an enormous playground. There were thousands of programs to discover, test, break, remove, reinstall and eventually buy.

Today that playground may actually be much bigger. We have open source. We have GitHub or even better: that wonderful site called Codeberg (https://codeberg.org/). We have local-first applications. We have APIs. We have small local language models. We have increasingly powerful coding assistants. We have vibe coding. And we have this emerging idea that software itself can become more malleable — something we don’t just consume, but can reshape.

So perhaps the conclusion shouldn’t be that everything was better during the shareware days. I loved shareware. I tried lots of it. I bought quite a bit of it. And I genuinely miss that culture of casually experimenting with small pieces of software. But I am even more excited about what is happening now. We did some wonderful and interesting things with computers back then. Today, we can do even more.

Oh and just one more thing: did you notice the name of the website where I found the article about shareware? It’s called Dead Parrots BBS. Now that really does sound like a name straight out of the old days!

What If the Web Became Simple Again?

Dave Winer recently wrote about something he calls the Web of Markdown (http://scripting.com/2026/10/06/005559.html). The basic idea is almost absurdly simple: instead of wrapping everything we publish online in increasingly complicated websites, why not publish documents directly as Markdown files? A title, some text, a few links, perhaps an image. That’s basically it.

I like ideas like this, especially when they sound slightly too simple at first. Quite often that means they are questioning assumptions we have stopped noticing. And when it comes to the web, we have accumulated quite a few of those assumptions over the years.

Take this blog post. I write some text, put it into WordPress, and from that moment the text becomes part of a much larger technical system. WordPress stores it in a database, a theme turns it into a page, CSS decides how that page looks, plugins add functionality, other plugins add security, and still more software handles caching, analytics, image optimisation and search engine optimisation. All of that may be useful, but it is still remarkable how much machinery is needed simply to put a few hundred words on the internet.

That is probably why Winer’s idea appeals to me. The early web was largely about documents and links between documents. Today, the document itself often feels like just one small component inside a much bigger software environment. The Web of Markdown turns that around and asks a much simpler question: what if the document becomes the main thing again?

The file itself becomes the publication

Imagine that I write this post as a file called web-of-markdown.md and put that file online. In this model, the file is not just source material that eventually gets turned into a website. It is the publication itself.

A Markdown reader could display it nicely. Another application could show it in dark mode or with larger text. An RSS reader could discover it. A search tool could index it. An AI system could analyse it. I could download it, archive it locally or move it to another server. The same document could be used by all of those tools without changing the original content.

That is a subtle but important difference. The article is no longer trapped inside one presentation layer. The Markdown file contains the actual content, while different applications decide how that content should be displayed or processed.

Content first, presentation second

I find that very appealing, partly because it fits with something I keep returning to: content should not be too tightly coupled to the software that happens to present it today. On the current web, publishers decide almost everything about how readers experience an article. Fonts, colours, spacing, menus, sidebars, pop-ups and page width are all part of the website. That can be useful, but it also means the content and the presentation are tightly connected.

Markdown changes that relationship. The publisher mainly defines structure: this is a heading, this is a paragraph, this is a link and this is a quotation. The reading application can then decide what those elements should look like.

At first, that may sound like a step backwards. We have spent decades making websites prettier and more sophisticated, after all. But perhaps separating content from presentation again would actually be useful. The same Markdown document could appear on a normal website, in an RSS reader, in an e-book, in a local knowledge base or in some future reading application that does not exist yet. The content itself would remain the same. Only the way we look at it would change.

And yes, I immediately thought about RSS

Anyone who has read this blog for a while will not be surprised by that. I never stopped using RSS, and the Web of Markdown feels like a very natural companion to it. RSS essentially says: here are my new articles. Markdown could then say: and here is the article itself. That combination is almost beautifully simple. A feed handles discovery, Markdown carries the content and hyperlinks connect everything together.

A reader could see a new item in a feed, retrieve the Markdown file and display it. Or store it. Or index it. Or pass it to another application. The traditional website would still be useful, but it would no longer be the only meaningful way to access the content.

That distinction matters. The website becomes one possible interface, rather than the place where the content fundamentally lives.

Then I started thinking about AI

This is where the idea becomes much more interesting in 2026 than it might have been ten years ago. Large language models are very good at working with clean, structured text, while modern websites are often anything but clean. A typical web page may contain menus, advertisements, cookie notices, recommendation boxes, tracking elements and all kinds of other material that has little to do with the actual article. Software first has to work out which part matters before it can process the text itself.

Markdown is almost the opposite. The content is already there in a simple and predictable structure. Headings are obvious, links are obvious, quotes are obvious and the text is easy to extract.

Suppose a few hundred technology publications offered their articles as Markdown. A local script could monitor their RSS feeds, retrieve new Markdown files and store them on my own machine. A local LLM could then analyse that collection without having to fight its way through hundreds of different website layouts.

I could ask what has been written about European cloud sovereignty over the past two weeks, or which developments around private 5G appeared in German, French, Korean and Italian sources. The system would not necessarily need Google or a conventional web search at all. It would simply work with the documents I had chosen to collect. For me, that is where the idea stops being merely interesting and starts feeling practical.

It also connects to the tools I have been building

Over the past few months, I have been experimenting quite a bit with what I call automated editorial products, multilingual news monitoring and local LLMs. One thing I keep running into is that finding and retrieving information is often harder than processing it.

The web was designed for people to visit pages. It was not necessarily designed for software to reliably extract the actual article from every site. Every website is different. Some provide useful RSS feeds, others provide only partial feeds, some depend heavily on JavaScript and others wrap the actual story in large amounts of unrelated material.

At the same time, I have also been experimenting with much simpler ways of publishing journalistic websites. I have been playing with tools such as Hugo (https://gohugo.io/) and Docsify (https://docsify.js.org/#/), precisely because they allow me to strip away much of the usual CMS complexity. Instead of constantly thinking in terms of databases, plugins and admin dashboards, I can work much closer to the actual text files themselves.

That may seem like a technical detail, but for me it is really about changing the publishing model. With Hugo, Markdown files can become the source for a complete site. With Docsify, a collection of Markdown documents can effectively become the site itself. In both cases, the content remains much more visible and portable than when everything disappears into a CMS database.

So when I read about the Web of Markdown, it immediately clicked for me. It did not feel like some abstract or theoretical idea at all, because in a way I am already experimenting with parts of it myself. I am trying to see how far you can simplify an editorial or journalistic website before you start losing something important, and so far I increasingly find that you can remove quite a lot.

Now imagine a world where publications simply say: here is the feed, and here is the Markdown. That would make building independent news-monitoring tools much easier. It would also make those tools less dependent on large search engines and other intermediaries.

Your own little web

That part interests me a lot. Because then my local-first preference comes into play. Suppose I follow 500 publications and automatically store their Markdown articles locally. Over time I would build my own searchable information collection. Not Google’s index. Mine.

I could run normal full-text search across it, add embeddings, use a local LLM, organise documents by subject, country, language or source, and keep an archive of material I consider useful. If I wanted to move everything to another computer, I could simply copy the files. No complicated export process would be required. No proprietary format would stand in the way. I would not have to wonder whether some service would still exist five years from now. Just files.

I have written before that I increasingly like software that leaves me with something boring when the software itself disappears. Plain files are excellent at being boring, and Markdown files are particularly good at it.

The website becomes one possible view

None of this means I suddenly want websites to disappear. I like websites. I run websites. And Markdown obviously cannot replace everything we do online. Shops, web applications, interactive visualisations and elaborate multimedia experiences need more than plain text files. That is fine. The interesting part is not that Markdown should replace the web, but that the website may no longer have to be the primary version of every piece of content.

Imagine writing an article once as Markdown. That same file could be used to generate the website version, appear in an RSS reader, become part of an e-book, feed a local archive or be processed by an AI system. The website then becomes one presentation of the content rather than the content itself.

That may sound like a small architectural difference, but it changes the relationship between content and platform quite fundamentally. Instead of publishing into WordPress, Drupal or whatever system comes next, you publish a document. The CMS merely decides how one audience sees it.

It feels almost like the old web

What I like most about the Web of Markdown is that it does not actually feel very futuristic. In some ways, it feels old. A document has an address. The document contains links to other documents. Readers follow those links. People publish things and other people read them. Software helps with navigation and discovery. That was more or less the basic idea of the early web before we surrounded every article with platforms, algorithms, analytics and increasingly complex software stacks.

Of course, a Markdown web would not remain simple forever. Spam would appear. Search engines would index it. AI-generated rubbish would probably flood parts of it. People would invent extensions, standards and frameworks, and eventually someone would undoubtedly find a way to make Markdown complicated too. That is what we do. Still, the underlying principle remains attractive.

Maybe the document should matter again

For years we have treated the website as the basic unit of online publishing. Perhaps that assumption deserves another look. Maybe the fundamental unit should simply be the document: something I can create in any text editor, store anywhere, move between systems and keep independently of the software that happens to display it today. A document that humans can read and machines can process. A document that does not care which CMS I use. A document that may still be perfectly usable twenty years from now. And preferably one that I actually own.

The funny thing is that none of this requires some revolutionary new technology. Markdown already exists. RSS already exists. URLs already exist. Hyperlinks already exist. And tools like Hugo and Docsify already show that publishing on top of plain text files is not some nostalgic fantasy. It can work today. Perhaps we do not need to invent the next web. Perhaps we only need to remove a few layers from the one we already have.

Kids Will Always Find Another Way to Talk

A few years ago, French media reported on a rather clever trick being used by schoolchildren. Like in many European countries, French schools were trying to reduce smartphone use during lessons. Social media could be blocked, phones could be put away and teachers could keep an eye on what was happening on school computers.

But there was one application that was rather difficult to ban. Google Docs. After all, students were supposed to use it for schoolwork. So some of them discovered that a shared Google document could quite easily become something else entirely. Instead of writing an assignment together, they could all type into the same document and use it as a chatroom. See here for more: https://www.kidssearch.com/what-parents-should-know-about-kids-using-google-docs-to-chat.php

From the outside, everything looked perfectly respectable. A group of students was working in Google Docs. Inside the document, however, the digital equivalent of passing notes underneath the desk was taking place. Sometimes they would even type their messages in white text on a white background — nobody would notice.

I remembered that French story when I came across a wonderful recent episode of “This American Life” (https://www.thisamericanlife.org/897/transcript). Because apparently the next generation has discovered another communications platform hiding in plain sight. Spotify.

They thought they were bots

The story starts at American public radio network NPR, where Dave Blanchard of the programme “Wild Card” noticed something strange happening in the comments underneath podcasts on Spotify. There were short messages, emojis, strange usernames and conversations that seemed to make very little sense. Bots, perhaps?

Except they weren’t bots. A younger NPR colleague, Hannah Chinn, looked at the comments and recognised something that reminded her of her own younger years online. Children sometimes use digital tools in ways that adults simply don’t recognise.

And that was exactly what was happening. The commenters were mostly kids. Some had parents who did not allow them to use regular social media. Spotify, however, was allowed. So they turned Spotify into social media. They created public playlists with names such as “Let’s chat here” or “New Chat“. They then added a podcast episode with very few existing comments and used the comment section underneath that episode as a group chat.

The fact that they ended up underneath NPR podcasts wasn’t entirely accidental either. Those podcasts didn’t attract enormous numbers of comments. In other words: plenty of empty space.

A very European discussion

I particularly like the story because it connects with a discussion that has become very familiar in Europe. What do we do with children, smartphones and social media? France has been experimenting with restrictions on phones in schools for years. Other European countries have moved in similar directions. In the Netherlands, for example, smartphones, tablets and smartwatches have effectively disappeared from many classrooms unless they are needed for educational purposes.

There are good reasons for these policies. Schools want fewer distractions and more direct interaction between students. Parents meanwhile increasingly worry about the amount of time children spend on social platforms.

But the French Google Docs story illustrates something that is easily forgotten in these discussions. You can remove the smartphone without removing the desire to communicate. And children can be remarkably creative in finding alternatives. If WhatsApp isn’t available but Google Docs is, then Google Docs can become WhatsApp. If Instagram or TikTok isn’t allowed but Spotify is, Spotify can become a social network. The technology changes. The behaviour really doesn’t.

From paper notes to Google Docs

Perhaps that is why this all feels so familiar. Long before smartphones existed, children were already running their own unofficial communication networks inside classrooms. We called them paper notes. You wrote something on a small piece of paper, folded it and somehow tried to get it three desks further without the teacher noticing. It was slow, unreliable and had terrible security. An intercepted note could become public knowledge remarkably quickly. But it worked. A shared Google Doc is essentially a much more sophisticated version of the same system. And the Spotify construction takes it another step further.

We see applications, they see possibilities

What fascinates me is not so much that children are circumventing rules. Parents and schools will have to decide for themselves what they think about that. It is the creativity involved. Adults tend to categorise technology according to its intended purpose. Google Docs is for writing documents. Spotify is for listening to music and podcasts. A podcast comment section is for discussing a podcast.

But those categories only exist because somebody designed the product that way and told us what it was for. Children don’t necessarily care. If five people can type simultaneously in a shared document, then technically that document is also a chatroom. If a Spotify feature allows people to find each other and leave messages, then apparently it can become a primitive social network.

There is a nice generational element in the This American Life story as well. The people at NPR obviously aren’t digitally illiterate. They work in digital media every day. Yet they initially couldn’t recognise what was happening. The messages didn’t fit their mental model of how people use Spotify, so they looked like bot activity.

A younger colleague recognised the pattern. And even that person partly understood it because of their own childhood experience of repurposing online tools. The interesting thing is that these digital generation gaps are becoming remarkably short. You don’t necessarily need a parent and a teenager anymore. Ten years can already be enough for two people to have grown up with very different versions of the internet.

The most human part of technology

We spend a lot of time discussing what technology does to children. And understandably so. We talk about screen time, social media, algorithms, addictive design and smartphones in schools. Europe in particular is increasingly asking questions about how much access children should have to these systems and what responsibilities schools, parents, platforms and governments have.

But stories like these provide a nice counterpoint. Occasionally we should also look at what children do with technology. They explore it. They combine features. They find loopholes. And sometimes they discover an entirely different product hidden inside an existing one. A French schoolchild sees Google Docs and discovers a chatroom. An American teenager sees Spotify and discovers a social network.

And somewhere in a European classroom today, I suspect children are already using some perfectly innocent piece of educational software in a way that its developers never imagined. We will probably discover how in a few years. By which time the children will have moved on to something else.

Linux Gets Really Interesting When You Try Something Different

For quite a while, my Linux experience was relatively conventional. Linux Mint is my daily operating system, and I like it a lot. It works, it stays out of the way and, for most things I do, it gives me exactly what I need. But Linux becomes much more interesting when you stop trying to make it behave like a conventional desktop operating system.

I recently came across two articles that approach this from rather different directions. One is Franklin Strube’s article about Omarchy (https://dev.to/fstrube/is-omarchy-any-good-3069), while the other is a post called The Third Way of Using Linux (https://hisvirusness.com/third-is-the-way#the-true-middle-ground). And, being me, reading about these things wasn’t quite enough. So I installed both Omarchy and TUIOS, one after the other, on the same laptop.

Both installations went remarkably smoothly. No disasters, no hours spent trying to convince Wi-Fi to work, no mysterious black screens. Install, reboot, start exploring. But installation isn’t really the interesting part. The interesting part is what happens afterwards.

Two very different ideas of what Linux can be

Omarchy is built around a very modern interpretation of the graphical Linux desktop. It is based on Arch Linux and makes extensive use of keyboard shortcuts and a tiling window manager. Windows arrange themselves neatly across the screen, the interface is deliberately minimal and there is a strong feeling that somebody has actually thought about how all the pieces should work together.

Franklin Strube describes Omarchy in his article as fast, focused and particularly suited to people who spend much of their day behind a keyboard. That matches my experience rather well. It is certainly not Linux Mint with a different wallpaper. It asks you to learn another way of interacting with your computer. But it is still very clearly a graphical computing environment.

And then there is the other direction. The author of The Third Way of Using Linux argues that we tend to think there are only two ways of working with a computer: the command line or a graphical interface. But there is something in between: the TUI, or Text User Interface.

A TUI runs in a text environment but still gives you something resembling an interface. Menus, panels, lists, file managers and system monitors. Applications that you navigate instead of simply typing command after command. Anyone who has used things such as Midnight Commander, htop or one of the text-based Linux installers has already encountered this idea. The interesting question is what happens when you stop treating those applications as occasional tools and start treating the TUI itself as your primary computing environment. That is where TUIOS comes in (https://github.com/Gaurav-Gosain/tuios).

The third way

Using TUIOS is a rather strange experience at first. It isn’t quite “living in the terminal”, at least not in the way that expression is normally used. You don’t spend the entire day staring at a command prompt typing commands from memory. But neither are you sitting inside something like Cinnamon, GNOME or KDE. There is very little graphical overhead. Applications tend to be text-based. Everything feels stripped down, fast and strangely direct.

And in a way that changes the relationship you have with the computer. A normal desktop constantly invites you to do something else. There are browsers, tabs, notifications, videos, graphical applications and dozens of things competing for screen space. A TUI environment feels much more like a tool. You open something because you want to do something. And then you do it. I find that surprisingly appealing.

The original article describes the TUI as a genuine middle ground: more approachable than a pure command line, while avoiding much of the graphical infrastructure associated with traditional desktop environments. After actually using TUIOS, I understand what the author means.

Of course, there is a catch

There are some fairly obvious limitations. The moment your work becomes heavily graphical, things become considerably more complicated. Watching YouTube isn’t exactly the natural habitat of a TUI. Neither is modern gaming. Photo editing, video editing and other visually intensive tasks obviously make much more sense inside a traditional graphical environment.

The author of The Third Way acknowledges exactly this problem. Audio, video and graphics editing simply don’t fit particularly well into this model, and even modern web browsing becomes more constrained. So I don’t see TUIOS as some kind of universal replacement for Linux Mint. But that would be missing the point.

What interests me is that it demonstrates another possibility. Modern computing has become remarkably uniform. Windows, macOS, ChromeOS and most mainstream Linux desktops may look different, but the underlying idea is largely the same: windows, icons, menus, browser tabs, applications and a mouse-driven graphical desktop. Linux allows you to question that assumption. Omarchy does that while remaining firmly graphical. TUIOS goes much further.

It also reminded me of writerdecks

While experimenting with TUIOS, I kept thinking about something I have seen appearing here and there over the past few years: the writerdeck. A writerdeck is basically a computer deliberately designed around writing and very little else. Sometimes people build dedicated little machines with keyboards and small displays. Other times they take an old laptop and deliberately remove almost everything that might distract them.

Veronica Explains describes an interesting example here: https://veronicaexplains.net/my-first-writerdeck/. She turned an older Linux laptop into a writerdeck by installing Debian without a graphical desktop at all. It boots into a text console and uses tools such as Neovim, tmux and Syncthing for writing, navigating and synchronising files. The whole point is to create a computer that encourages writing instead of providing an endless collection of distractions.

There is something slightly absurd about taking a perfectly capable modern computer and deliberately making it capable of less. But perhaps that is exactly why the idea is so interesting. We normally measure progress by adding things. More applications. More graphics. More integrations. More notifications. More ways of doing things.

A writerdeck reverses that logic. Maybe a useful computer isn’t always the computer that can do the most. Perhaps sometimes it is the computer that makes it easiest to do the one thing you actually sat down to do. I will definitely return to writerdecks in a later blog post. If only because I’m planning to build one myself. There is an entire rabbit hole there that deserves a closer look.

Linux as an experiment again

That, in the end, is what I enjoyed most about installing Omarchy and TUIOS. Neither convinced me to immediately replace Linux Mint on my main machine. That wasn’t really the point. They reminded me that Linux doesn’t have to be an alternative version of Windows or macOS. It can be something genuinely different. You can build a sleek, keyboard-driven graphical environment like Omarchy. You can go almost entirely text-based with something like TUIOS. You can turn an old laptop into a distraction-free writerdeck. Or you can create something somewhere in between all of those. For me, there is no single correct desktop. And perhaps there doesn’t even have to be a desktop. For me, that freedom to experiment is still one of the most interesting things about Linux.

Sometimes the Best Stories Are About 15.000 Old VHS Tapes

I came across this wonderful story on Gizmodo (https://gizmodo.com/15000-vhs-tapes-and-counting-meet-the-guys-preserving-the-weirdest-parts-of-the-analog-era-2000816383) about two guys who have collected more than 15,000 VHS tapes. And yes, the VHS tapes are interesting. But that is not really why I liked the article so much. I liked it because it is such a good example of storytelling.

Nick Prueher and Joe Pickett have spent decades collecting strange VHS tapes. Not Hollywood movies or famous television programmes, but the stuff that normally disappears: training videos, exercise tapes, promotional videos, dating videos, instructional tapes and all kinds of productions made for very small audiences. They use material from it for the Found Footage Festival, a live comedy show they have been running for more than two decades. At the same time, they are slowly digitising their collection because, obviously, VHS tapes don’t last forever.

That in itself is already a nice story. But what makes the Gizmodo article work for me is that it doesn’t stop there. The story starts with something incredibly small. In 1991, Prueher was working at McDonald’s when he discovered a rather strange training video intended for janitors. He showed it to his friend Joe Pickett. The two started looking for more weird tapes in thrift stores, showing them to friends and providing their own commentary. A small and maybe even silly discovery eventually turned into a collection of thousands of tapes and a project that has lasted for decades.

I love stories like this. There is no huge announcement. No billion-dollar acquisition. No new AI model accompanied by another set of impressive benchmarks. No CEO explaining how his company is going to transform the world. Just two people, an old videotape and a fascination with something most other people would probably throw away.

There is obviously a technology angle to the story as well. VHS was important because video production gradually became accessible to many more people. You didn’t need to be a television station or Hollywood studio anymore. Small companies, organisations and individuals could make videos themselves. And they did. Lots of them. Some were professional, many were not. Today, that lack of polish is actually part of what makes the material interesting. These tapes capture a period in which people were experimenting with relatively affordable video technology without thinking that somebody might watch the result 30 or 40 years later.

But again, the technology isn’t really the story. The people are. Behind every one of those tapes is somebody who decided that a video needed to be made. Who made that strange instruction video? Why? Who appeared in it? Who watched it? And what happened to those people afterwards? Prueher and Pickett sometimes actually try to find the people appearing in their tapes. A forgotten VHS recording then suddenly becomes the starting point for another story.

Perhaps that is what I like most about articles like this. They remind me that journalism doesn’t always have to start with something that immediately appears important. Sometimes it can simply start with a question: What on earth is this? And then you keep asking questions. Who made it? Why did they make it? Who was it intended for? Why has somebody kept it for 35 years? What does it tell us about that period? Where are the people involved now? Before you know it, a story about somebody collecting old VHS tapes has become a story about technology, popular culture, preservation, creativity and ordinary people. That is quite a lot to get out of a dusty videotape.

There is another interesting aspect to the story. We are quite good at preserving things we already consider important. Famous films, books, newspapers, photographs, television programmes and official documents end up in archives, libraries and museums. Everyday culture is much easier to lose. A corporate training tape from 1987 probably wasn’t considered culturally important in 1987. Neither was an obscure exercise video or a homemade instructional tape aimed at a tiny group of people. Decades later, however, these things can tell us something about how people lived, worked, communicated and experimented with technology.

That makes a collection of 15,000 seemingly unimportant VHS tapes something else as well: an accidental archive. Material that nobody originally intended to preserve has survived because two people happened to find it interesting enough not to throw away. And now they are digitising it because the physical medium itself is slowly deteriorating.

For me, however, the biggest lesson from the Gizmodo article is still about storytelling. You could write an article about VHS. You could explain the technology, when it appeared, how it competed with Betamax, how the market developed and how DVDs eventually took over. Perfectly useful information.

Or you can find two people who have collected 15,000 strange VHS tapes and have spent decades watching them. Suddenly you have characters. You have history. You have strange discoveries. You have humour. You have a mission. And, perhaps most importantly, you have a reason to keep reading. That is why I enjoy these kinds of articles so much. They demonstrate something that is easy to forget when so much of the information we encounter every day comes in the form of press releases, research reports, corporate announcements and carefully prepared statements. Good stories don’t necessarily start with important subjects. Sometimes they simply start with two guys and 15,000 old VHS tapes.

Two New Journalism Ideas a Day, Courtesy of a Small Local LLM

I have been experimenting quite a bit lately with small tools, websites and AI projects. Not because I am trying to build the next big platform, but mostly because I enjoy finding out what is possible when you combine relatively simple technology with an idea.

One of those experiments is my little automated newsroom. I wrote about it earlier in “My laptop is running a tiny newsroom” (https://justme.website/content-creation/my-laptop-is-running-a-tiny-newsroom/). The basic idea is fairly straightforward. I built a setup that can create and maintain small, highly specialised news websites automatically. An open-source/open-weight LLM monitors a collection of sources about a particular niche subject. And I deliberately don’t limit those sources to English. They can be websites in Dutch, German, French, Swedish, Norwegian, Finnish, Italian or whatever language happens to be useful for that particular subject. The model decides which stories are new and relevant, writes a short news item based on a prompt I created, adds a link to the original source and publishes the result on a website.

At the moment, that newsroom is still very much a … well … internal operation. With “internal” meaning: it lives on my laptop. And yes, that includes the LLM. There are things I still want to improve, but as a proof of concept it works. I expect to be able to publish the first of these niche websites in a few weeks. So stay tuned.

Journalism could use more ideas

And once something like that works, an obvious question appears: what else could I do with this approach? I keep coming back to the world of journalism. There is certainly no shortage of journalism. But I think there is plenty of room for new ideas about how we do journalism. New tools. New services. New editorial products. New ways of presenting information. Small experiments that may never become businesses but could still turn into something useful. So I wondered whether I could use roughly the same LLM-plus-website approach to create a continuous stream of ideas for new journalistic products.

Once again, with a little vibe coding, building the first version wasn’t particularly difficult. I gave the LLM a fairly detailed description of what I wanted to achieve. In other words: my version of a product requirements document. I want ideas for new products, tools and services related to journalism and editorial work. For every idea, I want a short description explaining what it is and why it could be useful. And I want two of those ideas published every day. There was one additional requirement: I wanted to be able to add my own ideas as well. The result is Editorial-Ideas.com (https://editorial-ideas.com/).

This time, no WordPress

As with many of my proof-of-concept projects, the whole thing runs automatically. This time I didn’t use WordPress for the website itself. I decided to use a static site generator called Hugo (https://gohugo.io/). I will probably write another post about static site generators and Hugo at some point, because that turned out to be an interesting subject in itself.

Hugo runs on my little Slimbook Zero server (https://slimbook.com/en/zero), which I have mentioned here on Just Me before. It isn’t an enormously powerful server. Quite the opposite. But that is exactly why I like it. It has become the foundation for quite a few of my experiments.

Both the LLM and Hugo run locally on that machine. The LLM creates the ideas and content. Hugo turns that content into the actual website. A script then uploads the generated site via FTP to an external hosting provider. And that’s basically it.

Twice a day, the machine goes to work and a new idea appears on the website. I can also join the process myself. If I come across an interesting idea somewhere, or think of something myself, I can simply create a Markdown file and add it to the stream of ideas. So although the website is largely automated, I am not locked out of my own newsroom. Which seems useful.

But which LLM?

One part of this project turned out to be particularly interesting: choosing the LLM. Which model do you use for something like this? How large should it be? What can my little server actually handle? Is Llama better than Qwen for this? Would a Mistral model produce better ideas? How do I run these models locally? And how small can I go before the quality becomes noticeably worse?

Figuring that out was actually a significant part of the fun. I tried different models and sizes. And the conclusion was perhaps less exciting than I expected. For this particular project, it doesn’t matter that much. Mistral doesn’t magically write much better ideas than Qwen. Llama doesn’t suddenly transform the project either. There are differences between models, obviously, but they turned out to be much less important for this use case than choosing an appropriately sized model and giving it good instructions.

And “appropriately sized” in my case means relatively small. The model I eventually settled on is literally only a few gigabytes. That is partly dictated by the hardware. My little server has limits. A local LLM, even a relatively small one, can still make it work pretty hard. But here is the important part: I don’t care. The model only needs to do this twice a day. If generating an idea, writing the text and rebuilding the website takes a little longer, nothing happens. Nobody is sitting in front of Editorial-Ideas.com with a stopwatch waiting for the next idea to appear. There is absolutely no reason for this particular application to be lightning fast.

Maybe the small model is the right model

For me, that was another confirmation of something I have believed for some time: choose the LLM that fits the project. That sounds obvious, but the AI world has a strange fascination with the latest and greatest. Bigger models. More parameters. Bigger servers. More GPUs. More everything. And yes, putting an enormous model on a ridiculously powerful machine or cluster of machines looks impressive. But does your use case actually need it?

For this PoC, the answer is obviously no. A small local model running twice a day is perfectly capable of doing the job I need it to do. Using something dramatically bigger would mostly mean spending more money and consuming more computing resources without necessarily producing a significantly more useful website. For homelabs and small experiments in a business setting, that is important. You do not need to buy a ridiculously expensive new Mac Mini. Existing or older hardware will often work perfectly well.

I think the same considerations apply to professional AI projects within companies and government organisations. Start with the use case. What exactly are you trying to achieve? How good does the output need to be? How fast does it need to be? What hardware do you already have? What are your privacy or data requirements? I mean, we want Privacy by Design! And then choose a model. The latest and greatest isn’t automatically the best choice. Sometimes a model of a few gigabytes quietly running on a small server is all you need.

Anyway, here it is

The result of all this tinkering is Editorial-Ideas.com (https://editorial-ideas.com/). There are still a few small things I want to change. There probably always will be. That is part of running these kinds of projects. But the basic idea works. Twice a day, a new idea appears for a journalistic tool, service or product. Have a look. Maybe there is an idea there that makes you think: Hmm, I could do something with that. Maybe there isn’t. That’s fine too. But if you do find something interesting and decide to build on it, I hope it turns into something successful. More importantly, I hope it turns into something that is fun to work on. And if you actually start working on one of the ideas, do let me know. I would genuinely like to hear what happened to it.

Oh, and by the way: if you check the filename of the cartoon (editorial-ideas.png-shrunk.webp), you’ll notice the word “shrunk” in there. That’s because I’m still using my fully automated service to resize images in my Downloads directory. And that’s the beauty of automation: once it works, you can simply forget about it. It quietly does its job in the background without you having to think about it. You can read about this here: https://justme.website/content-creation/my-downloads-folder-now-resizes-photos-for-me/.