Two Waves and a Dot

RSS has a business problem, not a technical one

Tue, 08 Sep 2026 06:35:03 GMT

I believe RSS syndication has a fundamental problem that limits its adoption. It's not anything technical — not the format, not the readers. It's the content: it is very hard to make a living by publishing full content via RSS.

How the web pays for content today

Most professional journalism today either sits behind a paywall or is plastered with ads, popups, and whatever else is needed to squeeze a penny or two out of a non-paying visitor. Both approaches are annoying. Beyond the financial aspect, nobody enjoys managing subscriptions to a dozen paywalled websites. And there is probably no person in the world who isn't annoyed by aggressive online ads.

Reading in 2026... taken from businessinsider.com, August 2026

After 30 years of news on the internet, there is still no common solution that pays the authors of a website without being a hassle for the reader.

This situation is unique to short-form reading. Music is easy to obtain, as long as you pay a monthly fee to Spotify or one of its many competitors. Musicians may complain that the income is thin, but it's enough to sustain a steady flow of new content from practically every artist. Short videos are distributed on YouTube, Facebook, and TikTok, and creators get paid - either viewers watch ads, or they subscribe to something like YouTube Premium.

What makes music and video easier to monetize than websites is, of course, the gatekeeper. YouTube only lets you watch a video if you either pay for Premium or sit through YouTube's ads. There is no equivalent gatekeeper for websites. In many ways it's a good thing that Chrome doesn't show us an ad before we can follow a link. But it also means that only the site itself can generate revenue, and in practice it does so in the most annoying ways imaginable.

Where that leaves RSS

RSS is already an awesome way to read content the reader doesn't pay for. In an ideal world, you could read your newspaper, the NYT or whatever you prefer, in the RSS reader of your choice instead of going to their website or app. Unfortunately, that's not possible. Not for technical reasons, but because there is no viable business model for it today.

That doesn't mean RSS is useless. It's great for personal blogs - if that's all you want to read, you can find more blogs than you could ever read. It also works well for product and company blogs like the Google Blog, where the article isn't the product but a way to sell you the actual product. Podcast feeds are similar: the feed is free and delivers an audio file that may contain ads and sponsorships that are hard to skip.

Only journalism and similar content - where the article is the product - has no solid way of making revenue from an RSS feed. The most common workaround is truncated content, often just a headline and a single sentence. Enough to decide whether you want to read the article, but to actually read it, you have to leave your RSS reader and open the site's app or website:

One sentence summary in the New York Times

Some sites offer paid, ad-free subscriptions that include a full RSS feed. This is a wonderful way to read your news, but it's mostly limited to a handful of tech sites. The Verge and Ars Technica are two of them. It can be a good solution for the sites you read most, but it's inconvenient: a "secret" URL that has to be copied into your reader, and one more subscription to manage, per site.

What RSS actually needs

What RSS needs is a way for authors to get paid while readers enjoy the full article inside their feed. Ideally something like the YouTube model: read articles with ads for free, or pay for an ad-free subscription. Publishers would get either a fixed amount per article delivered, or a share of a subscriber's fee proportional to how many of that subscriber's articles they provided.

The big question is how to get there, given how fragmented the RSS reader market is.

The Spotify model - every reader negotiating paid full feeds - is unrealistic for a million reasons: tiny teams, solo devs, non-commercial projects, or simply no interest. The YouTube model - a single dominant player offering it exclusively - doesn't work either, because no single reader has enough users to get publishers interested. And ad-supported feeds can't work in open-source readers, since the ads are trivially stripped out - though open-source users could still use paid full feeds.

A reselling portal

I think the logical model is a reselling portal. It negotiates contracts with publishers and obtains full feeds. Readers of any app, however small or independent, subscribe directly to the portal and get access to the full feeds via secret, per-user URLs, conveniently importable via OPML. And RSS readers that integrate with the portal directly could offer both seamless access to the paid feeds and ad-supported free viewing.

One subscription, every reader, full articles. That's the missing piece.

What is RSS Chat - and what not?

Fri, 28 Aug 2026 13:14:35 GMT

You may have heard about Dave Winer's rss.chat, a social network designed to find out whether RSS 2.0 "can be used as the backbone of a real social network".

