rss

May 4, 2026

Moving Feed Discovery to /.well-known

A few weeks ago I wrote about how RSS discovery is hard. In that particular example I used the BBC, who make things notoriously difficult because they don’t even surface their feeds in the <head> element of their site. However, since writing that piece, I’ve been thinking about better ways for RSS readers to discover feeds, and it turns out I’m not the only one.

There’s an Internet-Draft that proposes moving feed discovery to /.well-known/feed-menu.json, which I think, in principle, is a great idea. Take the following very common use case:

the user provides a website https://example.com to a feed reader
the feed reader scans <head> and can’t find any feeds
the feed reader then makes educated guesses to find feeds, e.g.,
- /feed
- /rss
- rss.xml
- /atom
- and so on

Contrast that with:

the user provides a website https://example.com to a feed reader
the feed reader reads https://example.com/.well-known/feed-menu.json and immediately has a full rundown of the feeds the site offers

The benefits are clear.

The name. I think Feed Menu is not serious enough for a standard. I’d prefer something along the lines of /.well-known/syndication.json or, even simpler, just /.well-known/feeds.json.

I’d also expand each object in feeds so that it is explicit about title, URL, format, version, and media type.

{
  "publisher": {
    "name": "Stuart Breckenridge",
    "url": "https://stuartbreckenridge.net/",
    "contact_url": "https://stuartbreckenridge.net/about"
  },
  "feeds": [
    {
      "title": "Stuart Breckenridge",
      "url": "https://stuartbreckenridge.net/feed.json",
      "format": "jsonfeed",
      "version": "1.1",
      "rel": "self",
      "media_type": "application/feed+json",
      "preferred": true
    },
    {
      "title": "Stuart Breckenridge",
      "url": "https://stuartbreckenridge.net/atom.xml",
      "format": "atom",
      "rel": "alternate",
      "media_type": "application/atom+xml"
    },
    {
      "title": "Stuart Breckenridge",
      "url": "https://stuartbreckenridge.net/rss.xml",
      "format": "rss",
      "version": "2.0",
      "rel": "alternate",
      "media_type": "application/rss+xml"
    },
    {
      "title": "Stuart Breckenridge: Links",
      "url": "https://stuartbreckenridge.net/links/feed.json",
      "format": "jsonfeed",
      "version": "1.1",
      "rel": "alternate",
      "media_type": "application/feed+json"
    }
  ]
}

A single GET to /.well-known/feeds.json would give a feed reader everything it needs.

May 3, 2026

Enhanced Feeds with Byline Data

The feeds on this site now support the nascent Byline specification. While this is a single-person blog, the change gives supporting feed readers the data they need to differentiate between linked items (curation), reviews (review), and announcements (announcement).

<channel>
  <title>Stuart Breckenridge</title>
  <description>Personal blog by Stuart Breckenridge. App development, Apple ecosystem, cycling, and more.</description>
  <link>https://stuartbreckenridge.net/</link>
  <language>en-us</language>
  <atom:link href="https://stuartbreckenridge.net/rss.xml" rel="self" type="application/rss+xml"/>
  <byline:contributors>
    <byline:person id="stuart">
      <byline:name>Stuart Breckenridge</byline:name>
      <byline:context>iOS developer, program manager, cyclist, and writer about apps, Apple, RSS, and technology.</byline:context>
      <byline:url>https://stuartbreckenridge.net/about</byline:url>
      <byline:profile href="https://indieweb.social/@stuarticus" rel="mastodon"/>
      <byline:profile href="https://github.com/stuartbreckenridge" rel="github"/>
      <byline:profile href="https://bsky.app/profile/stuartbreckenridge.net" rel="bluesky"/>
      <byline:profile href="https://threads.net/@stuarticus" rel="threads"/>
    </byline:person>
  </byline:contributors>
  <image>
    <url>https://stuartbreckenridge.net/favicon-v20260420.png</url>
    <title>Stuart Breckenridge</title>
    <link>https://stuartbreckenridge.net/</link>
  </image>
  <item>
    <title>Enhanced Feeds with Byline Data</title>
    <link>https://stuartbreckenridge.net/2026-05-03-enhanced-feeds-with-byline-data/?utm_source=rss&utm_medium=feed</link>
    <guid isPermaLink="false">01KQPWXDVZSHD2X2ZVASCT3NEG</guid>
    <pubDate>Sun, 03 May 2026 12:27:20 GMT</pubDate>
    <content:encoded> <p>The feeds on this site now support the nascent <a href="https://www.bylinespec.org/">Byline</a> specification. While this is a single-person blog, the change gives supporting feed readers the data they need to differentiate between linked items (<code>curation</code>), reviews (<code>review</code>), and announcements (<code>announcement</code>).</p> <pre><code class="language-xml"> </code></pre> </content:encoded>
    <byline:author ref="stuart"/>
    <byline:role>creator</byline:role>
    <byline:perspective>personal</byline:perspective>
    </item>
