RSS has been alive this whole time. Blogs usually have it by default, the big news organizations have it.
The only thing I'm not satisfied with reading news on RSS, is that news organizations push too many articles, to the point that reading the headlines alone takes quite some time. There's nearly 100 articles per day per source sometimes. Unlike a newspaper, which has a natural structure of priority and hierarchy, in an RSS reader, every head line has the same salience, and it's a pain to weed out what's important.
I kinda hope news organizations would make a separate "weekly digest feed", 30 or so articles per week.
Newsblur has a training feature [1], with a thumbs up/down on article tags, author, and keywords in a title that can bubble up more interesting articles or completely hide them.
Unfortunately training is per feed, there's a newer Premium Pro tier with global training coming out with it, but it is much more expensive [2].
I assume this is targeted at professionals that are trying to stay abreast of developments around certain topics/subjects. If you think about it through that lens it's reasonably priced, I suppose.
lol all these RSS readers really go in on solving problems as broadly as possible - not just ocean boiling, it leaves each user with a subpar experience even if it’s novel (having to laboriously refine results yourself). it would be easy for them to for instance scrape many popular news sources or APIs for ranking/top story info to at least cover these extremely common and extremely noisy feeds
Yes. Feedly seems to be marketing itself at investors and speculators lately (or trading bots I suppose), because they're using NLP to highlight and categorize articles based on whether they mention acquisitions, mergers, leadership changes, etc.
Feedly seems to be marketing itself as whatever interest group they think you are, because they're using NLP to highlight and categorize articles but at least for me not regarding whether they mention acquisitions, mergers, leadership changes, etc (though some of the articles my feed do) but rather whether they mention new security vulnerabilities or attacks - and I'd guess the same for many other specific niche domains.
Hey mate, you can give a go to lenns.io (an opinionated RSS reader). You can assign different priorities to both sources and categories to have the important (for you) articles show first.
I added rss filter/grep support to my homebrew rss->email script. So for example, I follow https://news.ycombinator.com/rss but only for articles with titles matching certain patterns:
I had a similar problem and created nooshub.com some years ago, it groups similar articles and uses the group size to detect news trends, but everything can also be configured per feed collection if you prefer chronological feeds. I use this to quickly check what is going on with high rate feeds, for other feeds like podcasts I keep it classic...
You can see it in action on some pages that do not require login like https://www.nooshub.com/pages/7-news-international
That's one of the reasons I build lenns.io. An alternative RSS reader. I gives you some additional vectors of control. For example, you can limit the number of items per source to show on your feed, as well as assign priorities to both sources and categories. Combined - it gives you a calm feed following all the sources your are interested in.
I'd be more than happy if you give it a go and share how it seems.
With FlipRSS.com we let subscribers choose only the content they want to receive. Using RSS feeds, matched to interest groups, content creators can keep in regular contact but deliver more personalised subscriber experiences. We love RSS!
We need to get back to a world where we’d have daily or weekly issues of news that we all read so that we can’t point at the same thing and say, “that’s right” or “that’s wrong”.
Not a complete solution to your problem, but the New York Times at least offers different RSS feeds for different sections.
So you can have a different feed for Science and Technology, and one for Australia, and one for New York. By not using the front page firehose, you can keep the number of inbound articles to a more manageable level.
If you have Reeder, you just paste the regular web page URL into it and it tries to figure out the RSS address on its own. It's possible that other RSS readers do the same, since the RSS information is usually in the page's metadata.
One thing that's been corrosive to rss the past couple years have been podcast platforms. I find more podcasts (free ones) that can only be accessed through platforms like Google podcasts, Stitcher, Spotify, or Anchor, with no rss feed link to use in a platform agnostic podcatcher app.
Unfortunately, to Spotify's great delight, the word "podcast" has been successfully embraced, extended, and extinguished. Us technical types have been complicit in it by allowing the word "podcast" to mean audio shows on proprietary platforms that require proprietary players.
> Us technical types have been complicit in it by allowing the word "podcast" to mean [...]
Those types have done a lot of the same damage to the word "wiki". It blows my mind that Sourcehut of all places is a willing participant in debasing the term.
The same thing GitHub is doing: throwing a bunch of source files into a repo—i.e. the sort of thing that came before wikis (and the reason why wikis were invented in the first place—to displace those kinds of systems)—but then calling that a wiki. It qualifies certainly as what GNU calls a "Massive Multiauthor Collaboration Site". But to call it a "wiki" is wildly inappropriate—like saying "integral" when you're talking about derivatives:[1]
> Imagine you're a mathematician, and fellow mathematicians start calling derivatives integrals instead; that's basically how badly the term[] is being misused: it's being used to describe systems that are almost the _exact opposite_ of the concept.
Whats missing from GitHub/SourceHut "wikis" that would make them actual wikis? At least with GitHub wikis you can edit them from the web like the wikis that came before GitHub.
Here's how you edit a wiki: spot the typo, hit the Edit button, make your change, and then hit the submit button.*
Many of these new-gen collaboration sites that bill themselves as having wikis result in a request for approval (pull request) instead of an actual edit when you attempt to make a change. (And in the Git-backed ones, the process is usually more egregious; see below.) This proposal/review/approval cycle is exactly what a wiki isn't. GitHub no longer imposes this workflow—there's now an option at least to turn your wiki into, you know, an actual wiki—but even today that option remains off by default so all pages are closed to changes unless the owner makes an effort to toggle the right setting[1]. What these are aren't wikis—they're anti-wikis; if you have a "wiki" that only you can edit, then stop calling it a wiki. (Notably, GitHub's setting doesn't control whether it will continue to advertise it as a wiki or not—instead of just, like, the "docs" tab or something.) Most of these are static sites with extra/fewer steps.
SourceHut is even worse than present-day GitHub, because for all its docs in the man.sr.ht namespace, this is the process you have to use to edit one of its anti-wikis: spot the typo, note the title of the page you're currently on, find the corresponding repo URL in the page footer, leave your browser to clone the repo to your machine, open that directory and locate the source file based on the page title you noted earlier, edit it, make a commit, and then (probably**) push your changes to the original repo. This flies in the face of the definition[2], etymology[3], and entire spirit of the word[4][5].
* Maybe you hit a wall because the specific page has been locked. Fine. Raise your concerns through linked resource for discussions. The fact that individual pages can be locked because e.g. they have a history of being the target of abuse does not negate the meaning of "wiki". If every page is locked down (including pages that don't even exist yet, so you can't go create them), then that makes a material difference—it makes it not a wiki.
** It may not actually be the case that trying to push your changes makes them immediately live on SourceHut—it very well may result in a request for approval by the project owner. No idea. I've never gone through the process on Sourcehut because of how much contempt is deserved by projects that have contributed to the campaign of debasing the term "wiki" to it-means-what-we-feel-like and who-are-you-to-say-that's-wrong levels of uselessness.
Because it was broadcast to your iPod. Where iPod means a non-networked personal media player which in the 00s overwhelmingly meant an iPod.
The distribution model was a client subscribes to the RSS feed on their computer, downloads new episodes (from the publisher's website), and then syncs them when the "iPod" is synced to the computer. Many PMPs but the iPod especially defaulted to syncing your computer library when plugged in (to charge). So the iPod just received no episodes of podcasts when people plugged them in to charge at the end of the day.
When iTunes added explicit podcast support it became even easier to subscribe and sync podcasts. This was and remains a good distribution model but Spotify et al have done their damnedest to co-opt the term to mean content exclusive to their platform.
The history was that "podcasting" was an open medium, "open" being the point. A "podcast" was a show (e.g. "Smartless"). "Episodes" were audio or video files combined with metadata that lived in the podcast's RSS. Anybody could play in that ecosystem.
Now "podcasting" means anything/nothing. "Podcasts" are shows. "Podcasts" are episodes. "Podcasts" are things that increasingly need a proprietary app to play.
Of course it's okay for languages to evolve, but here's how you're missing the point:
Imagine that shortly after the turn of the century, Adobe created a proprietary platform for delivering internet content and called it the "web". Viewers must use Adobe Web Reader to use Adobe "web pages", which are DRM-protected PDF files delivered using proprietary protocols. Adobe has done deals with several hundred popular sites to turn off their standards-based websites and deliver Adobe websites exclusively.
This is what Spotify and others are doing, and nobody cares. Apple is effectively the last media giant left holding the flag for standards-based podcasting, but how long do we think that will last?
What I just love is when people use this excuse to justify "borrowing" a clearly defined technical term, using it incorrectly, and then insisting that their incorrect usage of that term is entirely valid because "language and meaning change over time."
(Not saying you're one of those people at all but that is one of the most frequent uses of that phrase that I tend to experience from other people.)
This doesn't seem particularly closely related to the discussion. The meaning of "podcast" hasn't changed. Instead, the question is "why bother distinguishing podcasts from other mp3 files that you also download off the internet?". If someone records an album and puts it up for sale online, how is that not a "podcast"?
Note that the Google Podcasts mobile app differs greatly from the site at podcasts.google.com. When accessing Google Podcasts through the latter, the feed URL is encoded in a base-64 variant that you have to resort to extracting from Google's show page URL and descrambling. If you want to export your feed list, this can be tedious. (Made worse by how top-heavy the Google Podcasts site is just to load a page.)
Nope. One of the few use cases where I actually looked towards Google Takeout as an escape hatch for my data, instead of a mere novelty ("a ZIP of all my YouTube interactions—that's neat, I guess"), but Google Podcasts is not there. I've filed several complaints about this and several other shortcomings in response to the Google Podcasts app's spammy notifications requesting feedback.
I ended up writing a short set of procedures to follow (an SOP—written like a software manual, really) that walks you through how to select page elements that are shown on screen while logged in, and then drag and drop them from the podcasts.google.com tab into the "export tool". The punchline is that the export tool is just the SOP document itself. It's meant to be read in your browser, and it takes advantage of the fact that the browser also happens to be a universal runtime...
The exporter will descramble the links and output your subscriptions in text/uri-list format.
I got pretty carried away writing the thing as if it were a mid-century technical repair manual for a piece of industrial equipment, and never got around to publishing it but here you go: <https://crussell.ichi.city/gpe.html>
It could really stand to have an associated 90-second video demonstration that walks through the steps because of how unorthodox the the-documentation-is-the-implementation paradigm that I was experimenting with is.
Thanks. Wow, did not notice that you have to click not the globe button or share button, but the three dot 'hamburger' button at the top right in order to see this.
Disagree on 'blaming the creator' argument. Not everyone is aware of these technical philosophies and are focused on getting a good story out there. Feel the same way about social media.
I have only noticed that on spotify, but, without a spotify subscription, I hate it. I have had several podcasts I used to listen to move to spotify-only.
(I actually still listen to them on an Apple iPod nano....)
I could believe it being true of some of other platforms, trying to have "our-platform-only" content but I haven't seen it and am not finding confirmation. I don't think it's true of Google Podcasts, that they have any of their own content.
Yea, but the flipside (patreon) is really, really, really nice and a huge step up from the ad-ridden public ones and work with whatever podcast player you like. Nearly all my favorite podcasts on the platform release half their content for free. I just wish they allowed mixed media in the feed.
It's not dead, but many things I wish supported RSS don't.
Facebook. Twitter. Instagram. These would be incredibly useful things to have native RSS feeds for, but instead I have to dig around and either use some tool someone built for the purpose - a tool at the mercy of the walled garden whose wall they're peeking over - or build my own nightmare factory.
None of those will because they rely on engagement to make money. They need people logging into their servers so that they can see what they are looking at. That's not how RSS works, so of course they won't support it.
And I think this is the main reason Google Killed Google Reader.
It was controversial (or illegal or ugly) to put ads over the third party content.
And it was way better to have Adsense on the websites directly.
Such "spring cleaning" was an alibi, not the reason. It was abandoned after some attempts to build a kind of social network inside, and probably they preferred people to create content on +1 instead of on blogs.
But Blogger still exists, and there's a strong contradiction why to kill the reader for the blogs except one: Ads. Google Reader was bad for Ad business.
And that's a big business in Google.
And terribly sad.
Some places that do offer rss only offer truncated feeds so you actually have to open the website and be monetized and fingerprinted. there are of course workarounds but its an arms race with only a few maintainers.
> instead I have to dig around and either use some tool someone built for the purpose - a tool at the mercy of the walled garden whose wall they're peeking over
My dream is being able to get only the events off my Facebook feed. Invitations, events my "friends" are going to that show up on my feed, events people post on their timeline that would show up on my feed, whatever.
If Facebook had any kind of API I could probably build this, and stop using facebook otherwise. Which is probably why they don't?
RSS is still the default distribution system for podcasts. It's probably the thin thread that is keeping Spotify from building a walled garden for audio.
> […] The company spent a good portion of its presentation specifically focused on podcasts, which it said had been “largely unchanged” for years before its entry into the market, due to the limitations of RSS.
> Spotify cited how unbundling podcasts from RSS technology has paved the way for Spotify to generate revenue through these popular audio programs — a sentiment that’s not universally beloved by those who support an open podcast ecosystem. Spotify has disrupted that market by bringing some podcasts in-house, where they can only be heard on its service, and competitors have followed. This has fractured the ecosystem and left consumers at a disadvantage as some shows are no longer broadly available.
> “We’ve been able to replace RSS for on-platform distribution, which means that podcasts created on our platform are no longer held back by this outdated technology,” Maya Prohovnik, Spotify’s head of Talk, told investors.
The entire framing of this (esp. re "unbundling") is pretty gross. Unbundling is associated with disintermediation. What Spotify is doing is the opposite. What organizational dysfunction led to the circumstances here—where the writers and editors of the linked article uncritically publish and more or less legitimize this kind of shameless corporate spin?
The whole article is pretty much just re-wording Spotify's press release.
There seem to be no sources in it except for Spotify's press release.
So, a very old form of organizational disfunction in journalism: The cheapest and quickest way to write an article is to use someone's press release as the only source, as it doesn't actually require, well, any journalism.
Spotify has never used RSS, other than for Roach Motel-style ingest.
The plan was to embrace, extend, and extinguish the podcasting medium, and the hard part of that is done. "Podcasting" was a standards-based, open medium. Now it's any audio show, and we've lost the unique name for the open medium. As Spotify incentivizes more and more creators to not publish an RSS feed, standards-based podcasting will become a fond memory.
I also boycott them for a more practical reason: I can’t listen to them in my normal podcatchers! I’d have to switch all my podcast listening to Spotify to change that, and that’s a pain.
Spotify has started and rapidly escalated a program to pay podcast producers for spotify-only podcasts. (with no rss feeds). Several podcasts I used to listen to and enjoy have become spotify-only.
When I recently asked friends for podcast suggestions... several were spotify-only, i don't think the suggestors even realized it, cause they just listened on spotify anyway regardless.
So I think Spotify agrees with you and is working on it...
+1 for Feedly, although I use Feedly Classic on IOS for a more concise, no-frills UI. I really appreciate the header + summary without thumbnails format for quickly going through large-volume sources (like HN).
I dropped Feedly because I found that 90%+ of my feeds would only put the article title and the first sentence into the feed, then require I click the URL to pull up the full article.
It wasn't very fun constantly having to switch between my RSS app and my browser, so I just stopped using it.
This is an issue with the site's RSS feed, not Feedly. Feedly has an option to open any individual feeds posts in an in-app browser directly (and if you're on iOS, even enable Reader mode!) to combat this, so you don't need to switch apps!
I use Reeder for iOS + Feedly. What the OP describes started happening to me with all sites at the same time 2 days ago. Interestingly, it does not happen on the main Feedly site. So I do think that Feedly is making the experience worse with third party readers. I would speculate that this is done because third party readers don’t show ads.
We let publishers decide whether to showcase their content via a full feed (ie. full text and multimedia content can be read through a reader app) or a partial feed (ie. only showing limited text, inviting readers to browse full-content directly on their website). The choice is entirely in their hands.
Some publishers offer full RSS feeds as one of the benefits of their subscriptions. It might be something to explore for your favorite must-read sources.
I use inoreader and had the same problem. But solved it by installing a plugin to Firefox, that closes current tab with back-button if you are at the start of history.
Inoreader also has a button to show full content. But it's not working for all feeds.
Yeah this really sucks. I think some do this for paywall reasons, but there are definitely models out there to allow in-reader paywall access. Stratechery has an interesting approach - when you subscribe you get a unique feed that can be cancelled when you stop paying.
Same. After Google Reader I went with Feedly for a while, then self-hosted TTRSS, and currently self-hosted Miniflux. Miniflutt is my preferred Android client and ReadKit on Mac. The Miniflux web app is nice and simple but I prefer clients that mark as read on scroll.
I occasionally venture onto Reddit or HN to see if I've missed anything big but rarely do.
Not necessary, but nice: can be monetized in a healthy way via things like API tokens. I have a few podcasts whose RSS feed endpoints accept a unique, revocable token and check that server-side -- but the client needs only the ability to pass query params in the URL (which it should have anyways). It's a great way for creators to get paid without imposing on their users.
> There's still this lurking mess of RSS 0.91 vs 1.0 vs 2.0 vs Atom.
Maybe in theory, but as a heavy RSS user this has never been an issue in practice. For example, WordPress sites support both by default — RSS at /feed/, Atom at /feed/atom/, but apps like Feedly hide this implementation plumbing during normal use.
I’ll repurpose an older comment[1]. It was in response to “I doubt very much [JSON feeds] will catch on”.
> There’s little incentive for websites to change to JSON feeds when their RSS feeds are already implemented, working well, and generated automatically. But several good RSS readers added support for JSON feeds when the format was introduced and that’s all you need for it to be viable; it isn’t important if it “catches on” after that when the flexibility is there.
> JSON feeds were great for me because I generate my own feeds for personal consumption and can now do so with simpler code. I understand I’m in a minority—most people consume feeds and never create their own—but the larger point is JSON feeds may have already done their job: they exist and are supported if you need them.
It was created taking some lessons of Atom into account.
It does have a few minor advantages: multiple attachment support, more "branding" images support (author avatars, post "banners"), easier to build JSON than XML in most API backends these days. The one major advantage is that JSONFeed is easier to work with it in tandem with WebSub and other pubsub systems that assume messages are natively JSON, you can use the same JSONFeed item generating code for both pull (HTTP GET) and push (WebSub) scenarios.
Certainly even the main advantage isn't a huge reason to switch to JSONFeed if you've already got RSS/Atom feeds, but I believe the hope for JSONFeed was always that it would spark some sites/backends that don't want to support XML, don't have good XML libraries, or don't want to use their template languages to drive RSS/Atom feeds to be able to build something simpler instead resulting in more feeds overall than if things were just left to the XML-ish status quo. I don't know how successful it has been on that front, though, but I appreciate it exists for trying.
> Are there any technical reasons to use RSS instead of Atom in new deployments?
There's no technical reason. Unfortunately many CMSes still emit barely usable RSS v2. There's also the branding issue of RSS the format essentially being the name of the technology. Someone saying "I want an RSS feed" ends up with the implementer making an RSS v2 feed rather than a better Atom feed and just labeling it RSS.
I know XMPP is not as popular these days, but there is an XMPP extension for pushing Atom stanzas as a sort of the push complement to RSS.
… and using Slack to consolidate RSS turns RSS from pull to push. (Slack probably has caching mechanisms across all workspaces to reduce pull bandwith).
Do you know if there is a name for that XMPP/Atom pubsub service, and if web publishers can put up some kind of icon so people know they can subscribe to that kind of a feed?
Is there any way outside of just polling every 1~5 minutes to get realtime updates to RSS? Curious what is standard here? If you do do polling, what interval?
I usually do 60 minutes. I'm not desperate enough to check every 5 or 10 minutes. I've come across a few websites that block you if you refresh too frequently. I'm not sure whether those ones still do that though.
If you need realtime update, then RSS is probably not the right tool. For polling, I currently do the following:
* with `HTTP 304: not modified` result, I'll come back in 60 minutes
* if there is any update, I'll come back in 4 hours
* if there is no cache control header, such as etag or last-modified, I will poll every 12 hours.
Apart from websub, which does require some resources, servers could provide long-polling such that the socket remains open, and give a reply as soon as there is one. Clients don't poll, servers aren't flooded (but do need to keep an open connection )
Funny seeing this pop-up on my #hacker-news slack channel that periodically polls for the top stories :)
I actually prefer the ability to push things like the top stories of the day to me through either Slack on email rather than having the temptation to constantly refresh an RSS feed app. An added bonus is that I frequently add some custom logic to curate the feed to my liking (based on the feed).
I've been using Blogtrottr to email me my RSS feeds for whatever I'm following. It's run without any hiccups in I think over 10 years. I have tons of feeds just emailing me every day and I skim through them and read whatever I find interesting. It's really awesome, much better for me than anything else.
I haven't heard about blogtrottr before, but landed on a similar idea and built RSS-to-email service for myself and opened it for others (https://briefcake.com). Mainly, I did it to battle my pointless social network and doom scrolling addictions -- and it worked amazingly. I spend less of my time on internet, more of my time with kid.
I'm slowly extending support for other social networks, to my surprise, they are not that "social" and it's quite a pain to scrape anything from them.
Yeah I also use a simple rss2email utility that I hacked together. Having feeds in my mailbox means I can search/filter and tag them appropriately.
A lot of these online feed-readers have terrible UIs for managing large numbers of feeds, but I guess they allow the same benefit of keeping track of state (read vs. unread) that email also offers.
That reminds me of a project we did years ago for a large Dutch public transit company. We built an app with push notifications, and sometimes they needed to do big announcements to all users. We made our push notification back-end poll an RSS feed from their CMS every minute or so, if there was a new one on there it would get broadcast to all users.
It... wasn't ideal though, in hindsight we should've hacked together a UI so that the people sending the message could confirm the message and see how many people would be receiving it first. There have been a few Incidents of accidental test messages sent out. One was my fault, early on, because production and test were the same machine. The other was the operators' fault, but by then the app had two million installations and it caused a bit of a social media storm that day (#hajo).
It was funny to see that one play out, and how quickly there are print companies making and advertising merchandise about whatever is trending on twitter that day.
Honestly, this has been one of the hidden gems that gets so many people to stick with our service Murmel (https://murmel.social). We support RSS feeds everywhere.
It wasn't long before people discovered that and began using our service to deliver relevant stories to their Slack teams and stakeholders. As the author says, RSS is the closest thing to an open MVP-style API that "just works," and hasn't been plagued by a company's closed garden rules.
I loved blogs, I loved the vibe (like newsletters today) and I loved RSS (way better than email for receiving information. IN fact I am creating a project, and It will have updates by RSS. Why? Because I f**ing love it.
I think what really and significantly curbed RSS usage what Google reducing effective tooling (allowing you to see/subscribe to RSS in the browser) combined with killing Google Reader. Of course by that time, half my feeds were just links to the full URL (ads and all). Then, they take the next step and introduce AMP, which is really cool in a way, but effectively makes Google the gateway to it all, and Google Ads especially.
Google makes ad revenue, cuts out most of the sites themselves and increases google value, while reducing the value of the actual site producing the content.
I think it's that it feels like a dead product, even though it's still running.
Not a lot of new features being developed, and some features getting turned off "to support the product's next chapter"[1].
There hasn't been a firm announcement about Feedburner being sunsetted, but given Google's history of killing things off (including Reader, apropos of this thread's topic), it does feel like the walking dead.
> You can sign up for emails that go into the black hole of your inbox
I feel like Slack has already become a black hole equal to my Inbox in all respects and am hopeful that the Interoffice Mail envelope will stage a comeback for the things I really need to see.
RSS never seems to work on Windows. Funny when it is so simple. I did not realize this before. A simple client that fetches a feed, parses it, and searches the content for a keyword took me ~25 minutes to implement.
I've been using a little matrix app of my own making that sends notificatins to a specific matrix room when big jobs complete. Its nothing fancy (and conceptually not different than slack notifications), and sysadmins have been leveraging email for the same exact purpose...but i like me some matrix...plus, said same matrix room can be made to receive other/outside notifications too; win-win!
Just a few days. It’s done by running an external service that joins rooms and listens for commands. We’re using maubot [1] since it’s one of the more popular ones, but it has some rough edges [2] [3] [4]. Our setup for just the “rss” plugin is dockerized and documented here [5].
The only thing I'm not satisfied with reading news on RSS, is that news organizations push too many articles, to the point that reading the headlines alone takes quite some time. There's nearly 100 articles per day per source sometimes. Unlike a newspaper, which has a natural structure of priority and hierarchy, in an RSS reader, every head line has the same salience, and it's a pain to weed out what's important.
I kinda hope news organizations would make a separate "weekly digest feed", 30 or so articles per week.