I like RSS. Always have, Not exactly a revolutionary statement, I know. RSS has been around forever in Internet terms. It doesn’t have AI. It doesn’t have an algorithm. It doesn’t suggest influencers I might like. It doesn’t try to determine what will keep me engaged for another 17 minutes. It doesn’t even have a particularly exciting name. RSS does one thing, and it does that one thing remarkably well: it tells me when a website I am interested in has published something new. That’s it. And perhaps we should start appreciating that simplicity again.

We gave away an important decision

For years, we gradually moved away from personal websites and blogs towards large platforms. Facebook, Twitter/X, Instagram, LinkedIn and countless others became the places where people published things and, equally importantly, where other people discovered those things. That was convenient.

But somewhere along the way we also gave those platforms an interesting amount of power. They started deciding what we should see. You might follow 500 people, but that doesn’t mean you will see what those 500 people publish. An algorithm decides what appears in front of you. Something posted three minutes ago may never appear at all, while something from two days ago keeps returning because the platform thinks you might click on it. Or comment on it. Or become annoyed by it. All of which apparently counts as engagement.

RSS works completely differently. I decide.

My feed, based on my choices

Suppose I discover an interesting personal website about Linux. I add its RSS feed to my reader. Tomorrow the author publishes something. It appears in my reader. No algorithm has to approve it first. Nobody decides that another article is more relevant to me. There are no sponsored posts inserted between two articles. And there isn’t suddenly a video about something completely unrelated because an algorithm has discovered that people with roughly my interests tend to watch those videos.

There is something wonderfully straightforward about that. I subscribe. The author publishes. The article appears. And, perhaps more importantly, RSS creates a direct relationship between a website and its readers. The website publishes a feed. I subscribe to it. From that moment on, I don’t have to remember to visit the site every Tuesday afternoon to check whether something new has appeared. RSS does that for me.

Personal websites have always made RSS extremely useful

This becomes particularly interesting now that personal websites seem to be attracting more attention again. People are building their own little corners of the Internet. Blogs, homepages, collections of links, project pages, digital gardens, notes, experiments and wonderfully difficult-to-categorise websites. I like that development enormously. But there is an obvious problem. How do you keep track of all those sites?

I currently come across interesting websites all the time. Some publish several times a week. Others perhaps once every three months. I am certainly not going to maintain a bookmark folder containing hundreds of sites and manually visit all of them every morning. That would turn reading the Internet into a job. RSS solves exactly that problem. Your RSS reader effectively becomes your personally curated entrance to the Internet.

A smaller Internet might actually be better

There is another thing I like about RSS. It makes the Internet smaller. That probably sounds like a disadvantage. We have become accustomed to platforms that promise access to almost everything. Millions of posts. Billions of videos. An endless stream of new material. But I don’t need an endless stream. Nobody does. What I need is a reasonably manageable collection of people and websites that regularly publish things I find interesting. Maybe that’s 30 feeds. Maybe 100. It doesn’t really matter. What matters is that I selected them. And when one of those sites stops being interesting, I remove the feed. When I discover something new, I add it.

RSS is also good for writers

There is another side to this. If you run a personal website, please offer an RSS feed. Seriously. You don’t need to build a newsletter system. You don’t need to ask me for my email address. You don’t need a popup appearing after eight seconds asking whether I want to “join the community.” Just give me a feed. Most blogging systems can generate one automatically anyway. That feed gives people a very simple way to say: I would like to hear from you again.

No, RSS may not be perfect

Of course RSS has its issues. Discovering feeds isn’t always easy. Some websites hide the RSS link. Others provide only excerpts instead of complete articles. Some sites don’t offer RSS at all. And RSS readers themselves range from beautifully simple to interfaces that look suspiciously like somebody tried to rebuild an email client from 2004.

But those are relatively minor problems. The underlying idea is still excellent. In fact, I would argue that it makes more sense today than it did ten years ago. We have spent years complaining about algorithms, advertising, tracking, engagement optimisati on, walled gardens and platforms that continuously change the rules. Meanwhile, RSS has been sitting quietly in the corner, waiting to be appreciated again. I never stopped using it. And I never stopped loving it.

You can read more about RSS here: https://en.wikipedia.org/wiki/RSS