This is what it looks like when you visit https://rss.chat:

The whole thing confused me initially, and if you have heard about it, maybe it confused you, too. So I spent some time investigating what it is, what it isn't, and - for me - whether it is worthwhile to integrate support for it into my RSS reader.

The first thing to understand is that rss.chat can mean one of three things:

A set of extensions to RSS that make it more useful for reading posts and comments on the social network, along with several conventions on how to use them, which feeds to publish and where.
The rss.chat server and client code, hosted on GitHub and written in JavaScript, consisting of a server and an HTML-based client.
The actual website that runs this application at https://rss.chat/ (.chat is an actual top-level domain).

The RSS extensions

rss.chat uses RSS for three things:

the posts of a user, exposed at https://<server>/users/<screenname>/rss.xml
the combined posts of all users, at the path /users/rss.xml
the comments users wrote to a post, which is linked from the feed above

In some ways, this is similar to the RSS feeds other social networks have exposed, especially Reddit.

If you look at a Reddit RSS feed, the links to the author, the comments, and the post itself are part of the post's HTML:

rss.chat instead uses RSS extensions from Dave Winer's source namespace to add this information as machine-readable elements: source:comments links a post to the feed of its replies (including a reply count), source:inReplyTo links a reply back to its parent, and source:markdown carries the author's original Markdown next to the rendered HTML.

This allows RSS-consuming apps to improve how they render posts and comments, and to navigate from posts to comments and back:

But this is where the use of RSS ends: it provides a standardized way for applications to read a social network's posts. You cannot interact with them via RSS, and RSS is not the storage format or anything like that. This is what confused me initially, as I expected a bit more after reading the word "backbone".

Side note: using RSS as a storage format would actually be possible. The blog you are reading right now runs on custom blogging software built on JSON Feed as its backbone. Posts are stored as single-post JSON Feed files. Publishing the JSON Feed means combining them into one. Publishing HTML or the RSS feed is done by formatting the JSON Feed objects with Jinja templates. It may not scale to millions of posts, but it works fine for a single blog.

How rss.chat uses OPML

rss.chat uses OPML to expose a subscription list: one file listing the feeds of all users on a server, available at the conventional address /data/subs.opml and also through the server's API. You can hand it to any feed reader to follow the whole community at once. There is no per-user follow list on the server: who you follow lives in your feed reader, not in rss.chat. And there is no standard yet for modifying these lists remotely.

Limits of the Open Protocols

All the open rss.chat components are read-only. You can read posts and comments, but you cannot create posts or comments using open protocols. That requires the rather proprietary API of the current rss.chat implementation.

Furthermore, rss.chat is intended for small servers, each serving one community. But currently these servers cannot interact: a reply written on one server never reaches the thread on another. I could imagine rss.chat being used as an open Reddit alternative, with each server being the equivalent of a subreddit. But the limit of that model is the lack of interoperability. Users would need a separate profile on each server, each with a possibly different username and without a common reputation system. Depending on how you see it, this is either a massive gap or at least a limitation that makes it unviable as a replacement for one of the major social networks.

The rss.chat server and client code

The rss.chat software is an open-source implementation of the rss.chat conventions, including support for WebSub and rssCloud for near-real-time notification of feed changes. It also implements its own API for everything the open formats do not cover, like publishing posts, likes, and reading whole threads in one call.

The server is remarkably small for what it does: a single file of about 2,600 lines of JavaScript. The client is of similar size, plain JavaScript using jQuery and Bootstrap.

The rss.chat site

And finally, http://rss.chat/ is a website running the rss.chat code. Using its web interface, you can read and write posts after logging in. Third-party software can access posts and comments using RSS. Micro.blog already loads rss.chat conversations by following the comment feeds. It is an actual social network, albeit a small and simple one, proving that the rss.chat format generally works.

Who will use it?

I think the biggest question is whether rss.chat just stays a proof of concept, and its usage remains limited to an experimental server with fewer than 100 active users. Or whether it will be used at a larger scale.

Support from the existing commercial social networking giants like Reddit, LinkedIn, and Facebook is unrealistic at this point, as these companies are currently tightening access to their services to prevent AI companies from training on their data.

