Where I have RSS feeds from news sites, I usually skim down the list of titles, read an article (in my feed) if it's interesting, and then move on. I never visit their website, I don't see their adverts, their tracking scripts can't run, and I don't see or interact with their comments.

Which is great for me as the end user - but makes it much harder for them to monetise.

Nobody's forcing them to put the full text into the feed, for me the main benefit is not having to check the site manually.

As the consumer, that's a big benefit, and the main reason I use RSS.

But for the company running the website, the fact that you're no longer browsing to their site, being served adverts and tracking code, and seeing what's on their homepage is not a benefit

> makes it much harder for them to monetise.

On the other hand, RSS definitely provides extra opportunities to monitise. Imagine your business provides a customisable "offers" feed so you can tell interested parties when a sale occurs, etc. Businesses should be falling over themselves to get that kind of engagement.

That just sounds like a mailing list, but without the ability to easily identify and track the individuals you're sending to.

So... a win-win? RSS also avoids all the problems associated with spam.

Not everyone is out to monetise (e.g public sector). And even if you are after monetisation, sending out a teaser snippet makes sense. The user can decide if they want to visit the site to read more, subscribe etc.

Le Monde will tell you that you only got 70% or so of the article in your feed and you need to go to the site to get the full article. Why don't more feeds do that? Actually, I am unsure if this is the feed itself or the fact that my RSS reader scrapes the sites too.

Some sites even have different RSS links for subscribers only that give a full feed.

> Podcasts typically use RSS

I would even say that a podcast that does not support RSS is not a podcast, it is something else.

I would be curious why you think the idea of a podcast is coupled to a specific distribution technology

I'd be curious how you define podcasts and radio shows if you don't consider the distribution method. I don't see much light between the two other than the fact that a podcast show list is distributed via RSS.

Similar to why radio relates to electromagnetical transmissions in the radio spectrum. When it happens over internet, we don't call it radio, but possibly internet radio. RSS was the origin of podcasts, and if it does not involve RSS, it is not podcasts

Because the original idea of what we call "podcasting" is rooted on RSS.

The idea of what we call “writing” is rooted in stone tablets and chisels, but we still call Shakespeare a writer

There has been a significant longer amount of time between ancient civilizations and Shakespeare compared to today and l the first people who are recording audio content periodically and distributing it via RSS.

It goes much further than that: as the name suggests, it's coupled to a specific, obsolete brand of device.

I'd say that the only thing that reliably differentiates a _podcast_ from a _radio show_ is just that the podcast's method of delivery is RSS.

I don't think it is the only thing, but I agree that if the delivery method is not RSS, then it is something else.

I don't agree plenty of podcast are only on YouTube and twitch and never bother to setup a proper RSS feed, it was so annoying I developed a project to fix it for my self

https://github.com/madiele/vod2pod-rss

Because RSS is "too old"...

It comes down to a push versus pull architecture. RSS is pull based, you aren't notified when a feed is updated. Most people today want push based with a feed, with all the bells and whistles of a social feed that is updated instantly.

Federation comes in mainly because push based systems require a server managing who follows who, what is posted, and who to notify of updates. That's a lot of information for one central service to be responsible for, leading some to think its better to federate and trust a bunch of servers to host copies of some or all of that same data.

Right, those are good points.

Still I can't help but to wonder whether those notifications are needed or not. Except for instant messaging, I generally don't want notifications. Like I don't need to be told that a new podcast is available, I'll see it next time I open the app.

I would like to at least have the choice to use RSS instead of having to go through a complicated federated system.

That's actually the main reason I still use RSS, I never found a need for most notifications and the complexity required to manage a push-based system aren't worth it to me.

Even if I'm using someone else's system, I just don't like the idea of giving them a reason/need to manage all that for me. RSS works fine 99% of the time.

The push-based federated systems could still be built on top of RSS - have a pull-based feed as the source of truth and then optional push-based notifications for those that want more timely updates.

Ideally the push-based parts would be optional for both ends so you could host a static feed and still have people see those updates in their fancy fediverse apps, just not immediately when you post them.

Instead we have a completely different standard without a simple core that you can easily implement if you don't need all the bells and whistles.

> RSS is great. Most blog engines support RSS by default.

The people creating websites often don't know that they're providing RSS feeds though, and never link to it.

To solve that I developed a tool that finds RSS feeds, even if RSS autodiscovery isn't implemented: https://lighthouseapp.io/tools/feed-finder