</channel>

May 1, 2026

'One Month In'

Gobbler’s Month One Update:

Gobbler is one month old. Overall, it’s been a stable first month, with user numbers growing and a few interesting events along the way.

Stability

According to DigitalOcean, Gobbler had over 99% uptime. There was the odd latency spike from distant regions (think us_east to se_asia), but nothing worrying. The database is also performing well as the number of entries grows (at time of writing, ~150,000).

Success, 403s, and 404s When You Least Expect Them

Despite initially working fine, *.substack.com and medium.com feeds stopped working in their entirety in weeks three and four, respectively. This has largely been resolved by routing fetches to these domains via Cloudflare egress. Gobbler has also been submitted to Cloudflare’s Bot Verification Program, which should make the egress workaround a thing of the past.

youtube.com feeds are special. For most of the day they’ll work fine, then they’ll 404 for a few hours, then they’ll work fine again. It’s a known issue and there doesn’t appear to be a solution.

The only other problematic sites belong to, or are partnered with, IGN Entertainment. We have reached out to IGN to see if this can be resolved. However, as these sites are protected by Cloudflare, Bot Verification is hopefully the long-term solution.

Outside of the above, 5% of feeds are not reachable due to network errors, and Gobbler’s article fetch success rate sits at 84%.

Improvements in Month 1

New accounts: switched from email/password to social sign-in (Apple, Microsoft, Google) and app passwords

Implemented WebSub support

Improved newsletter rendering

April 20, 2026

Filtered Feeds

I’ve separated the content available across the RSS, Atom, and JSON feeds on the site. You can find them all on the About page, and I’ve listed them below:

Feed	RSS	Atom	JSON
All Posts	/rss.xml	/atom.xml	/feed.json
Featured Articles	/featured/rss.xml	/featured/atom.xml	/featured/feed.json
Linked List	/links/rss.xml	/links/atom.xml	/links/feed.json

The new feeds are a bit bare right now as I’ve moved this blog from platform to platform so many times, and lost content along the way. I must stop doing that.

April 12, 2026

'You Can Absolutely Have an RSS Dependent Website in 2026'

Mat Duggan

At one point I did have a Subscribe button up, and enough people clicked it that the cost of actually sending those emails started to resemble a real bill. Sending thousands of emails when you have no ads, no sponsors, and no monetization strategy beyond “I guess people will just… read it?” doesn’t make a lot of financial sense.

…

But the bigger reason — the one I actually care about — is that I didn’t want a database full of email addresses sitting under my control if I could possibly avoid it.

…

The people who use RSS really use RSS. They’re not trend-chasers. They’re the type who still have a working bookmark toolbar. They are, in the best possible sense, your people.

I had the same strategy of no ads, no sponsors, and no monetisation when I was using Ghost (Pro) and, yes, that resembled a real bill of US$348 a year (because I had to have a custom theme). That fee also covered membership management, database security, and email distribution, so it wasn’t just hosting and a CMS.

When I switched to Astro, I dropped my free membership, membership-only pages, and newsletter, effectively going RSS only. And Atom. And JSON feed. It can be done.

RSS just isn’t as easy to explain as email is to people that are new to the format.

April 11, 2026

Introducing Gobbler

One of my side projects, Gobbler, made it out of the oven just over a week ago. It’s a web-based RSS reader that offers a Google Reader-compatible API and even more functionality via a REST API to third-party clients.

Gobbler builds on the traditional RSS reader functionality (Feeds, Feed-level management, and Starred articles) with:

Lists, for organising articles
Annotations, for highlighting text within articles
Markdown export, for saving and viewing articles in other applications
Newsletter support
Custom typography ¹

Gobbler has a 14-day free trial and then it’s just $5/month. If you use NetNewsWire, Current, or Reeder (Classic), Gobbler already works! If not, you can use Gobbler in your browser or as an installable Web app on your device.

I spent a long time selecting which font to use for the sans serif. In the end it was a tie between Die Grotesk and Geograph, both from Klim, and Geograph won. ↩

April 3, 2026

The BBC's RSS Feed

Due to the incorrect way the BBC’s RSS 2.0 feed handles guids, RSS readers are repeatedly left displaying duplicate articles.

Let’s have a look at why this happens with a sample article from their feed:

