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!
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.
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.
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.
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.
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.)
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.
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.
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".
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?
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.
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.
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.
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.
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. :-)
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.
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.
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...
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.
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.
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.
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?
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.)
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.
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
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
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.
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.
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
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.
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.
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 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.
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.
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.
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.
Claude?
(Not judging, just testing my radar)
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.
Sure. I have a few projects like that, myself. Good luck with it.
Thank you
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.)
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.
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.
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".
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?
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.
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.
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.
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.
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. :-)
I think they are alive just because they are rough and weired
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.
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.
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.
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.
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.
I really need to finish the blog post for my emoji domain. What are mods gonna do when the emoji is literally in the domain?
The last time I tried to use one in a comment, it got stripped out. I guess that doesn't apply to submission titles.
It's generally does!
i guess that only works cause it's a text glyph and not a unicode emoji
If you love RSS, embrace Atom 1.0 :) Its the final modern form of RSS.
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.
Atom's problem is that RSS is also the final modern form of RSS.
Why is Atom better?
There might be other reasons, but chrismorgan linked a nice write-up in a sibling comment:
https://news.ycombinator.com/item?id=49136685
Thanks, good points there.
Atom was killed by podcasts. Tbh RSS 2.0 is good enough
Atom was killed by podcasts
Nice! The entire https://pico.sh constellation of services are built off rss for notifications.
https://pico.sh/feeds is an ssh app that is an rss-to-email service.
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...
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.
Thanks for RSS, sir.
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.
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.
I'm quite happy with NetNewsWire.
HN renders emojis in color?! I’m reading that on an iPad and see a red heart. That’s a first
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?
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.)
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")
Yep, that seems to be the case!
yes, exactly:
♠♡♢♣♤♥♦♧
♚ ♛ ♜ ♝ ♞ ♟ ♔ ♕ ♖ ♗ ♘ ♙
Chess pieces too. I think you could technically play a chess game here pretty easily if you were so inclined.
Funny, I see the 1st, 4th, 6th and 7th in color. The outlined ones look like standard font characters
To me they are (correctly) rendered as black
Joke on me for using Apple devices :(
On iOS, the filled-in ones are all in colors set by the font but in macOS Safari they inherit the text `color`.
I'm on Mac but on Firefox
It is not an emoji but a unicode character and HN doesn't render it, your OS does.
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.
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
Not up to HN, it’s up to your font and font rendering.
this is the first emoji I see on HN at all, they’re filtered out in comments.
It's because it's not actually an emoji (though your OS/font might decide to render it like one)
https://www.compart.com/en/unicode/U+2665
It's part of the card suite icons
♠♡♢♣♤♥♦♧
I don't remember ever seeing one before either. Will the floodgates now open?
first time also! depending on iOS for me.
that's specific to your os it renders in os emoji colors iirc.
I’ve always seen emoji being stripped on HN, so it’s very surprising to see colors for once
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
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.
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.
I love self hosting my own RSS feed with miniflux!
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.
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.
Would be nice if it was explained how to actually manage a RSS.
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.
What does this mean exactly?
Why not for small tech and individuals?
Is there a law or something? :)
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
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
I ♥ JSONFeed
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.
Please add me