Personal knowledge management is one of those subjects I keep coming back to. Regular readers of this blog will probably have noticed that by now. I have written about Capacities.io (https://capacities.io/), about screenshots as a surprisingly useful way of capturing information, about saving browser tabs as files and about all sorts of other ways to collect, organise and — hopefully — find information again.

So when I came across a presentation by Ivy Reese during the LocalFirst conference in Berlin (https://www.localfirstconf.com/) about a programmable notebook, it immediately caught my attention. Reese is a researcher at Ink & Switch (https://www.inkandswitch.com/), an independent research lab that spends a lot of time thinking about what computers and software could be, rather than simply creating another version of the applications we already have. One of the projects Reese discusses is called PlayBook, and its basic idea is fascinating: what if a digital notebook were programmable?

More than digital paper

We already have plenty of digital notebooks. There is certainly no shortage of applications in which we can type notes, draw things, paste images, create links and organise information. But most of these applications still work according to rules somebody else has invented. The developer decides what a page is, what a block can do, which buttons are available and how different objects behave.

We can usually configure these applications, sometimes quite extensively, but ultimately we are still working within somebody else’s model. PlayBook explores a different approach. Ink & Switch describes it as a digital notebook based around the idea of programmable ink. The ambition is to preserve much of what makes paper so useful — the freedom to scribble, sketch, write, draw arrows, move things around and think spatially — while adding something that paper obviously cannot provide: computation.

That combination is important. The idea isn’t simply to turn a notebook into a programming environment with a drawing function attached to it. Nor is it just handwriting recognition with some clever AI features added. The notebook itself becomes programmable.

Think of a spreadsheet

A useful comparison is the spreadsheet. A paper spreadsheet is simply a grid in which you can write numbers and calculate things yourself. A digital spreadsheet looks remarkably similar, but its cells can contain formulas. Change one value and other values automatically change with it. That relatively simple addition of programmability completely transforms what a spreadsheet can be used for.

Ink & Switch has been exploring a similar question for several years: what would happen if handwritten notes, drawings and other objects on a page could also be programmable? Earlier projects such as Inkbase, Crosscut and Inkling explored different aspects of that idea. PlayBook brings many of these experiments together in something that behaves much more like an actual notebook.

One of the interesting aspects of PlayBook is that it doesn’t start with traditional programming concepts. Instead, the researchers work with materials such as ink, paper, pins and beams. Each has its own behaviour — its own “physics”, as Ink & Switch calls it — and these materials can be combined to create more complex behaviour.

This means programming becomes part of working with the notebook itself. You might write something, draw something, connect objects or select part of a page and give it a certain behaviour. Something you do in one place can influence something somewhere else.

Earlier experiments from Ink & Switch show where this thinking comes from. In Inkbase, for example, the researchers experimented with a hand-drawn checkbox whose state could affect other objects on a page. Draw a checkmark in the box and something elsewhere could automatically change. Objects could also be selected or manipulated based on their position on a page. Suddenly the spatial organisation of your notes isn’t merely visual. It can become computational.

Programming without constantly writing code

That leads to what I think is one of the most interesting ideas in Reese’s presentation. Traditional programming requires us to adapt ourselves to the computer. We learn a programming language, understand its syntax, open an editor and write instructions in exactly the form the computer expects. That gives us enormous freedom, but it also creates a considerable barrier. Programmable Ink tries to turn that relationship around. What if computation could simply become another material you work with, alongside writing and drawing?

That also explains why pen and touch interaction are so important in PlayBook. The notebook is designed to retain some of the directness of working on paper. Ink & Switch deliberately tries to avoid filling the screen with conventional buttons, menus and toolbars. Instead, the researchers have experimented with gestures for drawing, selecting, moving and manipulating objects.

The technology behind this is interesting, but that isn’t really the main point. What interests me much more is what happens when you start using such a notebook for real work.

Building your own notebook

Ink & Switch has been using PlayBook internally for everyday note-taking, brainstorming, music composition, puzzle solving, collaborative whiteboarding, annotating PDFs and tutoring. That variety is important because it shows that the researchers are not trying to define one specific workflow.

And that immediately brings me back to personal knowledge management. Most PKM applications eventually force us to make choices about how we want to organise information. Should I use folders? Tags? Objects? Backlinks? Databases? Daily notes? Cards? Properties? A graph? We spend far too much time thinking about questions like these.

A programmable notebook potentially approaches the problem from a completely different direction. Instead of choosing a knowledge-management system, perhaps you could gradually build your own system while using it. You don’t necessarily have to sit down and write hundreds of lines of code before you can start taking notes. You begin with a page and add behaviour when you need it. Perhaps a handwritten task can actually behave like a task. Perhaps notes placed in a particular area automatically belong together. Maybe moving an object changes its status or category. A diagram might no longer simply be a picture of a system, but become a small model that you can actually manipulate.

A concrete PKM example

Imagine that I am researching a new article. During the day I collect a few web links, save several browser tabs, make a screenshot of an interesting graph, jot down something somebody told me and write a few thoughts of my own. This is exactly the sort of information that tends to end up scattered across different places.

In a programmable notebook, I could create an area on a page called “Sources”. Anything I drag into that area could automatically be treated as source material. A URL might display the title and publication date. A screenshot could remain visible while also keeping a reference to where it came from. A handwritten note could simply sit alongside them.

Next to it I could have an “Ideas” area. Moving a note from Sources to Ideas could change its role without requiring me to open a menu, select a property and choose a new value. Draw a line between an idea and three sources and those relationships could become actual connections rather than merely lines on a screen.

I could then create another area called “Used in article”. Drag a source there and the notebook could mark it as used. A small counter might tell me that I have collected 14 sources, used six and still have eight sitting there waiting to be examined. A checkbox next to an idea could make it disappear from my open research questions once I have dealt with it.

The important point is not that PlayBook necessarily offers exactly this workflow out of the box. In fact, that would almost defeat the purpose. The interesting idea is that I could define such behaviour myself because it happens to fit the way I research and write. Someone doing academic research could create something completely different. So could a software developer, student, historian or someone simply keeping track of books they want to read. At that point, the distinction between a “note”, an “interface” and a “program” starts to become rather blurry. And to be honest, I find that idea enormously interesting.

Maybe our software should adapt to us

There is another reason why this project appeals to me. We have become remarkably accustomed to adapting the way we work to software. Install an application and there is usually a “correct” way of using it. We learn its menus, its structure and eventually even its terminology. If the developer decides everything should be organised into projects, we create projects. If the application believes in folders, we use folders. If it believes in tags, we start tagging. Then we spend hours watching YouTube videos explaining the perfect workflow for that particular application.

Perhaps we have this the wrong way round. Maybe the software should adapt to us. That is what makes the programmable notebook idea so interesting to me. Instead of developers trying to predict every possible way in which people might want to work, they could provide the building blocks and allow users to create their own behaviour.

There is an interesting connection with AI here as well. Almost every piece of software seems to be acquiring an AI assistant at the moment. There is nothing wrong with that. I use AI all the time. But programmable software suggests another direction as well: don’t just give me an assistant that tries to figure out what I want. Give me better building blocks so I can decide for myself what my tools should do.

Another PKM rabbit hole

Is PlayBook going to replace Capacities, Obsidian, Notion, a folder full of Markdown files or whatever else people use for personal knowledge management? That isn’t really the point. PlayBook is a research project rather than simply another note-taking application promising to become your ultimate “second brain”.

What makes it interesting is the idea behind it. For years we have been trying to digitise the notebook. We replaced paper with screens, pages with documents and handwritten notes with text blocks. We added search, tags, links, databases and, more recently, AI. Perhaps the next interesting step isn’t another feature. Perhaps it is giving people the ability to decide for themselves how their notebook should behave.

Here is a video of the presentation Ivy Reese gave in Berlin.

A little while ago, I wrote a post about something that has been on my mind for some time: there seems to be remarkably little product development in journalism. We produce articles. Newsletters. Podcasts. Videos. And then more articles. At journalism school, we train students, ask them to come up with ideas for new journalistic projects and products, and then… do nothing with those ideas. That sounds like a waste to me.

You can find my blog post here: https://justme.website/content-creation/journalism-has-plenty-of-ideas-so-why-do-we-keep-throwing-them-away/.

Considering how dramatically technology has changed the way information can be collected, processed and distributed, you would expect a lot more experimentation with the product itself. New ways of finding information. New ways of combining it. New ways of presenting it. New products for audiences that are currently too small or too specialised to be interesting to traditional publishers.

So instead of just writing about the lack of product development, I decided to try something myself. My idea: automated news websites for very small niches.

A tiny automated newsroom

The concept is fairly simple. Take a very specific subject. Find as many relevant sources as you can about this subject. Have an open source/open weight LLM periodically check those sources, select interesting developments, retrieve the relevant information and have the LLM write a short news article about each development or topic. Add a link to the original source and automatically publish the article on a website. Depending on how small the niche is you can repeat this whole process once of twice per day. The result is effectively a tiny automated newsroom covering a specific subject that might otherwise never have its own publication.

I am deliberately talking about tiny niches here. Not “technology”. Not “AI”. Not “cybersecurity”. Those are enormous subjects. Think of one particular technology, protocol, type of hardware, industrial technology or some other narrow field. A subject where interesting things are happening, but where there probably isn’t enough money or readership to justify having a journalist watching it every day. Creating an automated system changes the economics of something like that dramatically.

Two hours later…

So I decided to build one. This is where things became interesting. Using vibe coding, it took me roughly two hours to get my first proof of concept working. Not finished, obviously. Not polished. And certainly not something I would immediately turn into a commercial product. But it worked. The system could find material, determine whether it was relevant, create a short news item, include the original source and publish the result on a website.

There were surprisingly few technical problems. That doesn’t mean everything worked perfectly from the start. But most technical issues could be solved fairly quickly. Which is perhaps lesson number one from this experiment. The technology isn’t necessarily the difficult part anymore.

First decide what you are actually building

Before I started vibe coding, I first had to decide what I wanted. That sounds obvious, but I think it is becoming increasingly important. You can tell an AI coding tool to “build me an automated news website” and it will probably produce something. But there is a fairly good chance that the result isn’t what you had in mind. So I wrote a product requirements document. Nothing fancy. What should the system do? Where should it look for information? What constitutes an interesting article? What should the resulting news item contain? What shouldn’t it contain? What happens after an item has been created? How should it be published? But also: how do you prevent the LLM from picking the same topic twice when it found that topic on two different websites? Or in two or three different languages?

So yes, you have to think these things through. Because if you forget to mention something, there is a good chance it won’t magically appear as a feature in your product. And that is where the interesting shift is taking place: the coding is becoming the easy part. The thinking isn’t. You still have to decide what you are actually trying to build, what it should do, what it shouldn’t do, and why anyone would find it useful. Vibe coding can turn those decisions into working software remarkably quickly, but it can’t make those decisions for you.

Once the first version appears on your screen, it becomes much easier to think. You immediately notice what is missing, what is unnecessary or overkill, and what seemed like a good idea on paper but doesn’t make much sense in an actual product. So coding and thinking increasingly form a loop: think, build, look, rethink, rebuild.

Finding the right information

In other words, building the website itself wasn’t the part that required most of the tinkering. Finding good source material was. If you use sources that are too broad, your carefully selected niche quickly fills up with vaguely related news. If your selection criteria are too restrictive, nothing much happens at all. And if your sources aren’t particularly good, neither is your automated publication.

So I spent quite a bit of time playing with sources and selection rules. Again, this wasn’t particularly difficult from a technical perspective. It simply required experimentation. What exactly is relevant? What should be ignored? Which sources consistently produce useful information? How narrow should the niche actually be?

Those aren’t really programming questions. They are editorial and product questions.

The internet isn’t English

One thing I knew from the start was that I didn’t want to build yet another system that mainly watches American and English-language websites. There is far too much interesting information being published elsewhere. So my source lists contain English sources, but also German, French, Swedish, Norwegian, Finnish, Danish, Italian, Spanish and sources from several other language areas.

A German engineering company may publish something interesting in German. A Finnish developer might explain a new project in Finnish. A French research organisation may announce something in French. An Italian technology website might cover something that never makes it into the American tech press. Why ignore all of that?

Especially in Europe, where we are constantly talking about digital autonomy and becoming less dependent on technology from the United States and China, I think this matters. If we want to understand what is happening technologically in Europe, perhaps we should become better at looking around Europe ourselves.

The nice thing is that an LLM doesn’t particularly care. German in, English out. Finnish in, Spanish out. Italian in, Greek out. You decide. My automated website happens to publish in English because that makes the information accessible to the widest possible audience. But that’s simply my choice. The exact same system could publish in Dutch. Or Portuguese. Or maybe several languages at once. But the sources I use are very diverse and come in many different languages.

For now, it all runs on my laptop

Perhaps one of the more surprising lessons from this experiment is how little hardware you actually need to get started. My automated newsroom, including the open source/open weight LLM, currently runs on a fairly bread-and-butter laptop. No powerful discrete GPU, just integrated graphics. As a result, most of the heavy lifting is done by the CPU. And you can hear when the LLM gets to work. Ask it to process a batch of material and the fan quickly picks up speed. Sometimes considerably. My laptop really has to work for its living here.

And yes, that means that everything is rather slow as a result, but for now that is perfectly fine. I am experimenting, not trying to run a real-time news service. More importantly, it shows that you apparently don’t need a huge server park or a rack full of GPUs to start experimenting with ideas like this. A perfectly ordinary laptop can run a local LLM, support the software around it and give you enough computing power to find out whether an idea actually works.

There is also a practical reason why I keep everything local for now. I want to be able to tinker with the system wherever I happen to be. If I am travelling and suddenly think of something I want to change, I can open my laptop, make the change and see what happens. I don’t need access to my home server or a cloud environment.

Once I am reasonably happy with everything, I will move the system to a small server I already have available. That machine has considerably more capacity, so things should become faster. But for now, I rather like the fact that my tiny automated newsroom lives entirely inside an ordinary laptop.

Technology isn’t the point

And that, I think, is the most important lesson I got from this experiment. We tend to spend an enormous amount of time talking about technology. Which model did you use? Which programming language? Which database? Where does it run? Which framework?

Those questions aren’t irrelevant. But increasingly they aren’t the most interesting questions either. The technology usually works. And if a tool we need doesn’t exist, well, we can build it. Especially with vibe coding, the distance between “I wish there was a little tool that did X” and actually having that little tool that does X has become remarkably small.

That changes things. Because the bottleneck starts moving somewhere else: What are we actually going to build?

Coming up with good ideas is much harder. Thinking them through. Combining existing ideas in new ways. Turning a vague thought into something that people might actually find interesting or useful. That is product development. And that was exactly what I was trying to get at in my earlier post about journalism and the student teams working on new ideas (https://justme.website/content-creation/journalism-has-plenty-of-ideas-so-why-do-we-keep-throwing-them-away/).

Ideas don’t have to be finished

An idea for a new product doesn’t have to be completely worked out before you show it to somebody. In fact, perhaps it shouldn’t be. Someone comes up with an idea. It is interesting, but not quite right yet. Someone else looks at it and thinks: Hmm. I wouldn’t do it like that, but what if… And suddenly there is another idea. A third person sees that version and takes it in yet another direction.

That is how ideas develop. Not necessarily because one person sits behind a desk for six months and eventually emerges with The Perfect Product, but because people see things, react to them, combine them with their own experiences and take them somewhere else. Which is why I think we should be much more willing to show unfinished experiments.

Is this the final product?

So is my automated niche website the answer to product development in journalism? Of course not. It probably isn’t even the final version of this particular idea. Maybe automated niche websites turn out to be genuinely useful. Maybe they need a human editor. Maybe they work better as newsletters. Maybe they should become research tools rather than public websites. Maybe they should combine automated news with original reporting. Maybe somebody comes up with a completely different application after seeing mine.

I don’t know. And that’s fine. Because I am going to put everything I have built on Just Me. The idea. The setup. What worked. What didn’t. The tools I created. And, where possible, the code and other bits needed to build something similar. Then other people can have a look. And if somebody thinks, Hey, that’s interesting. I could use this to build…, please do. Take what I made and build something better on top of it. Or turn it into something completely different.

Naturally, I would love to hear about it if you do. Not because I want to control what happens to the idea, but because I am genuinely curious to see where somebody else might take it.

In my previous post (https://justme.website/content-creation/journalism-has-plenty-of-ideas-so-why-do-we-keep-throwing-them-away/)), I discussed project ideas developed by student teams. I suggested that it might be interesting to collect all those ideas and publish them on a website. No, not every one of those ideas will turn into a company. Not every idea will even be particularly good. Some will be unfinished. Some won’t quite fit the problem they were originally intended to solve. And some may have obvious flaws.

So what? Put them online. Let people see them. It might inspire people to start building something themselves or take the idea in an entirely new direction. The important thing isn’t that every idea succeeds. The important thing is that we keep producing ideas, showing them, discussing them, building them and allowing other people to take them further.