<item>
    <title>
        <![CDATA[
            'We fell off the face of the earth': Dad-daughter duo who took on 7,500 miles for TV
        ]]>
    </title>
    <description>
        <![CDATA[
            Molly Clifford and her father are part of this year's line up for the BBC's Race Across the World.
        ]]>
    </description>
    <link>
        https://www.bbc.com/news/articles/c9951jrr18no?at_medium=RSS&at_campaign=rss
    </link>
    <guid isPermaLink="false">https://www.bbc.com/news/articles/c9951jrr18no#3</guid>
    <pubDate>Fri, 03 Apr 2026 05:19:07 GMT</pubDate>
    <media:thumbnail width="240" height="135" url="https://ichef.bbci.co.uk/ace/standard/240/cpsprodpb/bb22/live/0bdf4fa0-2db9-11f1-934f-036468834728.jpg"/>
</item>

Specifically, let’s focus on the guid:

<guid isPermaLink="false">https://www.bbc.com/news/articles/c9951jrr18no#3</guid>

What I’ve seen the BBC doing is incrementing the suffix after the # and, as per the RSS 2.0 specification below, RSS readers tend to treat each incremented guid as a new entry:

guid stands for globally unique identifier. It’s a string that uniquely identifies the item. When present, an aggregator may choose to use this string to determine if an item is new.

The above article has been fetched by Gobbler twice and the title had changed between fetches:

guid	title	content hash
https://www.bbc.com/news/articles/c9951jrr18no#2	’We fell off the face of the earth’: Dad and daughter raced across world but had to keep it secret	a8159e96
https://www.bbc.com/news/articles/c9951jrr18no#3	’We fell off the face of the earth’: Dad-daughter duo who took on 7,500 miles for TV	17cbc6b7

Strictly speaking, the RSS 2.0 specification doesn’t prohibit a guid from changing. Additionally, there are no update semantics available (e.g., an updatedDate element) in the 2.0 specification. So, in this scenario with a change of title, an incremented guid is almost justifiable.

However, this isn’t always the case. Let’s look at a different example in the Gobbler database:

guid	title	content hash
https://www.bbc.com/news/articles/cyv1q9gz39do#0	How English-only condolences undid one of Canada’s top CEOs	8845f9d6
https://www.bbc.com/news/articles/cyv1q9gz39do#1	How English-only condolences undid one of Canada’s top CEOs	8845f9d6
https://www.bbc.com/news/articles/cyv1q9gz39do#3	How English-only condolences undid one of Canada’s top CEOs	8845f9d6

Gobbler has fetched this article three times. The article hasn’t changed at all: same title, same content, and same published date ¹, all validated by the content_hash. This is simply not justifiable. There is no reason to change the guid if the article hasn’t changed.

What could the BBC do differently?

First, don’t change the guid when the article content hasn’t changed. Just don’t.

Second, if the article has been updated, use <atom:updated> in the <item>. The feed declares the Atom namespace and already uses it:

<atom:link href="https://feeds.bbci.co.uk/news/uk/rss.xml" rel="self" type="application/rss+xml"/>

Lastly, and this is a bit of a stretch goal, put the full content of each article in the feed instead of a summary.

I couldn’t fit everything in the table. ↩

March 19, 2026

PC Gamer Recommends RSS Readers in a 37MB Article That Just Keeps Downloading

There’s not much worth quoting in this PC Gamer article but I do want to draw your attention to three things.

First, what you see when you navigate to the page: a notification popup, a newsletter popup that obscures the article, and a dimmed background with at least five visible ads.

Second, once you get passed the welcome mat: yes, five ads, a title and a subtitle.

Third, this is a whopping 37MB webpage on initial load. But that’s not the worst part. In the five minutes since I started writing this post the website has downloaded almost half a gigabyte of new ads.

We’re lucky to have so many good RSS readers that cut through this nonsense. ¹

NetNewsWire, Unread, Current, and Reeder, to name a few. ↩

March 13, 2026

Making RSS Discoverable is Hard

Let’s talk about the BBC.

The BBC surface a bunch of RSS feeds if you know where to look. However, in an RSS reader if you try to follow bbc.co.uk or bbc.com, you’ll invariably get a “No Feed Found” error (or equivalent). Why? Because the BBC don’t surface these feeds under the hood in the <head> element of the HTML, which is what they should do. It’s at this point where RSS becomes difficult and where users drop out.

In these scenarios, my idea was to use Gobbler’s knowledge of feeds available on those domains. If someone put bbc.co.uk into the address bar, Gobbler would surface http://newsrss.bbc.co.uk/rss/newsonline_uk_edition/business/rss.xml (BBC News UK) if it knew an RSS feed existed.

Easy to code, easy to implement, and adds immediate value for discoverability. So, why have I pulled it?

Respecting private feeds.

I subscribe to publications where I receive a unique, private RSS link, that contains articles that I’ve paid for. Imagine a scenario where Gobbler surfaced that URL? It would completely undermine said publication’s business model.

I still think there is merit in the feature. I just need to find a way to not surface the wrong URLs.

What I Would Change About Feed Menu

Stability

Success, 403s, and 404s When You Least Expect Them

Improvements in Month 1