Hacker News Reader

Comment by Havoc | Hacker News Reader

RSS has more of a commercial problem. You can’t put ads in it so sites are incentivized to force a site visit. Which in turn forces them to withhold the bulk of the value from the feed itself. Ie just include first sentence or two. Which kills the usefulness of the feed as anything more thank headlines and link. Headlines in turn are all clickbait these days so those don’t have much info density either.

View on HN

> You can’t put ads in it

That's a silly thing to say. Of course you can put ads in it since it allows linking to things. What you mean probably, is that it's not as easy as embedding some google ads markup in your sidebar.

What you can't do, is add all sorts of invasive tracking to RSS to confirm that the user saw the ad, and that it wasn't filtered out. You have to get more creative with wording that works the ad into the descriptions for the articles, and even then, there's no guarantee.

Advertisers love to burn money, but they draw the line at not being able to verify that the spend did what was promised.

This is definitely false, see Facebook's pivot to video.

Wasn't that famously based on advertising network lies?

You can add an image, can’t you? So the situation is not worse than email, and there’s plenty of tracking there (that good email clients block, but that doesn’t matter in a world where almost everyone uses the Gmail web UI).

It's a little worse than email.

With email, you normally use unique image and link URLs for each recipient, so you generally know who's opened the email and what they've clicked and can map that to their email address and whatever other information you have about them.

With RSS, you generally don't have any information about who's accessing the feed other than an IP address. It is possible to require users to log in and receive a unique RSS URL, which is what podcasts often do to give paid subscribers access to paywalled episodes, but that's not common for web RSS.

The exact same techniques used for email can be used for RSS. You could generate unique links for RSS too, based on requester headers, in the same way way web fingerprinting works. There'd be a bit of computational overheard in comparison to serving a static XML file, but it seems easily doable.

Small problem was the way feeds worked in practice is you had various services caching the source feed and consolidating everything for its users like Reader and Feedly and others. Multiple startups around this.

Even the injected ads idea was tried with companies like FeedBurner, later acquired by google.

Not that much different from any other form of content aggregation. Web links posted to HN or Reddit also either strip out individualized links or conflate everything together under the same link. There are plenty of solutions to this.

If you're generating feeds on the fly with tracking metadata based on the requester, you can identify aggregators, and treat them equivalently to social media platforms where users circulate normal web links. You still get click-throughs to the underlying content from the end users, and you'll know the aggregator was the referrer.

Many podcasts use direct ad injection using metadata from the request to the enclosure link -- that seems to work well enough, and seems like the sort of thing that could be used for other content than just audio and video.

I really really really object to being tracked in emails with poisoned links (without being told or having a sensible opt-out, usually, so also illegal under GDPR I believe) and it is one reason that I will not sign up to them.

Of course you could manually put ads in your RSS feed. What you can't do is use an ad network (3rd party javascript), but if RSS was actually popular, that could be solved.

> that could be solved

Let's not. Please.

You can have that on your website and put a summary and a link to your website in the feed. That's been a common approach for a while.

If RSS has been more common, I imagine the bigger RSS readers (bearing in mind one of them was from Google!) would also have standardised on other ways of tracking clicks and ad views and all the rest. There just weren't enough people interested in RSS to make any of that worthwhile.

I say this as a user of RSS and someone who publishes a (very sporadic) RSS feed. It's a niche, because most people don't want to curate their own feeds.

FWIW, there were attempts to build an RSS Ads product at Google: https://www.eweek.com/c/a/Search/Google-Puts-RSS-Advertising...

Everywhere that ads are the only way to create revenue streams, that should be considered a commercial problem in itself. It should be way easier to pay (and charge) securely for services like this by now.

Most ads seem to be unwanted, but some of them seem to work to make the nuisance worthwhile. People regularly stumble upon content randomly, and get exposed to ads.

Paying for content is a conscious action, it has a higher activation threshold than just clicking mindlessly on something that looks fun.

Then, transactions are expensive; micropayments are not a thing.

Subscriptions alleviate that a bit. Large middlemen alleviate that even more: Apple and Google can make micropayments like $0.50 viable within their ecosystems, so apps or in-app purchases can be tiny, and allow to remove ads for paying users. Attempts to do something similar for websites never took off, sadly.

John Gruber (Daring Fireball) has made his entire living for 20 years by putting a once a week sponsored post in RSS along with the full content of his posts from his site in RSS.

