I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow.
In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt away.
- it doesn't allow stupid things like HTML in titles (which I guarantee >50% of all implementations can't handle correctly)
- JSON Feed allows feeds to have a <favicon> and a (square!) <icon>, which is a very practical thing for readers. You can use the <favicon> in lists of feeds, and the <icon> to present a single feed. Atom has a small square icon and a <logo> which is supposed to use a 2:1 aspect ratio. 2:1 is completely useless. No site has a logo in 2:1. It's also useless for most full-name logos, like 'New York Times'. (RSS is, of course, even worse; it doesn't even recommend an aspect ratio, practically guaranteeing that RSS readers can look bad)
You can see that JSON feed has been designed from a feed consumer's point of view: what does an RSS reader need to make a feed look good? While Atom and RSS have been written from an abstract publisher's point of view, making everything possible and allowing maximum flexibility. Especially RSS, which has shown its flexibility in becoming the de facto format for podcasts. And both Atom and RSS are really old, written at a time when it probably wasn't clear how RSS would eventually be used.
In the end, no matter which format a feed uses, users won't notice any difference (as long as publishers are smart enough to use square images!). So any feed is a win, no matter whether RSS, Atom, or JSON feed.
Consider the title of my article: “Atom is better than RSS, in ways that matter”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.)
We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles? When you look at titles that get used on platforms like YouTube, there’s obviously a desire for formatting. People use Unicode shenanigans to work around the deficit frequently. (And they do so in ways that are mostly only available for the English script, quite inequitable for other scripts.) Even if you were to restrict it to ASCII, people GLEEFULLY abuse capital letters FOR EMPHASIS!!!!1!
Especially once you get to coding topics, titles need to support <code>, which is important semantics.
(My biggest disappointment with Atom is that text constructs are single-type-only. I wish you could provide distinct text and HTML representations, like email does with the multipart/alternative MIME type. In some places where I use <code> in titles, I’d just drop the <code>…</code> wrapping, in other places I’d turn it into `…`.)
I will write a proper article about all this some time soonish, encouraging people to use markup in titles.
> We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles?
1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers that don't support the same subset. No renderer can allow it completely (<script>...). HTML sanitation/injection becomes a much bigger problem when it's not limited to a text body that can be relatively easily sandboxed.
2. If you allow every feed to define its own font style or even color, that makes a list of posts look like a 2005 MySpace page. :)
It is producing bad UIs. Renderers can't really render it as plain text, as they might lose a part of the meaning. But they also can't really allow it because it might make their output look like trash. In the end, that would force renderers to develop complex heuristics of which elements and styles to allow, which to modify (do your HTML titles support dark mode? accessibility?), and which to filter out.
3. I don't see the practical value of having <code> in a headline. If it shouldn't be rendered in a different way for obvious reasons, and XML is not designed for human consumption, what is it good for? Who is the consumer of the <code> tag? AI?
Inferior plain text: Using make and git diff for a simple and powerful test harness
Better plain text: Using `make` and `git diff` for a simple and powerful test harness
Better HTML: Using <code>make</code> and <code>git diff</code> for a simple and powerful test harness
I use the second for the <title> and og:title on my site, and the third in the <h1> and feeds. It will unfortunately be turned into the first by some feed readers, but that’s their problem. (Some feed readers do accept a subset of HTML phrasing content.)
> If it shouldn't be rendered in a different way for obvious reasons
I agree that it makes sense on that page. But only because the rendering of the page is completely under the control of the author, and the page shows only that one page. It's different if the text is rendered by an RSS reader in a different context. You don't know the font, color, or text weight it is rendered with in an RSS reader (which also depends on the context, like unread posts being bold). Imagine the same title in a list of post titles. I think it would stick out and make the list much harder to read.
> Imagine the same title in a list of post titles.
Sounds wonderful. I think you aren’t realising that it’s already easy to abuse this stuff, with uppercase and exotic Unicode letters <https://yaytext.com/> and such. But people don’t abuse it in feeds.
I’m not talking about allowing <font face=Impact style=color:red>, just some relevant semantic HTML elements like <code>, <em> and <kbd>, which are pretty harmless to add, and useful.
Perhaps I should have gone with the MATHEMATICAL MONOSPACE characters for my plain text title. Alas, HN strips them. Demo in https://temp.chrismorgan.info/2026-08-02-titles.html. Doesn’t look any good for me with my specific fonts, would look better for some people.
I would really strongly prefer titles to work the same way they do in html, which means plain text. Why should feed titles need a different standard than html titles?
There is precedent. The HTML title element cannot contain markup. Titles may be cited in many places and formatting may not be available. If a title requires formatting to convey its meaning it's a bad title.
(Not that I want to defend RSS. In early versions valid RSS wasn't necessarily even valid XML. It is very poor.)
If you publish content, Atom is the superior format. All the parsers support it so there's no argument there against using it. You use it, everything should work just fine. There are no real downsides.
The issue with RSS of course is that there is a lot of really crappy and ancient code out there that should have died a long time ago written in languages like PHP, Ruby, etc. by people who did not really care about details. Details like having unambiguous time stamps (what do you mean, you don't live in my time zone?), or details like "this text is not encoded in UTF-8 but in my unspecified locale specific ASCII variant" (why?!). Or indeed "this description contains malformed tag soup with some of the tags escaped".
Also, while most modern RSS and Atom parsers are pretty decent, it's not that hard to find feeds that still have parsing issues despite these frameworks giving it their best effort. Part of the reason is that the code that generates these feeds is a lot less well covered by frameworks. Lots of content management systems out there that use some wonky templating, home grown scripts, or other improvised shit to generate their feeds. That always was the biggest problem.
Grouping PHP and ruby together like that betrays some profound ignorance. I’m trying to understand how someone could come to utter such nonsensical drivel but honestly nothing is coming to me.
That's important and will break the walled gardens, and will change money flows I suspect as advertising revenue is more equitably shared with content providers, who themselves can be better paid for content produced and content promised. It's the 'ol centralization <> decentralization swinging back and forth again.
> Gabriel offers the examples of the adoption of C over Lisp, Unix over Lisp machines and VMS, and x86 over reduced instruction set computers as examples of technically worse solutions defeating more elegant ones by arriving to market first.
Even (especially?) as a person that appreciates Lisp, Lisp losing this fight twice is kind of funny.
Wonder if it’s going to happen an nth time with Guix vs Nix
No thanks. We've spent enough decades living in squatter camps built on the ruins of other people's lazy decisions. It's past time to move out now. Worse is worse; worse is shit. And there's nothing endearing or funny about Winer's bad behaviour.
I used to be on Dave Winer's scripting-news mailing list, and then somebody posted a request to be removed, so he removed them in a huff and then complained about how they hurt his feelings to the rest of the mailing list (not that they spammed the list, but that he was insulted they wanted off).
After that, I was afraid to ask him to remove me too! I think I finally just moved on to another email address.
There's supposed to be a mailing-list-name-REQUEST email address just for administrative questions like that, but so many people now don't even know or support that, and just send removal requests to the whole list. Instead of complaining about people asking the whole mailing list to be removed, there's a much better passive aggressive strategy:
My favorite instance of emergent mailing list behavior was when a trouble maker named GUMBY created a "PLEASE-REMOVE-ME" mailing list, just for people who sent email to another entire mailing list asking to be removed from it, instead of sending their request to the administrator at mailing-list-name-REQUEST.
Whenever somebody would make that faux-pas, he'd add them to the PLEASE-REMOVE-ME mailing list, and the emergent behavior was that those people would discuss amongst themselves the fact that they really wanted to be removed from the PLEASE-REMOVE-ME mailing list, until they eventually learned that the way to get removed from a mailing list was to simply send email to PLEASE-REMOVE-ME-REQUEST, instead of the entire mailing list.
Most of the online content I consume comes to me either via RSS or Atom (I don't have numbers on the split). Not once have I thought - "Gosh darn it, this blog uses RSS instead of Atom, even though Atom is so obviously the better choice. Now I don't even want to add this blog to my feed." ...
I don't think this article is aimed at consumers, but at developers who might have to write parsers, or people who are trying to decide what feed format to use for their own content.
Though you might be upset about RSS being used when your reader screws up with it, because some things are difficult to interpret. Of course, you won't know why it screws up, and you'll probably blame the person who wrote the feed, not the format itself.
As a concrete example: I have been frustrated by title encoding issues on CSS-Tricks (HTML tag names getting broken) multiple times, which would never have occurred if they just used Atom instead of RSS.
It is XML, so not all HTML5 is allowed. You would have to convert your HTML5 to XHTML5. Possible but harder than string-concatenation.
It requires full self links, so you must put your domain name in there as relative links would be an error. When using a static generator, why should I care where the files are published?
My website has valid Atom feeds. Still, it's an annoying format to me.
You don't have to convert anything to XHTML5. You only need to do that if you specify type="xhtml" on an element, but you can use="html" and escape the markup. RSS has this behaviour too, but it's spelled out better in Atom.
I suspect you've been making your lifeIfe difficult for no good reason.
> why should I care where the files are published?
You don't, but those consuming your feed do. You do it for their benefit.
And those three ways to encode a title. Do I really imagine that every parser is going to undo the double-encoding correctly? Or XHTML conversion if I use a namespace prefix?
I remember ( I may be very wrong ) eventually RSS and Atom became one and the same thing for consumer and that all RSS reader would parse Atom feed, RSS became the logo and the name people know, atom was used behind the scene.
Apart from iTunes, as the article said.
It has been 20+ years I do hope someone on HN can now spills the beans as to why.
There are so many formats and standards and people using different sets of them that I feel like we need an organisation that selects some of them and decides that those are the ones that people should use.
Everyone could become a member of that organisation and vote for which standards should be part of the next version of the selected set.
Maybe there could be a new version every other year or something.
This would give us some kind of leader that shows the way.
It would make it easier for developers if people were more focused on fewer standards and there would be a well defined point in time when we would upgrade to the new set of standards.
For those of you who are familiar with RISC-V, it would be like the RVA23 spec: one big collection of things to use that can be targeted and talked about as one thing with one name, rather than everyone having their own collection of extensions that they use.
- since we are on the topic i got a question for you
- what is the best way to store rss data inside postgres
- will you store it as raw xml directly? or will you process it and store it?
- what format will you store it as if stored inside postgres?
- how will you handle updates to the feed? rss doesnt do websocket push as far as i can tell so you have to poll which gives you the entire feed with a few items removed and a few new items added in the best case scenario. how do you diff this for storing?
If you're building a RSS reader, you'd probably want to process the data and store all relevant fields as columns for storage. Not much point to storing the XML.
Entries in feeds should have a guid you can use to detect updates/entries you have already seen. RSS readers typically don't delete entries that disappeared from the feed - entries disappear from feeds to limit their size.
You can get live updates to some RSS feeds using WebSub.
Absolutely store the raw data. For the reasons you state.
But also store derived data. Titles, authors, dates, article texts. You need those for whatever your application does. You don't want your application logic to be working with the raw text.
> how will you handle updates to the feed?
When polling, consider using HTTP HEAD to check for changes before GET.
What you do when an article ID reappears with different content, that up to you. I think readers usually replace the old entry with the new content, silently. But it's not the only option.
- if you split the rss document into its "items" i am not sure if you can store each item separately inside postgres using that XML data type
- if you store the whole document, you end up with a problem when say the feed partially updates after a few minutes
- one suggestion i hear from r/PostgreSQL is that you store the XML blob somewhere else like hstore or something and somehow index it back to postgres. I wonder how that works conceptually / architecturally speaking
The data is probably small enough and infrequently updated such that almost anything will work. If you split the items then you would have a separate episodes table with one row per episode joined to the podcasts table. If you store the whole XML in a row then you can overwrite the row when the feed changes. Doing the parsing and splitting into episodes in DB sounds better to me because your clients will otherwise constantly be repeating that work.
For that purpose, you’re perfectly well off just leaving it as an opaque blob; compress, base64 encode and stuff it into a string/varbinary column and call it a day.
You don’t even need to store it in pg itself; stuff it into a cheaper datastore like s3 and just have the locations stored in pg.
The only thing to optimize for is cost & storage. Access/retrieval doesn’t matter for a once in 6 months process.
Also what is this revolting formatting strategy you’ve found?
A reader does things in realtime. You don't care what happened 6 months ago. If you did something 6 months ago you don't want to gaslight the user by pretending you did something different 6 months ago.
I don't care about the internal format. What I'm missing is an active component. Instead of re-downloading the same thing over and over it should work like POP3.
Who remembers when everybody was syndicating all their favorite RSS feeds on their own blogs, and then some joker posted a blog entry to his own RSS feed with a title like "What happens when you put an unbalanced <BLINK> tag into the title?", and the ENTIRE BLOGOSPHERE started blinking?
The content of that notorious discussion went on and off and on and off for weeks, giving all the netizens of the RSS community blogosphere terrible headaches, with people's entire blogs disappearing and reappearing every second, until it finally reached a flashing point, when Dave Winer humbly conceded that it wasn't the user's fault for being an idiot, and maybe just maybe there was tiny teeny little design flaw in RSS, and it wasn't actually such a great idea to allow HTML tags in RSS titles.
Unless they are building a podcast application which is predominantly RSS 2.0 based with some extensions from itunes and others to provide additional podcast-specific metadata such as episode and season information.
Not relevant to the overall discussion, but this VHS vs Betamax thing is actually a myth, borne from confusing Betamax (a home consumer version, comparable and inferior to VHS) with Betacam (a professional format, which could use the same physical tapes as Betamax, albeit at much shorter runtimes so not suitable for movies).
What? Not at all. RSS is a product category. Many RSS feeds are, if you look into them, Atom. Your RSS reader just doesn't bother to tell you, because why would you care?
Try putting a Betamax tape into a VHS VCR and see if you can watch it.
To extend the metaphor though. An RSS reader that works with atom is the same as a VHS player that also has a beta max player. Or your blueray player that plays dvds and CDs....
> To extend the metaphor though. An RSS reader that works with atom is the same as a VHS player that also has a beta max player.
An RSS reader that works with atom is the same as a VCR that will play VHS and Betamax cassettes out of the same physical slot, in a world where videocassettes are sold with no indication of which format they've been printed in, and they're all the same shape, and there are no VCRs that can fail to play either format.
> Or your blueray player that plays dvds and CDs....
Which, yes, is a lot like this, but absolutely nothing like VHS vs Betamax.
This is like pointing at the monitor of a desktop computer and saying, "that's the computer". It is effective to communicate with people who aren't interested in computers, but it's also not true and the distinction does have important consequences for behavior. Atom is not RSS even if some feed readers support both and most people don't know what feeds are.
And because of that, and the early popularity and widespread adoption of RSS, the better format (atom) isn't used nearly as much. And calls to increase use of betamax/atom generally went and go unheeded.
> and the early popularity and widespread adoption of RSS, the better format (atom) isn't used nearly as much.
That may have been true 20 years ago, but now that pretty much no-one uses either of them , I'd be surprised if RSS was still meaningfully more widespread than Atom. (Except everything is being called RSS).
Well, the likes of Wordpress make this a bit of a mixed bag. It still publishes multiple feeds in multiple format, with what proports to being an RSS feed actually being a Frankenstein's monster of RSS, Atom, and random other namespaces.
I don't know why they persist in still doing that after all these years.
And I stand with that phrase. I'm pretty sure that are more VHS users than RSS these days. It's not strictly zero, but it's a negligible fraction of internet users.
I don't disagree. But I would also assert the absolute number of RSS users is probably higher than it has ever been. And that's what matters, not what "most people do" now that there are far more non-technical users on the internet than ever before.
As far as I can ascertain, and as I described in the last section of this article, they never actually supported it meaningfully. I believe that the iTunes client got Atom support, but not the iTunes Music Store, and that was the part that actually mattered.
Not every programming language I use can output RSS/Atom/XML by default, but pretty much all of them can output JSON natively, no library needed, just fine. The spec is short and easy to understand, to the point it’s little effort to manipulate the feeds, adding to them or consuming them even without a dedicated reader if need be.
To consume other people’s feeds, I mostly don’t care what format they are as long as my reader can understand them. To generate my feeds, I always use JSON. Most of them are for personal use, but even for those which aren’t, I never had any complaints (most feed readers seem to be able to read those just fine).
XSLT 3 (via XPath 3.1) has support for maps, arrays, and parsing JSON to/from those or an XML representation. The XML representation is easier to work with in 3.
There's a draft version of XSLT 4 that Saxon supports which adds more capabilities for working with map and array types.
I guess it's like you can't transform XML with JSON-T :)
Seriously, yes, the really old XSLT does not support JSON. But these days it is much easier to find tools that read or write JSON than to find decent XML support.
That’s not something I care about, though. I don’t mean to imply that JSON feeds are objectively superior to RSS and Atom, I just mean to share what my personal observations are, which might be useful to someone else too.
I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow.
In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt away.
In my humble opinion, JSON feed (https://www.jsonfeed.org/version/1.1/) is the most practical format. By a small margin, but still...
- it's really simple and doesn't use XML
- it doesn't allow stupid things like HTML in titles (which I guarantee >50% of all implementations can't handle correctly)
- JSON Feed allows feeds to have a <favicon> and a (square!) <icon>, which is a very practical thing for readers. You can use the <favicon> in lists of feeds, and the <icon> to present a single feed. Atom has a small square icon and a <logo> which is supposed to use a 2:1 aspect ratio. 2:1 is completely useless. No site has a logo in 2:1. It's also useless for most full-name logos, like 'New York Times'. (RSS is, of course, even worse; it doesn't even recommend an aspect ratio, practically guaranteeing that RSS readers can look bad)
You can see that JSON feed has been designed from a feed consumer's point of view: what does an RSS reader need to make a feed look good? While Atom and RSS have been written from an abstract publisher's point of view, making everything possible and allowing maximum flexibility. Especially RSS, which has shown its flexibility in becoming the de facto format for podcasts. And both Atom and RSS are really old, written at a time when it probably wasn't clear how RSS would eventually be used.
In the end, no matter which format a feed uses, users won't notice any difference (as long as publishers are smart enough to use square images!). So any feed is a win, no matter whether RSS, Atom, or JSON feed.
Consider the title of my article: “Atom is better than RSS, in ways that matter”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.)
We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles? When you look at titles that get used on platforms like YouTube, there’s obviously a desire for formatting. People use Unicode shenanigans to work around the deficit frequently. (And they do so in ways that are mostly only available for the English script, quite inequitable for other scripts.) Even if you were to restrict it to ASCII, people GLEEFULLY abuse capital letters FOR EMPHASIS!!!!1!
Especially once you get to coding topics, titles need to support <code>, which is important semantics.
(My biggest disappointment with Atom is that text constructs are single-type-only. I wish you could provide distinct text and HTML representations, like email does with the multipart/alternative MIME type. In some places where I use <code> in titles, I’d just drop the <code>…</code> wrapping, in other places I’d turn it into `…`.)
I will write a proper article about all this some time soonish, encouraging people to use markup in titles.
> We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles?
1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers that don't support the same subset. No renderer can allow it completely (<script>...). HTML sanitation/injection becomes a much bigger problem when it's not limited to a text body that can be relatively easily sandboxed.
2. If you allow every feed to define its own font style or even color, that makes a list of posts look like a 2005 MySpace page. :)
It is producing bad UIs. Renderers can't really render it as plain text, as they might lose a part of the meaning. But they also can't really allow it because it might make their output look like trash. In the end, that would force renderers to develop complex heuristics of which elements and styles to allow, which to modify (do your HTML titles support dark mode? accessibility?), and which to filter out.
3. I don't see the practical value of having <code> in a headline. If it shouldn't be rendered in a different way for obvious reasons, and XML is not designed for human consumption, what is it good for? Who is the consumer of the <code> tag? AI?
Here’s an example of <code> in titles being quite valuable: https://chrismorgan.info/blog/make-and-git-diff-test-harness....
Inferior plain text: Using make and git diff for a simple and powerful test harness
Better plain text: Using `make` and `git diff` for a simple and powerful test harness
Better HTML: Using <code>make</code> and <code>git diff</code> for a simple and powerful test harness
I use the second for the <title> and og:title on my site, and the third in the <h1> and feeds. It will unfortunately be turned into the first by some feed readers, but that’s their problem. (Some feed readers do accept a subset of HTML phrasing content.)
> If it shouldn't be rendered in a different way for obvious reasons
I don’t perceive your obvious reasons.
I agree that it makes sense on that page. But only because the rendering of the page is completely under the control of the author, and the page shows only that one page. It's different if the text is rendered by an RSS reader in a different context. You don't know the font, color, or text weight it is rendered with in an RSS reader (which also depends on the context, like unread posts being bold). Imagine the same title in a list of post titles. I think it would stick out and make the list much harder to read.
> Imagine the same title in a list of post titles.
Sounds wonderful. I think you aren’t realising that it’s already easy to abuse this stuff, with uppercase and exotic Unicode letters <https://yaytext.com/> and such. But people don’t abuse it in feeds.
I’m not talking about allowing <font face=Impact style=color:red>, just some relevant semantic HTML elements like <code>, <em> and <kbd>, which are pretty harmless to add, and useful.
Perhaps I should have gone with the MATHEMATICAL MONOSPACE characters for my plain text title. Alas, HN strips them. Demo in https://temp.chrismorgan.info/2026-08-02-titles.html. Doesn’t look any good for me with my specific fonts, would look better for some people.
If html in titles were an opt-in feature from the beginning none of this discussion would be happening
I would really strongly prefer titles to work the same way they do in html, which means plain text. Why should feed titles need a different standard than html titles?
There is precedent. The HTML title element cannot contain markup. Titles may be cited in many places and formatting may not be available. If a title requires formatting to convey its meaning it's a bad title.
(Not that I want to defend RSS. In early versions valid RSS wasn't necessarily even valid XML. It is very poor.)
Because the title appears next to a bunch of other titles.
It should be consistent, or else compromise browsing.
The content has no such situation.
If you publish content, Atom is the superior format. All the parsers support it so there's no argument there against using it. You use it, everything should work just fine. There are no real downsides.
The issue with RSS of course is that there is a lot of really crappy and ancient code out there that should have died a long time ago written in languages like PHP, Ruby, etc. by people who did not really care about details. Details like having unambiguous time stamps (what do you mean, you don't live in my time zone?), or details like "this text is not encoded in UTF-8 but in my unspecified locale specific ASCII variant" (why?!). Or indeed "this description contains malformed tag soup with some of the tags escaped".
Also, while most modern RSS and Atom parsers are pretty decent, it's not that hard to find feeds that still have parsing issues despite these frameworks giving it their best effort. Part of the reason is that the code that generates these feeds is a lot less well covered by frameworks. Lots of content management systems out there that use some wonky templating, home grown scripts, or other improvised shit to generate their feeds. That always was the biggest problem.
Grouping PHP and ruby together like that betrays some profound ignorance. I’m trying to understand how someone could come to utter such nonsensical drivel but honestly nothing is coming to me.
Both really need an explicit "Full/Partial" flag.
Over-polling is also a problem with both formats.
But the Local-First Fediverse is evolving. https://share.gemini.google/NHjiUHtpRTiJ
That's important and will break the walled gardens, and will change money flows I suspect as advertising revenue is more equitably shared with content providers, who themselves can be better paid for content produced and content promised. It's the 'ol centralization <> decentralization swinging back and forth again.
I agree with Gemin— wait. Did you just post a link to google.com to support an argument for self-hosting, decentralization and breaking monopolies...?
> 403. That’s an error.
> Your client does not have permission to get URL /share/d8748f435799 from this server. That’s all we know.
What's this link meant to be about?
https://share.gemini.google/aHYGlJzhFHSx
https://imgur.com/PQICt6I
RSS or Atom - do they indicate whether they are providing a full or partial feed?
What is federated content?
Can the Fediverse be local-first?
Didn't we get enough of this fight 20 years ago? Let's not piss off Dave Winer again. Reminder: https://en.wikipedia.org/wiki/Worse_is_better
> Gabriel offers the examples of the adoption of C over Lisp, Unix over Lisp machines and VMS, and x86 over reduced instruction set computers as examples of technically worse solutions defeating more elegant ones by arriving to market first.
Even (especially?) as a person that appreciates Lisp, Lisp losing this fight twice is kind of funny.
Wonder if it’s going to happen an nth time with Guix vs Nix
Worse is better isn't about first to market, it was about simpler beating correct.
No thanks. We've spent enough decades living in squatter camps built on the ruins of other people's lazy decisions. It's past time to move out now. Worse is worse; worse is shit. And there's nothing endearing or funny about Winer's bad behaviour.
Isn't this just VHS v Betamax again?
While a worse format surely could have won something like the video wars, it doesn't seem that VHS was in fact the worse format overall: https://www.youtube.com/watch?v=FyKRubB5N60 (Part 2: https://www.youtube.com/watch?v=v019trxfcmg . Quality comparison: https://www.youtube.com/watch?v=_oJs8-I9WtA ) Beta was basically optimised for one thing, reasonable cassette size, and the tradeoffs turned out probably not to be worth it.
Moreover, the VHS cassete itself is arguably a better design! https://www.youtube.com/watch?v=hWl9Wux7iVY
Only the porn industry can answer that question.
Contrary to the popular belief, you can get porn on Atom.
At least you don't get fined for forgetting to rewind you Atom feed.
Do video cassette recorders and players support both VHS and Betamax?
Because essentially all feed readers support both Atom and RSS.
I used to be on Dave Winer's scripting-news mailing list, and then somebody posted a request to be removed, so he removed them in a huff and then complained about how they hurt his feelings to the rest of the mailing list (not that they spammed the list, but that he was insulted they wanted off).
After that, I was afraid to ask him to remove me too! I think I finally just moved on to another email address.
There's supposed to be a mailing-list-name-REQUEST email address just for administrative questions like that, but so many people now don't even know or support that, and just send removal requests to the whole list. Instead of complaining about people asking the whole mailing list to be removed, there's a much better passive aggressive strategy:
My favorite instance of emergent mailing list behavior was when a trouble maker named GUMBY created a "PLEASE-REMOVE-ME" mailing list, just for people who sent email to another entire mailing list asking to be removed from it, instead of sending their request to the administrator at mailing-list-name-REQUEST.
Whenever somebody would make that faux-pas, he'd add them to the PLEASE-REMOVE-ME mailing list, and the emergent behavior was that those people would discuss amongst themselves the fact that they really wanted to be removed from the PLEASE-REMOVE-ME mailing list, until they eventually learned that the way to get removed from a mailing list was to simply send email to PLEASE-REMOVE-ME-REQUEST, instead of the entire mailing list.
Worked like a charm!
Most of the online content I consume comes to me either via RSS or Atom (I don't have numbers on the split). Not once have I thought - "Gosh darn it, this blog uses RSS instead of Atom, even though Atom is so obviously the better choice. Now I don't even want to add this blog to my feed." ...
I don't think this article is aimed at consumers, but at developers who might have to write parsers, or people who are trying to decide what feed format to use for their own content.
Though you might be upset about RSS being used when your reader screws up with it, because some things are difficult to interpret. Of course, you won't know why it screws up, and you'll probably blame the person who wrote the feed, not the format itself.
As a concrete example: I have been frustrated by title encoding issues on CSS-Tricks (HTML tag names getting broken) multiple times, which would never have occurred if they just used Atom instead of RSS.
Atom is correct to a degree that is annoying.
It is XML, so not all HTML5 is allowed. You would have to convert your HTML5 to XHTML5. Possible but harder than string-concatenation.
It requires full self links, so you must put your domain name in there as relative links would be an error. When using a static generator, why should I care where the files are published?
My website has valid Atom feeds. Still, it's an annoying format to me.
You don't have to convert anything to XHTML5. You only need to do that if you specify type="xhtml" on an element, but you can use="html" and escape the markup. RSS has this behaviour too, but it's spelled out better in Atom.
I suspect you've been making your lifeIfe difficult for no good reason.
> why should I care where the files are published?
You don't, but those consuming your feed do. You do it for their benefit.
And those three ways to encode a title. Do I really imagine that every parser is going to undo the double-encoding correctly? Or XHTML conversion if I use a namespace prefix?
… yes? It’s simple XML parsing, and then taking it as text, serialised HTML, or an already-parsed DOM tree. You are using an actual XML parser, right?
In most environments it’s no harder, and in browsers themselves (which is where half of it is consumed) it’s arguably easier.
the DOM tree is going to say either html:code or {http://something}code neither of which is just code.
When an XML document contains HTML, the DOM representation is of elements in the http://www.w3.org/1999/xhtml namespace.
When you parse a document or fragment that is in HTML syntax, the DOM representation is of elements in the http://www.w3.org/1999/xhtml namespace.
There is no difference.
Hope your parser implements all this correctly!
I remember ( I may be very wrong ) eventually RSS and Atom became one and the same thing for consumer and that all RSS reader would parse Atom feed, RSS became the logo and the name people know, atom was used behind the scene.
Apart from iTunes, as the article said.
It has been 20+ years I do hope someone on HN can now spills the beans as to why.
I think literally 90% of people that know RSS, if you ask them what Atom is, they will probably reply RSS.
I liked thought the article as I never deep dived in the differences
The three ways of encoding the string "<xmp>" in the title all look like awful gibberish to me.
Wait till you see the HTML I had to write to get them!
There are so many formats and standards and people using different sets of them that I feel like we need an organisation that selects some of them and decides that those are the ones that people should use. Everyone could become a member of that organisation and vote for which standards should be part of the next version of the selected set. Maybe there could be a new version every other year or something.
This would give us some kind of leader that shows the way. It would make it easier for developers if people were more focused on fewer standards and there would be a well defined point in time when we would upgrade to the new set of standards.
For those of you who are familiar with RISC-V, it would be like the RVA23 spec: one big collection of things to use that can be targeted and talked about as one thing with one name, rather than everyone having their own collection of extensions that they use.
> I’m choosing not to encode > as >: neither HTML nor XML syntax requires it.
TIL, I never questioned encoding >
Perhaps because encoding < but not > makes the code significantly more confusing and less readable.
- since we are on the topic i got a question for you
- what is the best way to store rss data inside postgres
- will you store it as raw xml directly? or will you process it and store it?
- what format will you store it as if stored inside postgres?
- how will you handle updates to the feed? rss doesnt do websocket push as far as i can tell so you have to poll which gives you the entire feed with a few items removed and a few new items added in the best case scenario. how do you diff this for storing?
If you're building a RSS reader, you'd probably want to process the data and store all relevant fields as columns for storage. Not much point to storing the XML.
Entries in feeds should have a guid you can use to detect updates/entries you have already seen. RSS readers typically don't delete entries that disappeared from the feed - entries disappear from feeds to limit their size.
You can get live updates to some RSS feeds using WebSub.
- the idea behind storing the raw feed items instead of processed ones is
- what happens if your processing logic changes 6 months down the line?
- for example today you decide you want to remove all extra spaces and lowercase all titles before storing them
- 6 months down the line you want to revert, what now?
Absolutely store the raw data. For the reasons you state.
But also store derived data. Titles, authors, dates, article texts. You need those for whatever your application does. You don't want your application logic to be working with the raw text.
> how will you handle updates to the feed?
When polling, consider using HTTP HEAD to check for changes before GET.
What you do when an article ID reappears with different content, that up to you. I think readers usually replace the old entry with the new content, silently. But it's not the only option.
so how do you store raw xml data in postgres?
There is a datatype, if the XML is correct: https://www.postgresql.org/docs/current/datatype-xml.html
As text or XML column type. IME a document store or columnar backend is significantly cheaper if you're not querying it from SQL.
- there is definitely one dilemma here
- if you split the rss document into its "items" i am not sure if you can store each item separately inside postgres using that XML data type
- if you store the whole document, you end up with a problem when say the feed partially updates after a few minutes
- one suggestion i hear from r/PostgreSQL is that you store the XML blob somewhere else like hstore or something and somehow index it back to postgres. I wonder how that works conceptually / architecturally speaking
The data is probably small enough and infrequently updated such that almost anything will work. If you split the items then you would have a separate episodes table with one row per episode joined to the podcasts table. If you store the whole XML in a row then you can overwrite the row when the feed changes. Doing the parsing and splitting into episodes in DB sounds better to me because your clients will otherwise constantly be repeating that work.
Pg can do array columns, though I don't think it's a good fit for common use cases
For that purpose, you’re perfectly well off just leaving it as an opaque blob; compress, base64 encode and stuff it into a string/varbinary column and call it a day.
You don’t even need to store it in pg itself; stuff it into a cheaper datastore like s3 and just have the locations stored in pg.
The only thing to optimize for is cost & storage. Access/retrieval doesn’t matter for a once in 6 months process.
Also what is this revolting formatting strategy you’ve found?
A reader does things in realtime. You don't care what happened 6 months ago. If you did something 6 months ago you don't want to gaslight the user by pretending you did something different 6 months ago.
For polling, the ultimate test is whether Rachel likes it. Check this and her other posts: https://rachelbythebay.com/w/2026/02/23/readers/
I don't care about the internal format. What I'm missing is an active component. Instead of re-downloading the same thing over and over it should work like POP3.
Who remembers when everybody was syndicating all their favorite RSS feeds on their own blogs, and then some joker posted a blog entry to his own RSS feed with a title like "What happens when you put an unbalanced <BLINK> tag into the title?", and the ENTIRE BLOGOSPHERE started blinking?
The content of that notorious discussion went on and off and on and off for weeks, giving all the netizens of the RSS community blogosphere terrible headaches, with people's entire blogs disappearing and reappearing every second, until it finally reached a flashing point, when Dave Winer humbly conceded that it wasn't the user's fault for being an idiot, and maybe just maybe there was tiny teeny little design flaw in RSS, and it wasn't actually such a great idea to allow HTML tags in RSS titles.
What about activitypub? I thought that was the new format to use..
The article is correct. Anyone who knows what they’re doing builds an Atom feed, not RSS. In fact, I thought this was common knowledge a decade ago.
Unless they are building a podcast application which is predominantly RSS 2.0 based with some extensions from itunes and others to provide additional podcast-specific metadata such as episode and season information.
Yes, except for podcasts.
Atom is better than RSS in the way Betamax was better than VHS. With the same outcome and consequences for practical use.
Not relevant to the overall discussion, but this VHS vs Betamax thing is actually a myth, borne from confusing Betamax (a home consumer version, comparable and inferior to VHS) with Betacam (a professional format, which could use the same physical tapes as Betamax, albeit at much shorter runtimes so not suitable for movies).
As in we now use neither?
What? Not at all. RSS is a product category. Many RSS feeds are, if you look into them, Atom. Your RSS reader just doesn't bother to tell you, because why would you care?
Try putting a Betamax tape into a VHS VCR and see if you can watch it.
To extend the metaphor though. An RSS reader that works with atom is the same as a VHS player that also has a beta max player. Or your blueray player that plays dvds and CDs....
> To extend the metaphor though. An RSS reader that works with atom is the same as a VHS player that also has a beta max player.
An RSS reader that works with atom is the same as a VCR that will play VHS and Betamax cassettes out of the same physical slot, in a world where videocassettes are sold with no indication of which format they've been printed in, and they're all the same shape, and there are no VCRs that can fail to play either format.
> Or your blueray player that plays dvds and CDs....
Which, yes, is a lot like this, but absolutely nothing like VHS vs Betamax.
Atom is a response to not wanting to support backwards compatibility like RSS does in order to improve things. https://web.archive.org/web/20080216234454/http://www.sixapa... It's explicitly a different thing.
This is like pointing at the monitor of a desktop computer and saying, "that's the computer". It is effective to communicate with people who aren't interested in computers, but it's also not true and the distinction does have important consequences for behavior. Atom is not RSS even if some feed readers support both and most people don't know what feeds are.
And because of that, and the early popularity and widespread adoption of RSS, the better format (atom) isn't used nearly as much. And calls to increase use of betamax/atom generally went and go unheeded.
Which of the nine incompatible versions of RSS supports backwards compatibility? https://web.archive.org/web/20110726002019/http://diveintoma...
> and the early popularity and widespread adoption of RSS, the better format (atom) isn't used nearly as much.
That may have been true 20 years ago, but now that pretty much no-one uses either of them , I'd be surprised if RSS was still meaningfully more widespread than Atom. (Except everything is being called RSS).
https://news.ycombinator.com/item?id=49141336 is the only valid response to your VHS/Betamax comparison, really.
Well, the likes of Wordpress make this a bit of a mixed bag. It still publishes multiple feeds in multiple format, with what proports to being an RSS feed actually being a Frankenstein's monster of RSS, Atom, and random other namespaces.
I don't know why they persist in still doing that after all these years.
I use RSS multiple times daily.
And you're also on HN, you're not exactly the average human being.
Do you use “RSS” as a protol specifically, or do you use “RSS” as in “any feed no matter the protocol”?
I was responding to the generic comment that:
> pretty much no-one uses either of them
And I stand with that phrase. I'm pretty sure that are more VHS users than RSS these days. It's not strictly zero, but it's a negligible fraction of internet users.
I don't disagree. But I would also assert the absolute number of RSS users is probably higher than it has ever been. And that's what matters, not what "most people do" now that there are far more non-technical users on the internet than ever before.
One person using something doesn't mean it's popular.
What can I say - its popular with me! Its also well supported, so that's something.
But by that standard Betamax was popular too…
I don't use Betamax, nor is it well supported.
> This is like pointing at the monitor of a desktop computer and saying, "that's the computer".
Referring to an atom feed as an "RSS feed" is exactly equivalent to bringing Hydrox cookies to a potluck and hearing someone call them "Oreos".
huh, I call the atom feed on my site an atom feed. I wonder if that confuses people...
Yes, obviously it will.
What a bitchy reply
tl;dr
Atom can do < or & in titles, and offer both a summary and the full text.
Some podcast apps (Apple Podcasts) don't support Atom, so then plain RSS is better.
So it doesn't really matter that much.
> Some podcast apps (Apple Podcasts) don't support Atom, so then plain RSS is better.
Apple Podcasts stopped supporting Atom (sadly) a few years ago:
* https://podcasters.apple.com/4115-technical-updates-for-host...
Not sure why they decided to do so (lack of volume/traffic?).
As far as I can ascertain, and as I described in the last section of this article, they never actually supported it meaningfully. I believe that the iTunes client got Atom support, but not the iTunes Music Store, and that was the part that actually mattered.
Personally, I don’t care at all since we’ve gotten JSON feeds.
https://en.wikipedia.org/wiki/JSON_Feed
Not every programming language I use can output RSS/Atom/XML by default, but pretty much all of them can output JSON natively, no library needed, just fine. The spec is short and easy to understand, to the point it’s little effort to manipulate the feeds, adding to them or consuming them even without a dedicated reader if need be.
To consume other people’s feeds, I mostly don’t care what format they are as long as my reader can understand them. To generate my feeds, I always use JSON. Most of them are for personal use, but even for those which aren’t, I never had any complaints (most feed readers seem to be able to read those just fine).
But JSON doesn’t allow you to run it through an XSLT and get a normal webpage out of it, does it?
XSLT 3 (via XPath 3.1) has support for maps, arrays, and parsing JSON to/from those or an XML representation. The XML representation is easier to work with in 3.
There's a draft version of XSLT 4 that Saxon supports which adds more capabilities for working with map and array types.
I guess it's like you can't transform XML with JSON-T :)
Seriously, yes, the really old XSLT does not support JSON. But these days it is much easier to find tools that read or write JSON than to find decent XML support.
Apparently it does.
https://stackoverflow.com/a/49011455
That’s not something I care about, though. I don’t mean to imply that JSON feeds are objectively superior to RSS and Atom, I just mean to share what my personal observations are, which might be useful to someone else too.
sfeed and newsboat don't support it, though. I do note that elfeed does.