Hacker News Reader

Comment by Retr0id | Hacker News Reader

> Why does it just have to be updates to a website? RSS can be used to distribute all sorts of information.

Such as? Maybe I'm just not being imaginative enough but I could really use some examples here.

Here is what I use RSS for beside tracking blogs, news sites, review sites, and so on:

- Notifications from Bandcamp artists/labels -- These come as emails as bandcamp doesn't have personalized RSS feeds, but I use imapfilter to generate an RSS feed [1]

- Tracking release of various software projects I run in my homelab (nextcloud, home assistant, vaultwarden, ...)

- Following creators on youtube -- I HATE HATE HATE youtube's interface. I'd rather just subscribe to a specific creator and be able to clearly see all their videos IN ORDER.

- Home Lab -- All my cron jobs in my homelab send their output to RSS feeds hosted locally. Much better than email reports.

- Sub-reddits -- There are a few subreddits that only Mods can create topics in (like r/Keep_Track). Reading through RSS is great.

[1] https://blog.line72.net/2021/12/23/converting-bandcamp-email...

Mastodon has inbuilt rss feeds for every user, for any given hashtag on an instance, etc.

Eg https://mastodon.social/@gargron.rss

This still feels like "updates to a website" to me. Each entry is ultimately a link to a webpage.

To me, the "default" use case for RSS is blog feeds, and this is just micro-blog feeds.

Everything is a website these days.

Even code commits. https://github.com/torvalds/linux/commits.atom

Why do you need to insist, when you got a good answer? Or what do you want sent with RSS that can't be sent?

Anything that has updates and doesn't need to be an instant notification.

It's rather the other way around. Nowadays everything is a website.

News is a website. GitHub commits, pull requests, issues, etc. are websites, too. Social media posts or replies are websites.

Some of those use cases used to be handled by mail, some of them are now done with browser notifications. I would consider a persistent standard log a need that is not handled by anything else than RSS though.

> Anything that has updates and doesn't need to be an instant notification.

I wonder if there's an easy/obvious way to enhance RSS with instant (or near-instant) notification capability. Perhaps HTTP long polling/Websocket? For small setups, it wouldn't scale/cache as easily as "check this URL every hour, and remember to include ETag/If-Modified-Since", so perhaps for public feeds it could be done via a specialized aggregator / caching proxy network? Maybe model the API after Pushover? <https://pushover.net/api/client#websocket>

Use cases is any kind of feed that can update in very short intervals (minutes), or benefits from quick round-trip times, but the exact update frequency can be extremely irregular. For example status alerts, social media posts, blog/forum comments, security updates.

“websub” is what you are looking for: https://www.w3.org/TR/websub/

It seems this is a server-to-server protocol? Subscriber is required to accept HTTP requests, which makes it mostly useless for most contexts where RSS is used.

It's a little funny to me that the response to "these notifications don't need to be realtime" is "let's make RSS realtime"

Because there are applications that could benefit from it?

Because the proposed solution complicates RSS in what it was designed to solve

Podcasts run on RSS

This was the mainstream killer app for RSS. And it was great. But then some podcasting services (looking at you, Spotify and others...) decided to force us to use our browser or some app instead of giving us the freedom to download files for offline use.

But the gatekeepers kinda failed. Spotify all but admitted that their podcast move failed, effectively writing off their investments in Rogan etc.

> then some podcasting services (looking at you, Spotify and others...) decided to force us to use our browser or some app instead of giving us the freedom to download files for offline use

Podcasts are pretty simple, and those services you're talking about aren't podcasts—nor is anything else that keeps you from downloading files like that (say, for transcoding and then dumping into/onto your player to listen to it how you want). It's not even as if insisting that people not say "podcast" when talking about something that clearly isn't one leaves us without a way to talk about them.

In the first place, "podcast" is not a genre label. There are tons of (actual) podcasts that don't follow the unscripted-banter-plus-question-and-answer/interview format.

And in the second place, all those things that do stop you from downloading them? Yeah, we have a word you can use already: they're just "shows".

Back in the experimental 2000s my RSS reader* could subscribe to a shell script. I remember I used that funktionality for monitoring the success of some long running downloads or something like that. More a proof of concept. Oh, and that was a very lightweight functionality for rewriting feeds with a shell script or `curl | sed`.

* NetNewsWire 3.2

Simple example: I have a Twitter-like timeline on my website, with short texts, images and sometimes a link. I also can 'retweet' feed items from other people on my own timeline. In a sense the accompanying RSS feed shows updates to this timeline and thus my website, but it makes more sense to see this timeline as the webview of my RSS feed. In my use case the feed feels more stand-alone.

I don’t know why updates to things like Adblock filters aren’t distributed over RSS

I presume you have in mind framing each item as a diff, and storing, say, the last week’s worth of diffs (beyond which point you’ll need to download the full thing separately)?

The criteria aren’t usually that large so could be inline, or, as you say, could be a diff with a link to the full thing if the current version installed is too old.

What would be the benefit?

Instead of spinning any update infrastructure you just use existing RSS library code.

Can you be more specific? Existing update "infrastructure" as I understand it consists of updating a file so that when you hit its URL you get the contents of the new filter list instead of the old one. RSS is the same mechanism—you rewrite the contents of /feed.xml, for example—but for no net benefit—it just adds a layer of indirection, plus you deal with "XML" containers. That is, the format looks like XML and even pretends to be XML but very well may not be, due to the legacy of RSS.

RSS lets you easily load older versions, not just the latest.

They're just .txt files on a webserver: https://github.com/uBlockOrigin/uAssets/tree/master/filters

Any updates would work, when/who you last fed the dog. The pubdate can be in the future. You can share upcoming events.

I use a cron job to update a to-do RSS feed of different recurring tasks for example.

Reply on news.ycombinator.com