Thoughts on RSS(matt-rickard.com)
matt-rickard.com
Thoughts on RSS
https://matt-rickard.com/thoughts-on-rss/
60 comments
Atom even allows specifying an Email address: https://datatracker.ietf.org/doc/html/rfc4287#section-3.2.3
So if someone wants to contact you, they can do so directly.
So if someone wants to contact you, they can do so directly.
RSS too:
managingEditor Email address for person responsible for editorial content. [email protected] (George Matesky)
webMaster Email address for person responsible for technical issues relating to channel. [email protected] (Betty Guernsey)
This really only benefits the audience, though, which means there is little to no incentive on the part of the creator to use RSS.
If you don’t have a RSS feed, I won’t see your content. There are only a handful of sites I view direct any more and most likely you are not going to make the cut.
Sure, but you represent what is likely to be a very, very small percentage of readers. There are a lot of people on HN that have that same orientation toward content. But, as with so many things, they're on the periphery of the zeitgeist because they're technologists for the most part.
Most blog readers don't share your perspective, and, unless a creator's audience skews very heavily toward a group that does, it would be hard to say the incentives are aligned in the direction that makes a tangible difference for them to support RSS for their posts.
Most blog readers don't share your perspective, and, unless a creator's audience skews very heavily toward a group that does, it would be hard to say the incentives are aligned in the direction that makes a tangible difference for them to support RSS for their posts.
That would be a compelling argument if any substantive number of each site's potential viewers did this. But they don't. Publishers don't care about RSS because hardly anyone uses RSS because publishers don't care about RSS. Publishers would care more about RSS if they didn't have to sacrifice things they cared about to serve a small minority of viewers.
> Publishers would care more about RSS if they didn't have to sacrifice things they cared about
What sacrifice are you talking about? For instance, Substack supports RSS, even for paid items. They just only include the teaser portion in the feed. The paying customers can click though.
What sacrifice are you talking about? For instance, Substack supports RSS, even for paid items. They just only include the teaser portion in the feed. The paying customers can click though.
If you don't click through, you don't get ads. The publisher makes no money from you browsing the content with a feed. Moreover, they can't quantify what you passed over before clicking something.
These aren't things users care about, but it's what the publishers care about.
These aren't things users care about, but it's what the publishers care about.
I think this is why the answer to RSS is an RSS client that can create feeds from arbitrary sources. (RSS being less a technology/protocol and more a general concept of fetching/consuming content for local consumption)
The original model never made too much sense to me: why do I depend on every single website to implement something that I want? If a website doesn't implement it, I just don't get to use my RSS client with it at all? Not very compelling.
You can see the same inconsistency in the finger-pointing that comes up on this topic. RSS benefits us, the audience, yet it's {X,Y,Z}s fault for not implementing it for us. And we need to somehow compel them to do it or something.
Nah, an RSS reader in 2022 should be able to create feeds from websites. There are already solutions here.
The original model never made too much sense to me: why do I depend on every single website to implement something that I want? If a website doesn't implement it, I just don't get to use my RSS client with it at all? Not very compelling.
You can see the same inconsistency in the finger-pointing that comes up on this topic. RSS benefits us, the audience, yet it's {X,Y,Z}s fault for not implementing it for us. And we need to somehow compel them to do it or something.
Nah, an RSS reader in 2022 should be able to create feeds from websites. There are already solutions here.
Reaching the audience that value their privacy is a good incentive, at least for most personal bloggers. I don't care who is reading my blog but I do want to make the process as hassle free as possible.
There are several questionable claims and viewpoints in this post. This is one I felt worthy of addressing because information to the contrary is not widely known:
> RSS is one-way publishing; there is no way for content creators and their audience to interact
Not true. Feeds support a byline for each post item. This typically contains the author's name. You can, though, also include an email address there. For readers that are also mail clients, those readers* can allow the user to "reply to" a given feed item (in the same way that your mail client lets you reply to a message sitting in your mailbox). I know of very few feeds, however, where people actually include a reply-to address. It's a network/ecosystem problem.
* or any other reader that wishes to allow invoking the user's default mail client
> RSS is one-way publishing; there is no way for content creators and their audience to interact
Not true. Feeds support a byline for each post item. This typically contains the author's name. You can, though, also include an email address there. For readers that are also mail clients, those readers* can allow the user to "reply to" a given feed item (in the same way that your mail client lets you reply to a message sitting in your mailbox). I know of very few feeds, however, where people actually include a reply-to address. It's a network/ecosystem problem.
* or any other reader that wishes to allow invoking the user's default mail client
That's really interesting, though I don't think that private 1:1 messages are what most people have in mind when they think of interaction between content creators and their audience.
I think the simplest way of adding a more traditional "replies" feature to RSS would be to have some way of indicating an RSS <item> is a reply to another RSS item in a different feed. Then maybe add some sort of POST endpoint where anyone can request that a reply be linked back to from the author's post, and there you go: a fully decentralized comment system.
I think the simplest way of adding a more traditional "replies" feature to RSS would be to have some way of indicating an RSS <item> is a reply to another RSS item in a different feed. Then maybe add some sort of POST endpoint where anyone can request that a reply be linked back to from the author's post, and there you go: a fully decentralized comment system.
It seems like the simplest way is to put a link at the end of the post that goes to a regular web page that has the comments.
At that point, you need to decide if users need to log in or not. Often, requiring a login of some sort is a good anti-spam measure, but it also excludes some people.
Still, if requiring a login is good enough for Hacker News, it's probably good enough for your blog. Why do you want to hear from anonymous posters anyway?
At that point, you need to decide if users need to log in or not. Often, requiring a login of some sort is a good anti-spam measure, but it also excludes some people.
Still, if requiring a login is good enough for Hacker News, it's probably good enough for your blog. Why do you want to hear from anonymous posters anyway?
I don't think RSS is the right place for this kind of interaction. There are many ways to include commenting such as HN, or (shameless plug) https://roastidio.us
With this feature though HN comments on articles could become 1st class citizens inside your favorite RSS reader. Just tag each item in https://hnrss.org/item?id=32140774 as a reply to the linked article, POST them to the feed's listed comment submission endpoint, and there you go, HN comments are now integrated with your blog's decentralized comment system.
I agree RSS is not designed work comments in mind and probably shouldn't be redesigned to support them. ActivityPub is a more suitable, federated way to support comments.
[deleted]
<comments> ?
Pretty much, except the existing spec for that provides no way for people to post or read comments from the RSS reader; you have to go to an external URL.
Oh. It’s been a while since I’ve worked with RSS2, IIRC some of the feeds I worked 14 yrs ago with were comment feeds off a given blog post. Maybe those implementations weren’t true to spec.
And every entry has a link, so users can follow it if they want more content/interactivity/contact.
RSS is not dead because it covers an use case for which there is no replacement. The attempt to kill RSS didn't consist in creating a better RSS, it consisted in walled gardens. The use case of providing structured updates for a web site has no better replacement than RSS right now. Some walled gardens like twitter feeds are the closest replacement and they are not nearly the same.
But the article gets it wrong IMO (except for the last point). The main people to blame about this situation is not the incentives, nor the companies who tried to created the walled gardens. Even if there were incentives, RSS would not improve. As long as web makers don't treat it as a first class citizen, RSS will keep being an "optional" thing that requires separate extensions, programs, etc, it is just not going to be massively used if using it isn't super obvious. It's the browser makers' fault (Mozilla, I'm looking at you). RSS was treated almost like an annoyance. Firefox only provided an icon and "live bookmarks" thing with a really poor UX and then removed it because not many people used it (meanwhile we have Pocket shipped by default...). Google, they never had interest in competing with their own walled garden.
And that's how we ended with the current horrible state of the web, where every website asks you to subscribe via email to their wonderful newsletter. If we only had a technology that would allow websites to provide content that users can read asynchronously and doesn't involve filling their mailboxes...something like a newsletter RSS...maybe then we would not need to place a stupid JS popup in every fucking website in the world and we would let people easily subscribe to a newsletter RSS.
Unfortunately, browser makers are too busy with things like webassembly, because making the JS popups faster is way more important than fixing the basic interaction with the web.
But the article gets it wrong IMO (except for the last point). The main people to blame about this situation is not the incentives, nor the companies who tried to created the walled gardens. Even if there were incentives, RSS would not improve. As long as web makers don't treat it as a first class citizen, RSS will keep being an "optional" thing that requires separate extensions, programs, etc, it is just not going to be massively used if using it isn't super obvious. It's the browser makers' fault (Mozilla, I'm looking at you). RSS was treated almost like an annoyance. Firefox only provided an icon and "live bookmarks" thing with a really poor UX and then removed it because not many people used it (meanwhile we have Pocket shipped by default...). Google, they never had interest in competing with their own walled garden.
And that's how we ended with the current horrible state of the web, where every website asks you to subscribe via email to their wonderful newsletter. If we only had a technology that would allow websites to provide content that users can read asynchronously and doesn't involve filling their mailboxes...something like a newsletter RSS...maybe then we would not need to place a stupid JS popup in every fucking website in the world and we would let people easily subscribe to a newsletter RSS.
Unfortunately, browser makers are too busy with things like webassembly, because making the JS popups faster is way more important than fixing the basic interaction with the web.
ActivityStreams is pretty much RSS on steroids. The whole Fediverse is built on that standard.
>Walled garden content aggregation is significantly more profitable than free syndication (e.g., Reddit, Facebook)
Reddit is a poor example(at least for now), considering you can still to this day add ".rss" to just about any search or url and get a feed. Their co-founder Aaron Swartz developed RSS. Before they destroyed modmail, you could use your rss reader to keep track of those as well.
Considering the corporate direction they are going, I'm sure the rss feature's days are numbered, as everything else, principles, morals, and ethics infused into reddit from Aaron Swartz are systematically replaced or removed.
Reddit is a poor example(at least for now), considering you can still to this day add ".rss" to just about any search or url and get a feed. Their co-founder Aaron Swartz developed RSS. Before they destroyed modmail, you could use your rss reader to keep track of those as well.
Considering the corporate direction they are going, I'm sure the rss feature's days are numbered, as everything else, principles, morals, and ethics infused into reddit from Aaron Swartz are systematically replaced or removed.
> Their co-founder Aaron Swartz developed RSS
"He was involved in the development of the web feed format RSS" -- https://en.wikipedia.org/wiki/Aaron_Swartz
"He was involved in the development of the web feed format RSS" -- https://en.wikipedia.org/wiki/Aaron_Swartz
> RSS readers act like email clients in how they render content via HTML. Unfortunately, email content isn't as rich as the JavaScript-powered web today. Maybe that's OK for email (and podcasts), but not for generic blog content.
It's not clear if this is meant to address the needs of publishers or readers.
For consumption, I consider refusing to run scripts or render sophisticated layouts a plus. Many browsers include reader modes to produce a similar effect because readers do not usually want auto-playing videos or email subscription overlays.
Of course, if I was publishing something and trying to make money from it, I might want to play a video with ads in it regardless of the reader's preference, and I definitely want their email address even though they're already subscribed by RSS so that I have another means of competing for their attention.
It's not clear if this is meant to address the needs of publishers or readers.
For consumption, I consider refusing to run scripts or render sophisticated layouts a plus. Many browsers include reader modes to produce a similar effect because readers do not usually want auto-playing videos or email subscription overlays.
Of course, if I was publishing something and trying to make money from it, I might want to play a video with ads in it regardless of the reader's preference, and I definitely want their email address even though they're already subscribed by RSS so that I have another means of competing for their attention.
> RSS readers act like email clients in how they render content via HTML. Unfortunately, email content isn't as rich as the JavaScript-powered web today
Can somebody expand on-behalf on this ludicrous idea and its unspecified details; it seems like somebody has found something better than hypertext¹ - but left the specs inexplicit. If anybody has an idea if that positively meant something...
(¹codable text? It reminds me of the self-modifying code we used in the 8-bit times. Surely not the way I want text - which has to be complete and assessable.)
By the way, RSS informs you that something exists; what it points to may even include rockets and theatrical performance in the end.
And all along the way, if I intend to receive hypertext I want it certain that code will run only in containers I decided.
Can somebody expand on-behalf on this ludicrous idea and its unspecified details; it seems like somebody has found something better than hypertext¹ - but left the specs inexplicit. If anybody has an idea if that positively meant something...
(¹codable text? It reminds me of the self-modifying code we used in the 8-bit times. Surely not the way I want text - which has to be complete and assessable.)
By the way, RSS informs you that something exists; what it points to may even include rockets and theatrical performance in the end.
And all along the way, if I intend to receive hypertext I want it certain that code will run only in containers I decided.
The HTML in email isn't modern HTML+CSS. IIRC due to Outlook and backwards-compatibility, it's out of date.
The author is saying that RSS readers render the content using older HTML standards. I don't know if that's true, but that's how I read their statement.
The author is saying that RSS readers render the content using older HTML standards. I don't know if that's true, but that's how I read their statement.
Trying to get an up to date web browser embedded in an application is difficult. The people who make web browsers make their components first most for their web browser, not for embedding in other peoples’ projects.
Usually you can find some web browser that you can embed in your application but it won’t be up to date because there is no money in maintaining it.
Usually you can find some web browser that you can embed in your application but it won’t be up to date because there is no money in maintaining it.
> Usually you can find some web browser that you can embed in your application but it won’t be up to date
If you want an HTML renderer, using a full «web browser» engine may be a bad idea. An HTML rendering may probably need less security updates.
If you want an HTML renderer, using a full «web browser» engine may be a bad idea. An HTML rendering may probably need less security updates.
OK but even sometimes finding an up-to-date HTML renderer can be hard.
Very few people are out there packaging up-to-date webpage renderers into easy to use libraries. Many times you end up using the one built-in to your UI toolkits and those are often very neglected.
Very few people are out there packaging up-to-date webpage renderers into easy to use libraries. Many times you end up using the one built-in to your UI toolkits and those are often very neglected.
In my case, that I don't think is extraordinary, I scan the titles in the RSS reader and click on them to go their fully rendered pages more often than not. That tacks some of the noted downsides. Content discoverability is no problem either. Content for me is web-first, but if provider exposes RSS, It gets more recurrence from me. User unfriendliness can be fought with browser extensions.
I wonder what percentage of RSS users read all their articles in their reader (if possible). I use RSS the same way you do but I've assumed I'm in the minority.
I utterly and etirely fail to see how javascript is evenly remotely required to render a blog.. If your blog requires javascript to simply show content, you're building a browser inside the browser and need to stop.
Hm. I am an active RSS user, used it since it came to be, and not once did I want my RSS feed to have more complex text formatting than it already has.
RSS is excellent at organizing chaotic websites into readable form. You can glance down the list quickly like reading email subject headers. There's limited opportunity to be distracted by flashy graphics or other time wasters. To try to explain RSS to somebody else who isn't familiar I usually don't bother.
RSS was, to make a slightly cliche paraphrase, a more elegant web for a more civilized age. It was user controlled content consumption. It declined because it conflicts with the "addict them and stuff their eyeballs with intrusive personalized ads" monetization model of the post 2010 internet.
I’ve had ideas on making a Reddit like RSS reader. Every user would have their own feed list that others can see by clicking on that user and add to their own.
The main feed would be ranked by most followed sites in an HN like layout with comments. And of course there would be another section for personal feed.
I just don’t know how much server fees would cost, a lot of feeds don’t have pubDates, polling or archive retrieval are expensive. I thought about making a fat client setup so the users machine does that work, whatever it takes to make something clean and simple without an ugly premium package with 100 things no one wants.
The main feed would be ranked by most followed sites in an HN like layout with comments. And of course there would be another section for personal feed.
I just don’t know how much server fees would cost, a lot of feeds don’t have pubDates, polling or archive retrieval are expensive. I thought about making a fat client setup so the users machine does that work, whatever it takes to make something clean and simple without an ugly premium package with 100 things no one wants.
I wish OPML (the import/export RSS format) was also subscribe-able[1] in more clients. So my GitHub "news feed" would live at github.com/captn3m0/news.opml (which would just be a list of RSS URLs), and the client would update this list periodically.
Same thing works well for Twitter, or other sites.
[1]: https://github.com/captn3m0/ideas/#opml-sync
Same thing works well for Twitter, or other sites.
[1]: https://github.com/captn3m0/ideas/#opml-sync
> a lot of feeds don’t have pubDates
I don't see how this would significantly impact the cost. The main cost is that you need to remember all entry IDs to know which you have seen before. However you should probably do this anyway because published dates aren't very reliable. Plus if you are storing user comments then you probably want to keep the entries around for a long time anyways.
> polling or archive retrieval are expensive
Polling isn't very expensive. It is just a HTTP get. Many feeds also support conditional requests so you just get a 304. If you have enough feeds that becomes expensive you can play with the update time, poll feeds of active users more often, slow down polling if a feed doesn't post often...
I also don't know how archive retrieval is expensive. You only really need to do this when a new feed is added (and even then you only need to do it if you want history). Maybe if the full "first page" of the feed is new you can look back a bit into the archive but this is so rare that it probably isn't worth doing.
I guess for pagnated (not archived) feeds you should technically check all pages each time but so few readers even support pagnation at all that I would consider a feed that doesn't put new entries on the first page broken and wouldn't bother support it.
TL;DR I don't think this service would be very expensive to run. If you get enough users and feeds to start being concerned about the cost of polling you will have enough resources to deal with it.
Source: I run a small RSS reader service.
I don't see how this would significantly impact the cost. The main cost is that you need to remember all entry IDs to know which you have seen before. However you should probably do this anyway because published dates aren't very reliable. Plus if you are storing user comments then you probably want to keep the entries around for a long time anyways.
> polling or archive retrieval are expensive
Polling isn't very expensive. It is just a HTTP get. Many feeds also support conditional requests so you just get a 304. If you have enough feeds that becomes expensive you can play with the update time, poll feeds of active users more often, slow down polling if a feed doesn't post often...
I also don't know how archive retrieval is expensive. You only really need to do this when a new feed is added (and even then you only need to do it if you want history). Maybe if the full "first page" of the feed is new you can look back a bit into the archive but this is so rare that it probably isn't worth doing.
I guess for pagnated (not archived) feeds you should technically check all pages each time but so few readers even support pagnation at all that I would consider a feed that doesn't put new entries on the first page broken and wouldn't bother support it.
TL;DR I don't think this service would be very expensive to run. If you get enough users and feeds to start being concerned about the cost of polling you will have enough resources to deal with it.
Source: I run a small RSS reader service.
How entry id’s serve as an alternative to pubDates? Also by entry id, do you mean RSS item?
Most of my concern comes from seeing NewsBlur, Feedly, and The Old Reader resort to premium services. Throttling users unless they pay, now that’s not a game I want to be apart of.
Most of my concern comes from seeing NewsBlur, Feedly, and The Old Reader resort to premium services. Throttling users unless they pay, now that’s not a game I want to be apart of.
My only guess for how pubDate would affect the cost was using it to identify previously seen entries/items. If you can rely on pubDates being stable and monotonically increasing for new entries you can just remember the last one instead of a number of IDs. But that is likely an incredibly small cost.
How else do you expect to make money other than premium services? Even if cheap hosting is not free. And likely the cost of staff is by far the biggest expense of these companies. Premium literally means something that costs. The only other major business model I am aware of than charging your chstomers is to sell their data or attention. Personally I prefer the freemium or paid model.
If you are going for freemium than faster update rate sounds like an incredibly fair compromise if that is increasing the cost of serving a user. Much better than many artificial limitations.
How else do you expect to make money other than premium services? Even if cheap hosting is not free. And likely the cost of staff is by far the biggest expense of these companies. Premium literally means something that costs. The only other major business model I am aware of than charging your chstomers is to sell their data or attention. Personally I prefer the freemium or paid model.
If you are going for freemium than faster update rate sounds like an incredibly fair compromise if that is increasing the cost of serving a user. Much better than many artificial limitations.
> How else do you expect to make money other than premium services?
I don’t, I want something that can host for users as cheaply as possible. I’d make it open source and be fully transparent about the fat client design and whatever else.
I pretty much want this site, but every user has an RSS feed, can see each other’s, and a front page with rankings.
I don’t, I want something that can host for users as cheaply as possible. I’d make it open source and be fully transparent about the fat client design and whatever else.
I pretty much want this site, but every user has an RSS feed, can see each other’s, and a front page with rankings.
Even this site is funded, it is effectively an add for Y-Combinator and it also hosts job listings for YC companies. I guess "make money" is poor wording but privately funded often fails in the long-term especially if a site becomes popular.
RSS feeds are in my eyes the best way to follow cross-platform content in a single place without worrying about privacy.
It allows you to follow your favorite artists / content creators on instagram (via bibliogram), twitter (via nitter), youtube (via invidious), tiktok (via proxitok) etc. without having an actual account to these services or using obscure apps. You can also follow your favorite news site, subscribe to ebay search terms (if your looking for one specific thing), hacker news, blog posts and much more all following one standard on one platform.
It allows you to follow your favorite artists / content creators on instagram (via bibliogram), twitter (via nitter), youtube (via invidious), tiktok (via proxitok) etc. without having an actual account to these services or using obscure apps. You can also follow your favorite news site, subscribe to ebay search terms (if your looking for one specific thing), hacker news, blog posts and much more all following one standard on one platform.
For some reason this misses out a point that I personally find deeply annoying. I’d like the ability to share an image for the RSS feed for my site. This is usually some horrific mix of nested html or xml cdata and no one can agree on how to put an image in a RSS feed item. Different readers and platforms seem to just make it up on a whim.
Podcast RSS has the fortune of being pretty consistent and contains an image for the podcast.
Podcast RSS has the fortune of being pretty consistent and contains an image for the podcast.
> no one can agree on how to put an image in a RSS feed item
There is, if you put a image at the enclosure tag, most feed readers will recognize that.
https://validator.w3.org/feed/docs/rss2.html#ltenclosuregtSu...
There is, if you put a image at the enclosure tag, most feed readers will recognize that.
https://validator.w3.org/feed/docs/rss2.html#ltenclosuregtSu...
Tried it and it didn't seem to work. I will try it again though. Again most SO answers and articles I saw have some terrible CDATA thing going on.
See my blog's feed as an example on how to use enclosure:
https://blog.3qin.us/feed.xml
W3C has a RSS validator that you can use to validate the RSS file. I also have a blog linter that cross check the consistency between the metadata from the feed and the metadata from the blog posts
https://roastidio.us/lint
Hint: very few blogs pass without warning.
https://blog.3qin.us/feed.xml
W3C has a RSS validator that you can use to validate the RSS file. I also have a blog linter that cross check the consistency between the metadata from the feed and the metadata from the blog posts
https://roastidio.us/lint
Hint: very few blogs pass without warning.
> how to put an image
I do not get it: an <img> tag?
If you mean "embed it": people in general would not want to receive it!...
I do not get it: an <img> tag?
If you mean "embed it": people in general would not want to receive it!...
Is it possible that Podcasts are the last remaining widespread/mainstream use case of RSS?
For me at least, it's quite on the contrary, there are few viable cases for content I wish not to consume via RSS.
Some of my reasons are:
1. Having a central place where I can keep track of my my reading lists.
2. Offline first (download for later use is the default behavior)
3. Deduplication - for advanced use cases such as messy web feeds, where ordering is far from guaranteed, a well defined key can reduce the clutter significantly.
4. Advanced filtering (Newsboat is great at that)
Some of my reasons are:
1. Having a central place where I can keep track of my my reading lists.
2. Offline first (download for later use is the default behavior)
3. Deduplication - for advanced use cases such as messy web feeds, where ordering is far from guaranteed, a well defined key can reduce the clutter significantly.
4. Advanced filtering (Newsboat is great at that)
You can still use RSS for most news sites and some feed type sites
youtube,news(papers) and so on have support for RSS or are supported using 3rd party providers
youtube,news(papers) and so on have support for RSS or are supported using 3rd party providers
No. A lot of things are crawled with RSS. With pubmed for example you can set up search terms as rss feeds.
RSS is also used a lot as a trigger on no code automation platforms like Zapier
And there's an article on the front page of HN just about that: https://news.ycombinator.com/item?id=32139612
No
Not at all. Most sites support RSS. There are still people (myself included) that consume most of their web content via RSS.
Is that really "widespread/mainstream" though? Podcasts listening is pretty huge; in the US "38% of those age 12+ in the U.S. are monthly podcast listeners" (ref: https://www.edisonresearch.com/the-infinite-dial-2022/)
I consider this as the main strength of RSS; respecting the privacy of the audience. If the audience want to interact they can still choose to do so. The small amount of friction actually helps to beat down the noises.