Live data from Hacker News

I've been advocating for RSS support, and you should too

reedybear.bearblog.dev

231–240 of 248 posts

Re: I've been advocating for RSS support, and you should too

#231

Earlier quoted context omitted.

A publisher does not want countless browsers scraping arbitrary web pages just to see if they’ve changed when they can instead offer a single lightweight end point specifically for content that is intended to be updated. If browsers started doing this scraping I can only imagine the arms race. I can only see this happening as a service. A company crawls the web—probably a search company. Their LLM classifies changes.…

This was part of the technical justification for RSS: concentrate all the redundant page hits in once place. But another reason was that parsing an article list from messy tables-based HTML was harder than it is today with HTML5. There's even a feed attribute `h-feed` available today, which effectively turns list pages into feeds. Nobody uses it. The problem with the "single lightweight endpoint" is that it has to be…

> A solution involving client parsing of semantic markup at least has the benefit of requiring zero maintenance.

This is a pipe dream. In reality your HTML markup needs just as much maintenance if not more - at least the separate feed is unbothered by design changes to the HTML site.

Re: I've been advocating for RSS support, and you should too

#232

Earlier quoted context omitted.

OK I won't dispute that. The problem is that they would function nicely as a pragmatic solution to the underlying problem. Maintaining a few HTML attributes on an existing webpage is significantly easier than maintaining an RSS XML endpoint.

RSS 1.0 was created in 2000. We are talking about a time where the browser that dominated the market was Internet Explorer 5 , where virtually no website would render on strict standards mode, and MS refused to introduce any significant changes if it meant breaking its compatibility mode. People realized that that asking the whole web to adopt XHTML fully would never happen, so a new XML-based format hat was separate…

> Also, a bit of a side rant: now that I am working on ActivityPub stuff I'm finding less and less sympathy for those that jump into code and push for "pragmatic" solutions. The ActivityPub spec is not perfect, but it's incredible how almost everyone implementing ActivityPub ignores JSON-LD and RDF and just want to wing with the JSON messages. It gets to the point where perfectly valid JSON-LD will get refused to anything that is not called Mastodon, because everyone else is just parsing the JSON they receive and completely ignoring @context directives

Maybe making everyone who wants to interact with the fediverse deal with all that complexity isn't such a great idea after all. What we really should have gotten was RSS++ with optional push notifications for new content instead of this mess. But it wouldn't be the web without reinventing the wheel for every new "standard" I guess.

Re: I've been advocating for RSS support, and you should too

#233
post #142

I recently had the need to subscribe to changes to a Github repo and it turns out it provides a feed for them. For rust master branch, for example, subscribe to https://github.com/rust-lang/rust/commits/master.atom .

Is that feed linked anywhere? I discovered this before and am subscribed to a couple of those feeds but I add new ones rarely enough that I always need to look up how to build the URL.

Re: I've been advocating for RSS support, and you should too

#234
post #85

Question about the RSS spec: When pulling RSS, how do you know how often to poll? How do you know which items have been seen previously?

rachelbythebay has a service and a series of blog posts about the technical side of this, starting at https://rachelbythebay.com/w/2024/05/27/feed/ TL;DR: readers should not poll more often than once and hour, use ETag and If-Modified-Since to determine whether to download the full feed again. Which items you have seen previously is something the feed reader keeps track of.

Polling every hour is excessive and will get you temp-blocked on some sites.

It really depends on you but IMO for most feeds polling once a day is plenty.

Re: I've been advocating for RSS support, and you should too

#235
post #211

Earlier quoted context omitted.

> Which items you have seen previously is something the feed reader keeps track of. Is there a particular field that can be used as an identifier?

Yes, the `guid` field in RSS and the `id` field in Atom.

A lot of readers (intentionally?) get this wrong though and show entries as new/unread if there are changes to the content.

Of course a lot of feeds also get this wrong and change the GUIDs for existing entries once in a while which results in strictly compliant readers showing you the entire feed history as new. Really annoying.

Re: I've been advocating for RSS support, and you should too

#236

The problem with RSS today is that bad actors use it to scrape and rewrite content using AI. Not having it enabled makes life harder for them since many are too lazy/not savvy enough to use other means to steal content.

FUD! Name a single AI scraper that fetches RSS but not HTML.

Re: I've been advocating for RSS support, and you should too

#237

I love RSS and I actively used it until modern browsers dropped support for it and then websites stopped using it. I always felt RSS being dropped wasn’t the choice of users but more a conspiracy between those browser developers (or rather their managers and company leaders) and marketing/sales departments of pretty much any company that advertises on the internet: Google being the main one. Why? You can’t bombard RS…

I'm unhappy about browsers dropping RSS support too but did you or anyone else actually use the browser integration for anthing more than discovering that an RSS feed exists?

Re: I've been advocating for RSS support, and you should too

#238
post #187

Earlier quoted context omitted.

I don't think so. If you print the HTML, it's often full of " ", images and links unrelated to the actual content. It's hard to extract the meaningful part of that pile of stuff in a trustworthy way (and you wouldn't want to lose information). Also many of those emails are autogenerated. So the template has to be done once, and that's it. And it should be trivial for whoever composes the HTML email to copy-paste…

Decoding   and other entities should be part of converting the HTML to text. This is absolutely basic. > So the template has to be done once, and that's it. Except the world is not static and then when the HTML template gets updated they'll forget the text template and now you are missing vital information. Perhaps even legally required information like unsubscribe links. Supporting text email only makes sense i…

I'm not saying it's impossible. I'm just saying that they make my email experience worse by only sending HTML, and most (all?) of the time, it's absolutely unnecessary.

And again, HTML brings security concerns.

Re: I've been advocating for RSS support, and you should too

#239

Earlier quoted context omitted.

RSS 1.0 was created in 2000. We are talking about a time where the browser that dominated the market was Internet Explorer 5 , where virtually no website would render on strict standards mode, and MS refused to introduce any significant changes if it meant breaking its compatibility mode. People realized that that asking the whole web to adopt XHTML fully would never happen, so a new XML-based format hat was separate…

> Also, a bit of a side rant: now that I am working on ActivityPub stuff I'm finding less and less sympathy for those that jump into code and push for "pragmatic" solutions. The ActivityPub spec is not perfect, but it's incredible how almost everyone implementing ActivityPub ignores JSON-LD and RDF and just want to wing with the JSON messages. It gets to the point where perfectly valid JSON-LD will get refused to any…

But this wouldn't give you two-way interactivity, and RSS and ATOM are just different ways to go about representing RDF.

I could entertain the argument that we don't need two way interactivity, and that most of the applications would be fine by implementing their own ad-hoc API. This is exactly what is happening in the Fediverse now, where every microblogging project ends up implementing Mastodon's API and every Lemmy client goes straight up to Lemmy's API instead of getting the data from "raw" ActivityPub.

Re: I've been advocating for RSS support, and you should too

#240
post #163

Earlier quoted context omitted.

Thus is a pet peeve of mine. Some companies send an multi-part E-Mail, just for the plain text part to be an empty string. Why bother? Pretty often the plain text is just the same html, so you get to read raw ugly html. Do people not test this?

I'm pretty sure they don't test them. I got a good one the other day from a well known institution. It was a bill and the html part said I owed N amount but the plain text said 0.00. By default I read the plain text part but when I saw it says 0.00 I thought it was odd so checked the html and there it was the correct amount!

That would imply developers/testers default to reading html-formatted text, which I honestly find hard to believe.
Post reply on HN