There are also some efficiency-related shortcomings. I'd wager that most feed readers either implement conditional requests incorrectly, or they don't implement conditional requests at all. Polling rates also tend to be stupid, on the order of 1-30 minutes with no regard for how often any given feed actually has new posts. This creates server-side pressure to make your feed as small as possible, which always means excluding content.

The first point sounds like an implementation issue rather than a protocol one. I also don't agree that most readers have this problem.

Polling rate also has nothing to do with frequency of updates if you care to receive those updates in a timely manner. I haven't seen a reader default to 30 minutes or less.

Probably in both cases you just notice the bad implementations more because they make more requests.

And Atom supports pagination so you can limit the main feed url to be just one entry while still allowing for clients to retrieve older ones.

My only Atom feeds are already short, and the paging mechanism would I think be hard to do in my static site, but yes, thanks for the reminder!

Yes indeedy. My one-update-per-month feed gets pulled over 10 times per hour by Podbean for example:

https://www.earth.org.uk/note-on-site-technicals-99.html#202...

10 times per hour? Yikes.

I'm a small enough deal that I can call out specific readers at the top of a new post. A couple weeks ago I put up a post that started with the aside "hey one of you has a Turkish IP and you're pulling the whole feed every 10 minutes, please stop doing that."

I think that I probably average < 1 listener by any sensible metric! B^>

(The podcast where I capture primarily audio material such as voice or sonfification that might as well also be presented in this alternative channel form...)

I'd be interested to listen to your podcast if you were to ping me its URL via one of the contact methods in my bio...

Why can't you put ads on RSS? Either in the story itself (by the site or aggregator) or as a "promoted item" in the feed (by the aggregator). If anything, the Google Discover (or whatever it's called) is not too different, just that you don't control which exact news sources you're subscribed to.

I can imagine an alternate timeline where Google Reader turned into a sort of Twitter (or FB or IG) feed.

I'm just here to say that I'm still bitter about Google Reader. :-(

Ads are a recent innovation on top of existing web standards. A new generation of changeable scripted ads had emerged and this was not compatible with XML. The old generation of ads was still compatible but not scalable, similar to how podcast sponsor ads work (immutable after publishing), and so did not get much traction.

Podcasts ads are definitely mutable after publishing. Dynamic ad insertion has been a thing for years. If you download an old Stuff You Should Know podcast, you will get a new ad even based on where you were when you downloaded it.

And where you(r GeoIP data) were as well. I remember a lot of local car dealer ads being on that show for a while.

Some podcasts do dynamic ad insertion. It has a plethora of inconveniences, but it does exist. I’d rather it didn’t but here we are.

Sounds about right.

Podcasts inject ads into the content: from RSS you get the link and description of the episode, and inside the episode are ads.

I guess that's why RSS is still a thing for podcasts? :-)

why not? you can format ads as an entry in the rss feed. in fact it would not even bother me. i could train my rss reader to detect the ad based on keywords and mark it, and even if not, i'd just skip over it manually, mark it as read, and it's gone. as long as the frequency of ads is not to much that is better than an ad on a website that is permanently visible.

I only put a summary of each item in my RSS feeds because I do not want to be redundantly sending the same body data over and over but I do want a complete history available easily in at least some versions of the feeds. And some of the primary content is audio (or video) so cannot be dumped into the RSS usably.

It's more like a one-way problem. Authors don't know how far the RSS reached nor who reads the articles.

Readers don't know how to reply to the author in a standard way (like an email)

FreshRSS on android will fetch the full article. Such a good feature I wished more applications used.

I host freshRSS and it's been amazing for me.

Also https://lireapp.com on iOS and macOS, has optional local cache of text and images for offline reading of RSS feeds.

Man, RSS still brings me so much nostalgia. Anyone still feel the pain when Google discontinued its RSS reader?

> Anyone still feel the pain when Google discontinued its RSS reader?

Yes, but mostly because of a lost opportunity.

I was working on my own web based reader when Google made a significant upgrade to their reader. It was similar to what I had made, so I thought it would be foolish to compete with Google and stopped working on it.

I wonder where RSS would be now if Google had not discouraged potential competitors.

Feedly works more or less the same. I have no issues with it.

I hate that the self hosting newsletter does this.

Reply on news.ycombinator.com