There may be an opportunity to create open and independent equivalents to Reddit subreddits and Facebook groups using the rss.chat software. For that, the software would need a lot of work to protect it from bots and spam, and to provide legal compliance for things like the GDPR and DMCA safe harbor. In its current form, operating a larger rss.chat server would be a legal risk. There is also competition from more traditional forum systems like myBB, though you could argue that rss.chat's style is more modern. It is definitely a better fit for small, low-frequency communities: forums with many empty boards are rather depressing.

In my opinion, the RSS extensions for comments are the part most likely to be adopted. It just takes one common CMS or blogging system to adopt them for comments, and many RSS reader applications would be motivated to support them.

Using for blog comments

Right now there are three established RSS extensions for comments, and all are very limited:

Slash which can be used to display a comment count. It was originally created for the weblog pioneer Slashdot.org, but has since been adopted by other sites.
The Comment API, which allows linking to an RSS document containing the comments. It does not define what that document should look like, and only allows flat comments. Curiously, it also has a way of submitting comments, but it lacks any spam protection, which makes that part quite useless these days.
Media RSS, which allows a list of plain-text comments, but without any hierarchy, author names, or anything else that would make it actually usable. I am not aware of any site using media:comments.

The Slash and Comments API in action, on the steelersdepot.com RSS feed

The first two are more widespread than you might think: WordPress feeds carry slash:comments and the Comment API's wfw:commentRss element by default. The source comment extensions used in rss.chat cover the same ground more coherently - one element that carries both the count and the link to the comments feed, plus threading via source:inReplyTo - and could be a good replacement for all three.

Conclusion

So what does rss.chat provide? An interoperable way to give RSS readers and other applications read access to a social network with the common feeds/posts/comments structure. It is not foreseeable that it will be adopted by any major social network, even though technically it could.

And a working implementation of this system with a small community using it, which at the moment is closer to a proof of concept than to an actual social network.

CSS Filtering for RSS Readers

Fri, 21 Aug 2026 13:14:26 GMT

I have come across this article about CSS-related vulnerabilities in email clients. It's quite shocking what you can do with CSS if you render arbitrary CSS from a third party. RSS readers have challenges similar to email clients: they both embed HTML from untrusted third parties. Not all readers support CSS though. Some go the easy route and just filter it out. Inoreader is a popular reader with CSS support, while Feedly does not support it. My project Downread supports CSS, so this is something that concerns me as well.

While RSS readers typically show feeds the user trusts, you can't always rely on that. Especially when users are adding comment feeds or aggregators. So filtering HTML is one of the crucial but more difficult parts of writing an RSS reader. On the one hand, you want to allow as much HTML as possible to allow rendering the feed as well as possible. On the other hand, RSS readers can't allow everything. Not only for security reasons, but also to prevent feeds from breaking the RSS reader's UI, especially when the reader is HTML-based and renders posts in its own DOM tree.

Unfortunately, RSS and other syndication formats (Atom, JSON Feed) do not make any attempt to specify an HTML subset to be used in feeds. As readers can't allow full HTML, this will inevitably lead to incompatibilities between readers. I believe this is something to be addressed, and I will come back to in a future post here.

But the main point I was going to make here was: be careful. If you are the user of an RSS reader, make sure you get one you can trust, because it's a tool you process untrusted data with. And as an author of RSS tools, be aware of the fallacies that come with rendering untrusted HTML.

Is Atom better than RSS?

Sun, 02 Aug 2026 09:52:51 GMT

There is this old argument about whether Atom is really superior to RSS. It comes back every once in a while, and also this weekend on Hacker News. Like so often, the central point is the format and encoding of texts and dates. Here, the main example is the <title> element. This is my comment on the original article:

I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow.

In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt away.

In my humble opinion, JSON Feed (https://www.jsonfeed.org/version/1.1/) is the most practical format. By a small margin, but still...

it's really simple and doesn't use XML
it doesn't allow bad things like HTML in titles (which I guarantee >50% of all implementations can't handle correctly)
JSON Feed allows feeds to have a <favicon> and a (square!) <icon>, which is a very practical thing for readers. You can use the <favicon> in lists of feeds, and the <icon> to present a single feed. Atom has a small square icon and a <logo> which is supposed to use a 2:1 aspect ratio. 2:1 is completely useless. No site has a logo in 2:1. It's also useless for most full-name logos, like 'New York Times'. (RSS is, of course, even worse; it doesn't even recommend an aspect ratio, practically guaranteeing that RSS readers can look bad.)

