Cory Doctorow with an RSS sermon. There’s something rather quixotic about fighting for RSS. Can’t put my finger on it but it feels like a lost cause because something is technically missing in the paradigm. Not because evil anti-protocol types killed it. It worked for a while because it wasn’t meaningfully stress-tested.
The day we understand why RSS failed and what might have saved it/could revive it in the future, we’ll have figured out everything important about protocols. My intuition is that it wasn’t social. People want their online reading to have a social component. Anything that’s solo read-only is doomed.
There were/are RSS-to-email services. I think because people wanted to forward and dus uss easily on email threads. Iirc Google Reader had comments though that was bolted onto the protocol somehow?
I know that you’re probably right, and that makes me a bit sad.
I just wanted to add that the reverse also exists and a few people use it:
How does Kill the Newsletter! work?
Create a feed with the form above and Kill the Newsletter! provides you with an email address and an Atom feed. Emails that are received at that address are turned into entries in that feed. Sign up to a newsletter with that address and use your feed reader to subscribe to that feed.
I tried to do an RSS-based recommendation startup back in 2009 or so, and I still use RSS myself. So I’m biased to like it. And yet, I’ve had the same sense as you for many years now. Something is missing. Some ideas I’ve had on what it is:
Lack of UX polish like in open source in general. When the emphasis is on interoperating with a commons of other apps, everybody has less skin in the game to make the UX good.
This isn’t just a cosmetic thing. One classic problem I’ve been seeing for 20 years: every now and then my reader will forget what posts it’s seen from some feed and mark everything unread. It happens for a variety of long-tail reasons. Incompatibilities in either the server or the reader. Annoying for me, but much more so for Eloi.
Perhaps the same rot that affects blogging as a whole? 2000-2010 was the golden age of blogs. They disappeared precisely to the extent they went mainstream. It could only be an elitist minority subculture. That applies to RSS too, perhaps. It stopped being fun around the same time everybody stopped using blogs. I like to blame Google for killing Reader, but perhaps in this one case we’re just shooting the messenger.
The standard dogma of blogs vs social media is that a blog is like your home and social media is like the street. But there’s always been a central incoherence there. Most people are trying to invite people (even close friends) in and failing, because a blog just doesn’t have the degree of life a home does. Life happens on the street.
Blogs are a fundamentally dead medium, and RSS is dead just by virtue of attaching to them. Maybe.
In 2024 I turned the idea of POSSE (publish on own site, syndicate elsewhere) on its head. On my devlog I repost a subset of my posts from Mastodon. They get cleaned up a bit. Threads of multiple toots get merged. I can add some html formatting. The result is a little nicer to read than a Mastodon thread. (Lots of people still have no clue how to parse a Twitter or Mastodon page.)
It looks superficially like I’m doing PESOS (publish elsewhere, syndicate on own site). The dogma is that PESOS inferior to POSSE but better than nothing. But I don’t really care about the syndication anymore. My devlog is a repository of links I can share with people when relevant. That’s it. I have no illusions that it’s a destination in its own right.
RSS is a zombie trying to look alive. My devlog kinda owns that it’s a dead thing, that the vitality is something readers bring to it.
I kinda get what Doctorow is saying. But I don’t think RSS is necessary to retain agency in the face of big tech aggregators. All you need to do is get out more, and browse many sites.
Another UX problem I remember now is handling relative hyperlinks. Usually composing a blog post is in the context of a specific site, and relative links are more concise and convey intent better. But adding RSS to a site gives it a second context. Now it’s in a feedreader disconnected from your site. Either the author must use absolute hyperlinks or the reader must go through and scrape a feed’s html. Why not just work with HTML at that point.
Perhaps the larger point is: is a feedreader providing voluntary or adversarial interoperability? If it’s voluntary, then it doesn’t feel like a big step above just providing clean html. The benefits are perhaps not worth the cost of a second representation. On the other hand, if it’s adversarial and it’s easy to create feeds for arbitrary sites, why do we ask authors to provide feeds? So I think RSS falls into an uncanny valley here.
Thought experiment: What if we separate how RSS is used to power blogs & RSS readers from how RSS is used to power podcast apps. The reason I’m saying this is because I can understand how someone can say RSS readers have failed but I don’t think anyone would say podcasting has failed. So, why have podcasts succeeded when the rest of RSS hasn’t?
I will offer up 3 reasons why I think podcasting succeeded.
A great user experience. I have talked to so many people (including developers) who don’t know that podcasts are powered by RSS under the hood. To a regular person, it works just like every other content platform (YouTube, TikTok, Instagram etc). They dont know or care that an open standard powers the app they use every day. This is the user experience all protocols should strive for.
Podcasting feeds are self-contained. Podcast feeds contain custom XML tags (like itunes:image, itunes:category, itunes:explicit, etc.). which gives it all the information needed to display the podcast without navigating to a different url. This is fundamentally different from how RSS reader apps work, which typically provides titles and snippets from the RSS feed and require users to click through to external websites for the full content. To reiterate point #1, because podcast feeds are self-contained - it enables podcast apps to create a great user experience - as it gives the same experience as every other content platform (YouTube, TikTok, Instagram etc) despite being powered by an open standard.
Apple, a really important and influential company, pushed for podcasting to succeed. Apple built an iPod and wanted more free + great content for their product. They didn’t care about owning the content platform, they just wanted to sell more devices. This greatly benefited the podcast ecosystem.
And to address your point that RSS may have failed because it wasn’t social.
I get where you are coming from. RSS is a one-way distribution model, with no identity or social layer. If RSS failed because of that, it really makes me think AT Protocol / Bluesky is headed in the right direction as to me ATProtocol is an identity layer on top of your PDS (which can be thought of as a user’s RSS feed)
But, to be a contrarian to your point, I actually don’t think RSS failed because it was missing social. After all, if it was, wouldn’t we expect ActivityPub to be more successful than podcasting, since its essentially a two-way version of RSS. Yet ActivityPub’s adoption has been limited (compared to podcasting), partly due to increased complexity that affects both users and developers. Take Mastodon for example: hosting your own instance is costly, app development is more complex due to additional moving parts, and user onboarding remains an issue for Mastadon years later. This suggests to me that podcasting’s approach of focusing on simplicity & user experience is more crucial to success than social features.
In redirecting my newsletter domain, I broke all my internal links, since substack doesn’t have relative linking. Now I have to go back and put in new absolute links in all my handcrafted pages.
Not directly related to RSS but it feels like domain context should be a global that’s handled appropriately by the embedding context (email client, browser session, in-feed preview, RSS client). Authoring should always be in maximally solipsistic context. Kinda like putting the coordinate system origin of an object at its center of gravity.
There’s also a content-addressing angle here. The object should exist primarily in relation to its own hash, not an addressspace or namespace. I’m still waiting for a usable content-addressed publishing tool. IPFS sans filecoin is too infrastructurey. Arweave is too integrated with crypto. BitTorrent type things are too neckbeardy.
Yeah that fits how I’ve been thinking about it. You want solipsism at all levels.
One concrete tiny place where I’ve been wishing for content micro-addressing is in referring to bullet points. If you number a bullet list and then want to refer to point 2 in the list, there’s basically no way to do that that is stable to inserting and deleting other bullets to the list. HTML can’t do it, Markdown can’t do it, nothing can do it short of LaTeX or a full-scale WYSIWYG editor.