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.
What I Would Change About Feed Menu
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.
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).
rss.xml
<channel>
<title>Stuart Breckenridge</title>
<description>Personal blog by Stuart Breckenridge. App development, Apple ecosystem, cycling, and more.</description>
<content:encoded> <p>The feeds on this site now support the nascent <ahref="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><codeclass="language-xml"> </code></pre> </content:encoded>
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
I’ve upgraded the site from Astro 5 all the way to Astro 6.1. Everything should be as it was, but what’s gone on behind the scenes is extensive. A short summary of what’s changed:
Posts have been reorganised — each post is now its own folder with its images sitting alongside the markdown.
All post images have been converted from PNG/JPG to WebP 1. The legacy versions are still around so existing feed entries don’t break.
Search results have been visually fixed.
Unrelated to Astro 6.1, the /atom.xml feed is now using WebSubHub, so if your reader supports it, you’ll now see posts close to when they are published.
Last week, I wrote about catching a supply chain attack on a WordPress plugin called Widget Logic. A trusted name, acquired by a new owner, turned into something malicious. It happened again. This time at a much larger scale.
[…]
The injected code was sophisticated. It fetched spam links, redirects, and fake pages from a command-and-control server. It only showed the spam to Googlebot, making it invisible to site owners. And here is the wildest part. It resolved its C2 domain through an Ethereum smart contract, querying public blockchain RPC endpoints. Traditional domain takedowns would not work because the attacker could update the smart contract to point to a new domain at any time.
[…]
Two supply chain attacks in two weeks. Both followed the same pattern. Buy a trusted plugin with an established install base, inherit the WordPress.org commit access, and inject malicious code. The Flippa listing for Essential Plugin was public. The buyer’s background in SEO and gambling marketing was public. And yet the acquisition sailed through without any review from WordPress.org.
WordPress.org has no mechanism to flag or review plugin ownership transfers. There is no “change of control” notification to users. No additional code review triggered by a new committer. The Plugins Team responded quickly once the attack was discovered. But 8 months passed between the backdoor being planted and being caught.
It’s truly astonishing that WordPress, despite its scale, has such exploitable supply-chain security. I’m aware of a similar npm supply-chain risk with Gobbler, though I am using both Dependabot and Socket.dev to mitigate it.1
I am also reminded of my own brief stint with WordPress in mid-2025 — I was quite excited. However, after four days I was already concerned about its security and installed wpfail2ban. ↩
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:
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.
A few weeks ago I moved this site back to Astro and ever since I’ve been curious about the state of Webmention and whether I should implement it. For the curious:
Webmention is a simple way to notify any URL when you mention it on your site. From the receiver’s perspective, it’s a way to request notifications when other sites mention it.
To get this up and running quickly, I’m using Webmention.io for receiving website mentions and brid.gy for monitoring social media interactions and sending them to Webmention.io. In <head>, I’ve added:
At the bottom of each post, there’s an Astro component that fetches and renders Webmentions from Webmention.io on each page load.
In terms of posting Webmentions, I’ve updated the small server app, Broadcaster, that monitors the Atom feed for the site and posts to Mastodon and Bluesky. Now, Broadcaster scans post content, identifies links, checks if the linked site publishes a Webmention <link>, and sends a Webmention if it does.
This all seems to work but I don’t like relying on Webmention.io. Similar to the approach taken by Wojtek Powiertowski, I will look to incorporate Webmention listening into Broadcaster (and, at the same time, I’ll probably have to change its name).
For example, if you have a 4.1 star rating in the App Store, any 4 star review is going to decrease that average. In other words, leaving a 4 star review is essentially leaving a negative review.
Problem #1 […] If you’re going to collect and average ratings from users, the system that works best is binary: thumbs-up or thumbs-down. Netflix switched from stars to thumbs in 2017, and YouTube switched all the way back in 2009.
I’d add one more to this list, and certainly one that’s more analogous to the App Store: Steam. Steam’s thumbs-based model is far superior. Not only can you rate and review the game (or app), but other users can also rate your review. Potential buyers can then find and filter by the most helpful reviews. It’s a better model for all involved. See UPDATE #1 below.
Next:
Problem #2 is that even if the App Store switched from stars to thumbs, the system would still be gamified by developers, rewarding, as Godier aptly puts it, not the best apps but instead the apps that are best at “review prompt execution”. Apple should remove the APIs that allow apps to prompt for reviews, and forbid the practice of prompting for them.
Apple should remove those APIs, but they won’t, and until they do, we’re playing within that ruleset. Full disclosure, I’ve built what Terry and John are describing, Singapore Buses does include a review prompt. It’s insidiously well designed. On the third launch, the app asks for a rating.
UPDATE #1: I just discovered that the App Store also has a thumbs-up/thumbs-down rating system for reviews of an app. Long-press a review and a context menu appears with Helpful vs. Not Helpful responses. Its outrageous that this system is hidden behind a long-press.
Apple’s MacBook Neo has been a huge hit, and it’s still in high demand over a month after it launched. The MacBook Neo is just $599, and with PC makers raising prices because of global RAM shortages, the Neo’s low price tag and Apple allure are even more appealing.
MacBook Neo orders placed today on the online Apple Store won’t reach customers until May, which means that it’s sold out for the month of April, as 9to5Mac points out. All colors and both the 256GB and 512GB SSD configurations will be delivered between May 1 and May 8 at the earliest.
That the MacBook Neo is a success doesn’t surprise me. I used one briefly in the nearby Apple Store and it’s a really nice laptop. For $599 you’re getting something cheaper and more capable than my iPad Pro paired with a Magic Keyboard. In fact, if the iPad Pro doesn’t start running macOS in the future, I’m not sure I’d buy another one: iPadOS hobbles the iPad Pro to the point where it can’t justify its price tag.
I’ve been having a strange issue with my new M5 MacBook Pro and GitHub: at random intervals, my MacBook cannot connect to GitHub. Well, that’s not strictly true: Safari can’t connect to GitHub, Git Tower can’t push or pull, but Chrome has no issues.
Using dns-sd -G v4 github.com to see what’s happening over time:
Timestamp
A/R
Flags
IF
Hostname
Address
TTL
Note
19:46:30.769
Add
2
0
github.com.
20.205.243.166
15
19:55:16.874
Rmv
0
0
github.com.
20.205.243.166
0
19:55:16.885
Add
2
0
github.com.
20.205.243.166
63
20:01:42.237
Add
2
0
github.com.
0.0.0.0
77
No Such Record
20:01:48.800
Rmv
0
0
github.com.
20.205.243.166
0
20:10:18.607
Add
2
0
github.com.
20.205.243.166
60
20:21:43.313
Add
2
0
github.com.
0.0.0.0
77
No Such Record
20:21:49.456
Rmv
0
0
github.com.
20.205.243.166
0
20:21:49.508
Rmv
0
0
github.com.
20.205.243.166
0
20:22:57.954
Add
2
0
github.com.
20.205.243.166
24
20:23:50.255
Rmv
0
0
github.com.
20.205.243.166
0
20:23:50.267
Add
2
0
github.com.
20.205.243.166
60
20:29:05.686
Add
2
0
github.com.
0.0.0.0
77
No Such Record
20:29:13.694
Rmv
0
0
github.com.
20.205.243.166
0
20:29:13.705
Add
2
0
github.com.
20.205.243.166
68
20:37:31.780
Rmv
1
0
github.com.
20.205.243.166
0
20:37:31.780
Add
2
0
github.com.
0.0.0.0
60
No Such Record
During those No Such Record periods, GitHub just refused to work in Safari or Git Tower.
I switched from Cloudflare’s 1.1.1.1 service to Quad9, and ever since I’ve had no issues.
Timestamp
A/R
Flags
IF
Hostname
Address
TTL
Note
20:37:45.321
Add
2
0
github.com.
20.205.243.166
65
21:13:26.595
Rmv
0
0
github.com.
20.205.243.166
0
21:13:26.603
Add
2
0
github.com.
20.205.243.166
15
This wasn’t a problem on my M3-series MacBook. I can only assume it’s a problem with the M5 and its new networking stack.