You can see that JSON Feed has been designed from a feed consumer's point of view: what does an RSS reader need to make a feed look good? While Atom and RSS have been written from an abstract publisher's point of view, making everything possible and allowing maximum flexibility. Especially RSS, which has shown its flexibility in becoming the de facto format for podcasts. And both Atom and RSS are really old, written at a time when it probably wasn't clear how RSS would eventually be used.

In the end, no matter which format a feed uses, users won't notice any difference (as long as publishers are smart enough to use square images!). So any feed is a win, no matter whether RSS, Atom, or JSON Feed.

How RSS Disappeared from the Mainstream

Fri, 31 Jul 2026 13:13:49 GMT

There was a time, back in the 2000s and early 2010s, when RSS was nearly mainstream. All enthusiasts knew it, and most used it. Websites prominently featured their RSS buttons. Web browsers had built-in RSS support. And Google Reader made RSS accessible to regular users. But what happened?

RSS Logo

The End of Google Reader

Google shut down Reader, removed RSS support from Chrome, and RSS became hard to use for most users. Most likely, Google Reader was an expensive distraction for Google that didn't generate any revenue. Back then, social networks were all the rage, and Google wanted a share of the pie with Google+. For a while, it looked like social media could replace RSS readers, and user numbers were declining as people spent more time on social networks. Of course, that was at a time when social networks weren't really monetized either and didn't have nearly the volume of advertisements they have today.

Without Google, not only did the biggest brand name supporting RSS disappear. The remaining RSS readers were mostly designed for enthusiasts. Capable, but packed with complicated features mostly relevant to power users, full of jargon and with less user-friendly design. Like many others, I switched to Feedly back then, as it was the most similar available reader and they made it easy to migrate. But today, it looks like Feedly has mostly pulled out of the market and pivoted to the more profitable market of threat intelligence. Feedly can still be used as an RSS reader, but go to their website, and you see a threat intelligence tool, not a reader.

RSS Readers from a Beginner's Perspective

Let's say you've heard about RSS readers being a great invention, and you Google it. This is what Google returns:

Your first hit is rssview.app. You open it, and this is what you see: Technically, it's an interesting reader that allows you to read a feed without logging in. But for a new user, that's just incomprehensible mumbo jumbo with no easy way of understanding how this can work. Just want to read the New York Times? Not a chance!

Current RSS Readers Are for Power Users

Thankfully, Google's AI Overview lists some popular RSS readers. The first one is Inoreader. Arguably the most powerful reader on the market, and with a generous free plan. But I'm not sure this landing page, and especially the screenshot, appeals to non-technical first-time users of RSS. Without any doubt, Inoreader is a great product for power users. But it's not an attractive product for first-time users.

NewsBlur is similar. It's more like a power tool, designed for maximum functionality, not for usability.

NetNewsWire's simple interface is closer to a feed reader that is easy to use. Without any doubt, it is simple and clean. It just doesn't make it easy for the user. There is no catalog of feeds, no help managing feeds, and no web version.

The Content Publisher Dilemma

However, RSS readers are far from the only challenge for RSS. The sad truth is, it's hard to make money from offering an RSS feed, especially for ad-financed sites. While RSS feeds can generate additional traffic for articles, at the same time, every user who does not visit the site's homepage is a user who won't see the site's ads.

The case is even more difficult for publishers who publish not just summaries or headlines, but whole articles through RSS. These publishers will see zero revenue from RSS. At best, they can place some affiliate links.

In the end, it's also a blessing that the number of RSS users is not that significant, as the possible loss in ad revenue stays low that way. If most users used RSS, there would be much more scrutiny about the cost and benefit of RSS feeds, and we might end up with fewer RSS feeds than today.

How Can RSS Get (Back) to Mainstream Users?

I believe there are two things missing for RSS to really thrive.

ubiquitous RSS readers: just look at podcast apps. They come with phones; they are bundled in services like Spotify; and they are easy to use. Everybody is just a click or two away from listening to a podcast. Reading an RSS feed is far more complicated. Either RSS readers must be as widespread as podcast apps, or there needs to be a well-known RSS reader that everybody can easily find.
a business model for feeds: this may be the bigger issue. Many feeds just offer summaries, so they can create revenue with users on their own website. Some sites offer full-text feeds for subscribers (like The Verge does), but this is rare. An easy system to allow publishers to get paid when a user reads their feed would go a long way in motivating them to promote their RSS feeds.

Until we have at least one of those things, ideally both, RSS readers will stay a niche product.

Post image at the top by Ashley Dryden, licensed CC BY 2.0 Attribution

About Two Waves and a Dot

Sun, 26 Jul 2026 12:39:31 GMT

Hi,

Human here! I just wanted to give you some background on this blog, why it exists, and how everything came together. Just be aware that you are reading this weeks after I originally wrote it, in July 2026. I’m a bit of a serial project abandoner. More on that later, but I promised myself I would not publish a new blog before I am 100% sure that I have gathered enough content to make it a worthwhile effort. Thankfully, these days, AI makes it easier for me to get out of the slump that I fall into every time a project goes from being fun to being serious work. As you are reading this, it looks like I made it.

So the story of me and RSS.. I must have started using RSS in the very early 2000s. No idea what I was using then to consume it, probably Mozilla Thunderbird, but this doesn’t really matter to this story. So I was consuming lots of feeds at that time, and I also had a slightly successful gadget review blog on Blogger, which I (you guessed it) abandoned a long, long time ago. Just like I had a full Slashdot-like site for tech interviews ready, with RSS and Atom feed generation, but abandoned it when it came to actually filling it with content and talking to humans (bleh!). Anyways, I had already been exposed to RSS a lot, both as a consumer and producer.

When, in 2005, Google Reader came out, it was a revelation. Back then, existing RSS readers were better than visiting websites one by one, but they weren’t really a joy to use. Google Reader was. So these were the happy days, when RSS was easy and was slowly entering the mainstream. For personal reasons, like meeting my future wife, it was also the time when I stopped working on any new content projects, but I was an avid user of Google Reader. Generally, even today, I am spending a significant part of my waking hours reading things on the internet, and an RSS reader makes it so much easier.

And then, in 2013, it all ended: Google Reader was shut down. My first reaction was to create a new reader on my own. Only this was the time when my wife and I got our first kids, and I was smart enough to know that creating a cloud-based RSS reader was an enormous task that I would never be able to complete. So I moved to Feedly quickly, since they made the migration easy. And Feedly works fine. I never loved it like I loved Google Reader. But, on the other hand, it worked and was better than visiting websites one by one. So I kept using it for quite a while. Till 2026, actually. Always thinking of what I would like to improve, but also knowing that I had no realistic chance to build this on the side, and whatever I started would just end up as another corpse on my list of abandoned projects.

Last year, near the end of 2025, I was still working on a different project, and realized that Claude Code is now so advanced that I had a realistic chance of creating the RSS reader that I really wanted in 3-4 months. So I did what I always do, ~~abandoned~~ paused my existing project, and started to work on a new one. And because all (really all!) good .com domain names that contain words like “read” or “feed” are long gone, I settled on the last remaining one: downread.com.

I am now near the end of month number 8, so the 4 months didn’t quite hold. In my defense, it was already very usable after 4 months. Just not ready to release. There are so many usable RSS readers already out there that I decided that I need to create one that really feels superior - people usually don’t give products a second chance.

But coming back to this blog: during the last 8 months, I have read countless blogs, looked at countless other RSS readers, and I am keeping up with what is happening with RSS… it currently even feels like there is some momentum. Or maybe I just feel like this because I am spending so much time actively looking out for anything anyone ever says about RSS. Anyway, I thought I should use this to create a central source of information for the RSS community, because there isn’t one yet. And also, as a side-effect, to have a channel to promote my RSS reader just a little bit. I am really not going to talk about it here unless I have a big announcement. It will have its own blog. So this will be a neutral blog, about RSS, Atom, JSON feeds… and whatever info I come across on my journey.

Tim