I hate RSS. It’s a bad format that developed organically in all the worst ways, and it should have died completely in favour of Atom by about twenty years ago. I started a draft describing some of the problems that actually matter (thing that can’t be represented reliably in RSS, and such) in <https://chrismorgan.info/atom%3Erss>.
And so I wish people would stop calling feeds RSS, because it continues to compound the problem. Let RSS die! More than once I’ve seen people implement RSS feeds, at great pain and often with errors, simply because they hadn’t heard of Atom.
(I still need to decide which spec I hate more, RSS or OpenGraph. Hmm… RSS had more excuses for being bad, OpenGraph was just a spectacularly bad thing thrown over the wall by a company that should have known better. I drafted something examining how comprehensively bad it was some years ago, I should put it onto my new site and continue it at some point.)
dewey [3 hidden]5 mins ago
Having structured feeds of any kind is already a niche and much appreciated when it happens. How to call them correctly technically based on some specs is not the hill to die on.
We call them RSS feeds, RSS reader apps even if it might be implemented as an Atom feed.
chrismorgan [3 hidden]5 mins ago
The reason I think it matters is that, because people keep on using the name of the wrong format, people keep on using that wrong format when they want to implement feeds. Where if they had known about Atom, or that podcast feeds are the only reason not to use Atom, they would gladly have used Atom.
sjs382 [3 hidden]5 mins ago
Flashback to a memorable bug report complaining that "the JPEGs I'm uploading don't work" but upon further investigation, they were trying to upload HEIC photos. The field was explicit about the formats supported, but to this user, "JPEGs" just meant "images".
F3nd0 [3 hidden]5 mins ago
I have trouble seeing how that helps anyone. It’s not like ‘RSS’ is a widespread term the way ‘Word’ or even ‘Mastodon’ are (and even there I’d argue it’s worthwhile to use technically more correct terms). Why not just use ‘news feed’ as the general term? If you don’t care about the protocol in the first place, that’s far more descriptive and correct, no?
dewey [3 hidden]5 mins ago
Because if you say "News feed" people are thinking Facebook or Twitter feed. RSS is widely known as it was already integrated in browsers before as a "RSS" button if the site advertised that in the html head.
F3nd0 [3 hidden]5 mins ago
I should think that’s a pretty niche memory among people who browse the internet nowadays, but then I only have anecdotal evidence, so I could be underestimating it. Even so, I think conflating a general type with a format specification is not a good idea overall.
ymolodtsov [3 hidden]5 mins ago
RSS is the only widespread enough name for this thing. Where you're correct is that it's silly to argue about the name of the format used by approximately three people.
I'm not too serious here but even many news media publications are just dropping it, or separate into dozens of unconnected feeds.
8organicbits [3 hidden]5 mins ago
I don't think this is helpful. The last statistic I saw put RSS at 77% of the web feed market share, higher than Atom. In the web feed market it isn't a protocol on the way out, its the dominant protocol.
While RSS is tricky to parse in practice, many of the challenges are due to invalid feeds, which Atom is not invulnerable to. Its very likely that there is a well-tested feed parser for your favorite programming language, so most developers using feed programmatically don't need to handle those challenges themselves.
For concerns like title encoding or summary vs full text description, you can handle those using namespaces. If you don't like any of the existing namespaces that do that you can create your own.
F3nd0 [3 hidden]5 mins ago
Thank you; that was a fun read! I had read that Atom was generally regarded as the technically superior format, but your article (and the links you helpfully provided therein) made it much more apparent why that is the case. :-)
Arshad-Talpur [3 hidden]5 mins ago
I think they are alive just because they are rough and weired
jjordan [3 hidden]5 mins ago
Wow, what timing. Not to shill, but I'm also nearly done building a directory of RSS feeds. It stemmed from a frustration of outdated and broken RSS feed collections, and the long slow death of the orange RSS subscribe button across the web. I'm not officially launched yet but I would love some feedback and maybe some of the RSS feeds that land in your directory can be added to mine.
Pardon the dust. There's an app tie-in that I'm almost done with too, a widget-first app that shows your RSS feed collections on your phone's home screen. It would really be great if we could start to bring about an RSS renaissance!
eleventen [3 hidden]5 mins ago
I generally want a posts/day count on any feed I subscribe to. Many of these are content mills with 20+ posts per day I have no intention in sifting through.
jjordan [3 hidden]5 mins ago
Yeah I'm focused on including more of the Indie Web. I include BBC, NYT, etc. because people expect it, but the directory already has some real depth worth exploring. And each feed details page has a cadence rating to tell you how often they post. So grouping a firehose with a specialty blog that posts 6 times a year probably isn't a good idea, but an OPML full of blogs that post ~monthly would be a delight, IMO.
sixtyj [3 hidden]5 mins ago
Nice.
I have sneaked in.
Suggestions:
White or almost white text would be better.
Make “Add” button visible on homepage.
Make a possibility to batch suggest feeds - a lot of people have opml xml exports from Google Reader so they can give it to you. Processing info would be nice so I as a supplier would immediately know how useful I was.
Move explanatory part of RSS to some other part than homepage.
jjordan [3 hidden]5 mins ago
Hey thanks for taking the time.
"White or almost white text would be better." -- There is some white text, headers and headlines mostly. Did you find the lack of contrast difficult to deal with?
"Make “Add” button visible on homepage." -- you mean like in the search results? That's a fine idea.
"Make a possibility to batch suggest feeds" -- I've been toying with how to handle OPML imports. Definitely a feature to come on the app, but I fear with mass submission on the vault I would be inundated with feeds, and the curation aspect would suffer. I want quality over quantity. But maybe there's a happy middle ground somewhere.
"Move explanatory part of RSS to some other part" -- yeah I guess this might be helpful to someone who doesn't know what RSS is, but then they probably aren't visiting anyway lol I'll give it some thought.
Appreciate it. Thanks again.
dd8601fn [3 hidden]5 mins ago
Claude?
(Not judging, just testing my radar)
jjordan [3 hidden]5 mins ago
Yes, with several months of iteration. I've wanted to build this for years but to get it to the point where it's a quality destination is an effort beyond the time I would have been able to contribute.
dd8601fn [3 hidden]5 mins ago
Sure. I have a few projects like that, myself. Good luck with it.
jjordan [3 hidden]5 mins ago
Thank you
mickeyp [3 hidden]5 mins ago
I love RSS but what I love more than RSS are people who blog about stuff: high concept stuff, day-to-day stuff and just what they did yesterday.
I wish people would blog more like in the old days.
rambambram [3 hidden]5 mins ago
Indeed! I have a selfbuilt RSS reader and interesting blogs without a feed are just saved as a bookmark basically.
I care more about the stories (people call it 'content' nowadays) than about the tech, as long as the tech is open.
mathgladiator [3 hidden]5 mins ago
Im going to be doing this again without an agenda. I am recovering from using AI to write thoughts because now I see and hear the patterns which are becoming obnoxious.
ninjahawk1 [3 hidden]5 mins ago
seeing an emoji in a title on HN really surprised me, I didn’t even know you could do that. Shows how much emotion we use on here lol.
guiambros [3 hidden]5 mins ago
And... it's gone. I guess mods don't like emoji in titles.
Can't blame them; it draws a bit more attention than normal.
RattlesnakeJake [3 hidden]5 mins ago
The last time I tried to use one in a comment, it got stripped out. I guess that doesn't apply to submission titles.
dgellow [3 hidden]5 mins ago
It's generally does!
dudefeliciano [3 hidden]5 mins ago
i guess that only works cause it's a text glyph and not a unicode emoji
edhelas [3 hidden]5 mins ago
If you love RSS, embrace Atom 1.0 :)
Its the final modern form of RSS.
rpdillon [3 hidden]5 mins ago
Yeah, I've been writing software that provides feeds for RSS, but I exclusively use Atom. It's just a better format. It does create ambiguity when using a site like this because I'm not sure if my sites will qualify as having an RSS 2.0 feed or not.
CharlesW [3 hidden]5 mins ago
Atom's problem is that RSS is also the final modern form of RSS.
culi [3 hidden]5 mins ago
Atom was killed by podcasts. Tbh RSS 2.0 is good enough
graemep [3 hidden]5 mins ago
Why is Atom better?
F3nd0 [3 hidden]5 mins ago
There might be other reasons, but chrismorgan linked a nice write-up in a sibling comment:
It's great to see someone else using FeedLand. While it has some quirks, is has some clever ideas, like that blogroll feature.
My favorite part of FeedLand is that you can see who subscribes to a blog and where else they subscribe. This makes RSS feel social, without the algorithmic tricks of traditional social media. Here's the listing for my blog, for example: https://feedland.com/?feedurl=https%3A%2F%2Falexsci.com%2Fbl...
davewiner [3 hidden]5 mins ago
It was designed that way, patterned after social media, where you share all that info. I wanted to see if it would work in RSS, and it came out pretty good.
We're going to have a new version pretty soon, hooking it up with RSS.chat.
rambambram [3 hidden]5 mins ago
Thanks for RSS, sir.
pooploop64 [3 hidden]5 mins ago
Surprisingly cool site. I've seen lots of sites for RSS feeds but they aren't any good because they just dump their mountain of every feed that was ever known to exist, and there's not really any aspects of curation or discovery. RSS feeds themselves embody the exact way I think the internet should work, where the internet itself is the platform. However it's very nice to get some help finding new stuff.
nicole_express [3 hidden]5 mins ago
I'm always surprised how many people who read my blog do so over RSS. It's probably one of my biggest traffic sources. (Definitely due to my niche topic and small reach, but still)
I don't really use RSS myself anymore, though; not since I stopped using Google Reader a few months before they pulled the plug. Wouldn't even know where to start nowadays.
oalders [3 hidden]5 mins ago
I'm quite happy with NetNewsWire.
dgellow [3 hidden]5 mins ago
HN renders emojis in color?! I’m reading that on an iPad and see a red heart. That’s a first
clickety_clack [3 hidden]5 mins ago
I only have a fairly basic understanding of encodings, but is this one by any chance in one of the smaller “standard” character sets and not in the huge Unicode “emoji” set?
deathanatos [3 hidden]5 mins ago
UTS #51 is your friend.
There's not really a "standard" character set and an "emoji" one. There is an emoji block (U+1F600 to U+1F64F), and this heart (U+2665) is not in that. But this heart is an emoji, in that the data file emoji-data.txt for contains `Emoji=Yes` ("=Yes for characters that are emoji", —UTS #51) for this character. However, this heart has `Emoji_Presentation=No`, which "=Yes for characters that have emoji presentation by default" (—UTS #51).
So basically, it should present, by default, in its non-emoji appearance. (Though there seem to be a number of readers for whom that isn't true. I think that's macOS being badly behaved.) There are some characters that can flip/flop between a "text" (normal monochrome) presentation and an emoji presentation; all of the card suit characters are. Unadorned (e.g., just U+2665 alone) then, you have to follow the emoji default presentation rules. In some contexts, such as web pages, that's "just do what that Emoji_Presentation flag says" for those characters, but see [§Presentation Style](https://www.unicode.org/reports/tr51/proposed.html#Presentat...) for exceptions to the rule. (HN is not an exception.) But you can also follow the character with a variation selector, to try to force either text (U+FE0E) or emoji (U+FE0F) presentation.
There are a number of what I'd call "yeah that's definitely an emoji" outside the Emoji block, too. Like U+2705 "white check in green box" (which HN disallows me posting); that one is Emoji=Yes but also Emoji_Presentation=Yes)
(IDK if Emoji=Yes Emoji_Presentation=Yes is HN's filter … but that'd be what I would do, if I wanted to filter out emoji like HN does.)
(Also, note that the title was changed; the original HN title was "I ♥ RSS")
dgellow [3 hidden]5 mins ago
Yep, that seems to be the case!
culi [3 hidden]5 mins ago
yes, exactly:
♠♡♢♣♤♥♦♧
smalltorch [3 hidden]5 mins ago
♚ ♛ ♜ ♝ ♞ ♟
♔ ♕ ♖ ♗ ♘ ♙
Chess pieces too. I think you could technically play a chess game here pretty easily if you were so inclined.
dgellow [3 hidden]5 mins ago
Funny, I see the 1st, 4th, 6th and 7th in color. The outlined ones look like standard font characters
culi [3 hidden]5 mins ago
To me they are (correctly) rendered as black
dgellow [3 hidden]5 mins ago
Joke on me for using Apple devices :(
extra88 [3 hidden]5 mins ago
On iOS, the filled-in ones are all in colors set by the font but in macOS Safari they inherit the text `color`.
culi [3 hidden]5 mins ago
I'm on Mac but on Firefox
prmoustache [3 hidden]5 mins ago
It is not an emoji but a unicode character and HN doesn't render it, your OS does.
F3nd0 [3 hidden]5 mins ago
It may not be in the Emoji character block formally, but casually speaking it’s not wrong to call it an emoji, since emoji is basically just a picture character, and this is no less a picture character than what’s formally codified as ‘Emoji’ in the Unicode standard.
dgellow [3 hidden]5 mins ago
In addition to this, what I meant to convey is that it does show exactly like the iOS/iPadOS emojis, in color, with details, etc. Not the non-emoji font unicode character
pkulak [3 hidden]5 mins ago
Not up to HN, it’s up to your font and font rendering.
dijit [3 hidden]5 mins ago
this is the first emoji I see on HN at all, they’re filtered out in comments.
culi [3 hidden]5 mins ago
It's because it's not actually an emoji (though your OS/font might decide to render it like one)
I don't remember ever seeing one before either. Will the floodgates now open?
cyptus [3 hidden]5 mins ago
first time also! depending on iOS for me.
minraws [3 hidden]5 mins ago
that's specific to your os it renders in os emoji colors iirc.
dgellow [3 hidden]5 mins ago
I’ve always seen emoji being stripped on HN, so it’s very surprising to see colors for once
culi [3 hidden]5 mins ago
They've always been stripped for me as well. This "emoji" actually appears black for me however.
I think the reason its not stripped is because it's actually "U+2665 : BLACK HEART SUIT {valentine}" which predates the emojis. Lots of fonts and OSes will render these older unicode symbols as emojis
sylware [3 hidden]5 mins ago
Well, in theory, with proper UTF-8 support you don't need to filter out anything.
Unsupported unicode code points are just rendered using a place holder.
3dedb728-3f77 [3 hidden]5 mins ago
Would be nice if it was explained how to actually manage a RSS.
smarkov [3 hidden]5 mins ago
Maybe you love being the consumer of RSS feeds, but you certainly wouldn't love being the poor bastard who has to parse them.
Even though it's a simple standard that's been around for decades, there are still many sites which serve their feeds with a subtly wrong format. When something doesn't work, users come knocking on your door saying "it works in X reader but not in yours", so now you have to handle that and contribute to the ever growing list of out of spec edge cases that feed readers need to account for.
bolt012 [3 hidden]5 mins ago
I love self hosting my own RSS feed with miniflux!
paradoxyl [3 hidden]5 mins ago
What sort of punishment should the monopolist google execs who destroyed blogs undergo? A fair punishment might be clawback of all wages and stock options and about five years in a minimum security prison with a permenant felony on their record. I think that's fair.
colesantiago [3 hidden]5 mins ago
How much money do you need for a class action lawsuit on this?
I think we should take Google to court over destroying blogs and force them to add back RSS support.
luciana1u [3 hidden]5 mins ago
the format wars ended and the prize was that nobody won and we all just use a different feed reader for the rest of our lives
poisonborz [3 hidden]5 mins ago
Nowadays I see these sites as nothing else but mining grounds for personal profiling by big tech. Nothing can be a cutesy show-off anymore.
ymolodtsov [3 hidden]5 mins ago
What does this mean exactly?
listic [3 hidden]5 mins ago
Why not for small tech and individuals?
Is there a law or something? :)
culi [3 hidden]5 mins ago
Small tech and individuals will never be able to take as much advantage of these standards as a multi-billion dollar data center is. 99% of them wouldn't ever even find these feeds
eleventen [3 hidden]5 mins ago
> An Atom feed correctly labelled application/atom+xml won’t match — that tag is right, it just isn’t the format we list - https://iheartrss.com/guide
...why?
pKropotkin [3 hidden]5 mins ago
I ♥ JSONFeed
8organicbits [3 hidden]5 mins ago
What do you like about JSON Feed?
One of the downsides I saw when evaluating JSON Feed was that it doesn't use GUIDs, which can cause problems when the same post is present in multiple feeds (I.E. syndication).
When I last looked I found that every feed reader supporting JSON feeds also supported RSS/Atom and every website with a JSON feed also had an RSS or Atom feed, so it seems easiest to ignore the JSON Feed format.
And so I wish people would stop calling feeds RSS, because it continues to compound the problem. Let RSS die! More than once I’ve seen people implement RSS feeds, at great pain and often with errors, simply because they hadn’t heard of Atom.
(I still need to decide which spec I hate more, RSS or OpenGraph. Hmm… RSS had more excuses for being bad, OpenGraph was just a spectacularly bad thing thrown over the wall by a company that should have known better. I drafted something examining how comprehensively bad it was some years ago, I should put it onto my new site and continue it at some point.)
We call them RSS feeds, RSS reader apps even if it might be implemented as an Atom feed.
I'm not too serious here but even many news media publications are just dropping it, or separate into dozens of unconnected feeds.
While RSS is tricky to parse in practice, many of the challenges are due to invalid feeds, which Atom is not invulnerable to. Its very likely that there is a well-tested feed parser for your favorite programming language, so most developers using feed programmatically don't need to handle those challenges themselves.
For concerns like title encoding or summary vs full text description, you can handle those using namespaces. If you don't like any of the existing namespaces that do that you can create your own.
https://rssvault.org
Password is vaultearly644988
Pardon the dust. There's an app tie-in that I'm almost done with too, a widget-first app that shows your RSS feed collections on your phone's home screen. It would really be great if we could start to bring about an RSS renaissance!
I have sneaked in.
Suggestions:
White or almost white text would be better.
Make “Add” button visible on homepage.
Make a possibility to batch suggest feeds - a lot of people have opml xml exports from Google Reader so they can give it to you. Processing info would be nice so I as a supplier would immediately know how useful I was.
Move explanatory part of RSS to some other part than homepage.
"White or almost white text would be better." -- There is some white text, headers and headlines mostly. Did you find the lack of contrast difficult to deal with?
"Make “Add” button visible on homepage." -- you mean like in the search results? That's a fine idea.
"Make a possibility to batch suggest feeds" -- I've been toying with how to handle OPML imports. Definitely a feature to come on the app, but I fear with mass submission on the vault I would be inundated with feeds, and the curation aspect would suffer. I want quality over quantity. But maybe there's a happy middle ground somewhere.
"Move explanatory part of RSS to some other part" -- yeah I guess this might be helpful to someone who doesn't know what RSS is, but then they probably aren't visiting anyway lol I'll give it some thought.
Appreciate it. Thanks again.
(Not judging, just testing my radar)
I wish people would blog more like in the old days.
I care more about the stories (people call it 'content' nowadays) than about the tech, as long as the tech is open.
Can't blame them; it draws a bit more attention than normal.
https://news.ycombinator.com/item?id=49136685
https://pico.sh/feeds is an ssh app that is an rss-to-email service.
My favorite part of FeedLand is that you can see who subscribes to a blog and where else they subscribe. This makes RSS feel social, without the algorithmic tricks of traditional social media. Here's the listing for my blog, for example: https://feedland.com/?feedurl=https%3A%2F%2Falexsci.com%2Fbl...
We're going to have a new version pretty soon, hooking it up with RSS.chat.
I don't really use RSS myself anymore, though; not since I stopped using Google Reader a few months before they pulled the plug. Wouldn't even know where to start nowadays.
There's not really a "standard" character set and an "emoji" one. There is an emoji block (U+1F600 to U+1F64F), and this heart (U+2665) is not in that. But this heart is an emoji, in that the data file emoji-data.txt for contains `Emoji=Yes` ("=Yes for characters that are emoji", —UTS #51) for this character. However, this heart has `Emoji_Presentation=No`, which "=Yes for characters that have emoji presentation by default" (—UTS #51).
So basically, it should present, by default, in its non-emoji appearance. (Though there seem to be a number of readers for whom that isn't true. I think that's macOS being badly behaved.) There are some characters that can flip/flop between a "text" (normal monochrome) presentation and an emoji presentation; all of the card suit characters are. Unadorned (e.g., just U+2665 alone) then, you have to follow the emoji default presentation rules. In some contexts, such as web pages, that's "just do what that Emoji_Presentation flag says" for those characters, but see [§Presentation Style](https://www.unicode.org/reports/tr51/proposed.html#Presentat...) for exceptions to the rule. (HN is not an exception.) But you can also follow the character with a variation selector, to try to force either text (U+FE0E) or emoji (U+FE0F) presentation.
There are a number of what I'd call "yeah that's definitely an emoji" outside the Emoji block, too. Like U+2705 "white check in green box" (which HN disallows me posting); that one is Emoji=Yes but also Emoji_Presentation=Yes)
(IDK if Emoji=Yes Emoji_Presentation=Yes is HN's filter … but that'd be what I would do, if I wanted to filter out emoji like HN does.)
UTS #51: https://www.unicode.org/reports/tr51/proposed.html#Emoji_Pro...
(Also, note that the title was changed; the original HN title was "I ♥ RSS")
♠♡♢♣♤♥♦♧
Chess pieces too. I think you could technically play a chess game here pretty easily if you were so inclined.
https://www.compart.com/en/unicode/U+2665
It's part of the card suite icons
♠♡♢♣♤♥♦♧
I think the reason its not stripped is because it's actually "U+2665 : BLACK HEART SUIT {valentine}" which predates the emojis. Lots of fonts and OSes will render these older unicode symbols as emojis
Unsupported unicode code points are just rendered using a place holder.
Even though it's a simple standard that's been around for decades, there are still many sites which serve their feeds with a subtly wrong format. When something doesn't work, users come knocking on your door saying "it works in X reader but not in yours", so now you have to handle that and contribute to the ever growing list of out of spec edge cases that feed readers need to account for.
I think we should take Google to court over destroying blogs and force them to add back RSS support.
Is there a law or something? :)
...why?
One of the downsides I saw when evaluating JSON Feed was that it doesn't use GUIDs, which can cause problems when the same post is present in multiple feeds (I.E. syndication).
When I last looked I found that every feed reader supporting JSON feeds also supported RSS/Atom and every website with a JSON feed also had an RSS or Atom feed, so it seems easiest to ignore the JSON Feed format.