Hacker News new | past | comments | ask | show | jobs | submit login

>My podcasts arrive using a different app with the backing of the RSS standard, not Spotify's internal standard.

I know a lot of people will disagree, but I think Spotify did a good job of handling the problem of "premium" podcasts.

There's no way to make a "premium" podcast (one you charge people to access) that is fully compatible with the original open vision of podcasting. You can either pervert the original RSS enclosures system by using obscure / personalized URLs for individual subscribers (a leaky abstraction that both discourages open sharing of feed URLs and fails to properly close off access) or you can pervert it by wrapping files in DRM (Apple's approach in the Apple Podcasters Program).

Instead of perverting the RSS feeds, Spotify opted to pervert (slightly) the term "podcast" to not strictly mean "in an RSS feed and listenable on any client." I think this was inevitable and arguably had already happened and is far better than corrupting the open ecosystem. It also happens to be far easier from a UX perspective to tell someone to just use the Spotify app.

For all the people upset at Spotify, consider the counterfactual: Why would they tell people to listen to their premium podcasts by copying a custom premium URL and pasting it into some random client (which 99% of the time on iPhones will be controlled by their bully Apple)? It is much clearer, easier for the user, and better for Spotify's premium creators (who don't want to lose listeners to a complex setup system) to just tell them "Listen to Spotify podcasts by downloading the Spotify app".

Under Spotify's system, some podcasters rake in Spotify money they wouldn't otherwise get, growing the premium ecosystem, while the open ecosystem remains robust and not polluted with more DRM and URL hacks. Keeping closed systems clearly closed and separate is much better IMO than trying to awkwardly jam it into the open ecosystem, undermining what makes that ecosystem great.




What's wrong with HTTP basic auth for this use case?

https://subscriber-id:subscriber-token@podcast.host/feed.rss

In what way does this "pollute" or "pervert" the open standard? Apple and Spotify are companies, not people, this is not high school, Apple is not "bully"ing Spotify, they have a business relationship.

In general your comment is loaded with emotional language that seems to muddle the issue rather than clarifying.


I didn't consider HTTP basic auth as part of the open ecosystem because it's not, as far as I know, widely supported by clients. Is it? Maybe my assumption was wrong.

But it's also not part of the original "open" podcast vision because it is closed by definition, on an access level, and opens the door to tracking. Wouldn't most users in the open ecosystem be confused by an auth prompt? Wouldn't it be better for the open ecosystem if this sort of essentially closed feed just be cleanly inside Spotify (or whoever else's app)? This is my thinking, although I appreciate that opinions can differ.

I agree my language like "pervert" and "corrupt" can read as emotional, but I deployed it because I was trying to argue against the people who criticize Spotify using similar language, not to criticize anyone or raise emotions. If anything I'm trying to praise Spotify here.


As someone with a few Patreon feeds, yes it is widely supported, and the few that don't support it do support URL parameters so a token works fine as well.


I Patreon (verb?) two podcasts and for both it was just a custom URL, I don't recall an option to use a password though maybe I missed the option.


Patreonize? :)

I pay for a couple podcasts as well and I’m pretty sure they just sent me a custom RSS feed to drop into my player.

No way in hell am I going to fall for Spotify’s middle-manning attempts here. Hopefully they don’t manage to close off too much.


My employer offers premium podcasts as private feeds. It's a growing industry. Usually just puts a secret in the user specific URL.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: