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.

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:

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.

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:

1. 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.
2. The rss.chat server and client code, hosted on GitHub and written in JavaScript, consisting of a server and an HTML-based client.
3. 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 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.

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.