> less prone to bugs

Citation needed. With XML validation, auto-generated type-safe serialization, and decades of battle testing, I feel like XML would be less buggy than JSON.

XML feeds are often generated by templating, rather than actual XML serialisation. The official Jekyll Feed plugin has this: https://github.com/jekyll/jekyll-feed/blob/master/lib/jekyll...

JSON is much more easily generated by a valid generator, and less likely to face serialisation issues.

Or so you would think, but malformed or invalid xml is so commonplace, that most good feed readers use very lax or forgiving xml parsers. I’ve never seen such issues with JSON in practice.

We could not even get the world to fully transition to the superior Atom format.

Introduced in 2017 and updated in 2020, I think this is mostly an interesting footnote at this point. Open podcasting efforts continue to evolve on RSS (thanks to RSS namespace extensibility) through industry groups like Podcasting 2.0 and Podcast Standards Project.

Is there a way to add terms of service to the json feed? Effectively it's a firehose GET command and that's tricky to open up publicly without some kind of checks and balances: rate limiting, docs, TOS, etc.

In practice, this doesn't seem to be a problem. Clients are generally smart about using HTTP conditional requests to minimize transfer.

I know npr uses it, but who else really does? I'm happy enough with atom feeds for now tbh.

hnrss.org (https://hnrss.github.io/) provides a JSON feed version for every feed, just append .jsonfeed to any endpoint.

known (https://withknown.com/) also provides JSON feeds

micro.blog (https://micro.blog/) does as well

wordpress also has plugins available that generate JSON feeds