Proposal: <podcast:block> #179
Comments
|
Is that like a robots.txt for the RSS feed? Why would someone want to limit the reach of a podcast? Okay, for Spotify or other paid services I could understand it. |
|
I don't know. I personally don't care which platform index my own podcasts. However as a hosting provider, with podCloud, we had many podcasters asking us to be able to block some platform to be more in control. We had this discussion in our original rss namespace project, when Majelan, a French equivalent of Luminary, indexed many podcasts without asking or warning them. Majelan, was a podcast player that had a free directory of independant podcasts indexed crawled from iTunes and selled exclusive content on the same app. (They now sell personal development content and closed the original app because podcast was not profitable enough) Many French independant podcasters were pretty angry, it even made the news. It's pretty common request from our users to get more control on where they "broadcast" their content. (Although, in my own opinion, that should not matter and you should be glad to have your content available everywhere. Except if an app is stealing your content as free stuff for acquiring user to sell them stuff, but if they do that, I doubt they'll enforce a tag in the rss feed) The purpose is also to replace itunes:block, googleplay:block etc with a generic one. |
|
This is something I proposed here a while ago, so it's nice to see it back. I can see the benefit of this for people like Majelan or Luminary. But it's for them - well, for Luminary these days, given Majelan exited the podcast space - to work out how they might wish to implement this. I think we can help them with the spec: but more important to understand whether this would be enough for them, or even something they'd like to do. We'll get nowhere if we just invent something for these folks without their input. Particularly, we need to understand who sets the "id" values. Is that up to the implementing directory owners? I suspect it might be. But my suggestion would be reverse notation for domains - "com.spotify" or "com.google.podcasts" - might be the plan here. |
|
I was thinking we could use the same ID as in I perfectly agree we can't release a tag like this and hope they'll follow without working with them. With majelan when French public radio asked them to be removed from their app, majelan refused to do it. (Thus refusing control over their own copyrighted content) (Now most public radio content is not available anymore in RSS, and only on private apps, partly because of this.) |
|
Are we sure this tag would have a legal value? If not, what consequence would it have in a courtroom? I suggest we focus on the podcast:license tag and define clearly what is legally (and thus technically) allowed to do. The main issue with Majelan was that they were (allegedly) making money out of others podcasts. This has yet to be defined, I suggest we use sub-tags for podcast:license. |
I think you may be right about this Ben. I do like the idea of the block tag. But, after being subject to so many "please take my podcast off your service" emails, I question whether people would actually use it properly. Idk. It's a hard issue. I'd rather just say "properly license your content and then go after who violates that."
Can you explain what your idea is with this? |
|
I answered in #177 : |
|
Revisiting this. Do we want to work on finishing this tag? I’m not sure how respected it would be. But I’m willing to do it if enough of us feel it’s a worthy addition. |
|
Well, I guess it will be more respected if it exists than if it doesn´t 😁 I'm sure some apps and directories, built by people here, will respect it. It helps to understand which feed is private and should not be publicly indexed. I doubt "the big four" (iTunes, Google, Spotify, Deezer (maybe mostly big in France)) will respect it right away, but it doesn't hurt to have it in the standard. And Spotify and Deezer might follow the lead if many use it. iTunes and Google will probably go their own way as always |
|
I agree with @PofMagicfingers. |
|
@PofMagicfingers Are you good with the structure as it stands? Any tweaks that you think need to be made? If not I’ll write it up into the main Readme for phase 4. |
|
It seems good to me ! |
|
Ok will write it up this weekend. |
|
Hey @daveajones, I listened to Podcast 2.0 #38 and now I must say agree 100% with you and Adam. |
Could you summarize their opinion or tell us the timecode of when they discuss about it? The episode is about 2 hours long. |
|
Just a second, je te trouve ça… |
|
From: |
|
Until: |
|
Here are my thoughts on it : I didn't realized block tag has been revived because of podcastclips (never heard of it), I though we were discussing it again to prevent directories and apps to index the "wrong" feed when using guid #251 and for podcast channels #240. Although, I understand the concern about letting companies decide where the podcasts would be listenable, this is obviously not the point of this tag. I hope users of platforms doing such thing will move their podcast elsewhere if they loose control over their hosting provider. Let me summarize, what we had in mind when we imagined this tag at podCloud :
About the tag being respected or not, as you said in the podcast, it's like the robots.txt, there might be issues about which settings are defaults in some companies*, and there might be issues about companies not respecting it. *I think we should advise in the spec that the reasonable default is no block tag for a public feed, for maximum compatibility IMHO, we cannot foresee everything, and only hope it will be respected and used for the original intent. As you said, if it is misused, as indexers, we would still be able to not enforce it for hosters that abuse this system. Like robots.txt, expire or user agents headers, etc, it's a convention, and it only works if everybody respects it. No solution is perfect, if tomorrow, Anchor or Libsyn decide to block every request not using iTMS or Spotify user agent, you will probably spoof this user agent and call them out on it. IMHO, the main purpose about this tag should not be to "block" bad platforms or indexers, as it will be obviously not respected by them. I think the main purpose is to declare inside the feed if it's a private or public feed. Or a platform specific feed ( blocking every app except spotify for a spotify only feed, as it seems to be a thing now ) |
|
I am no expert, but here are my two cents: |
|
I do agree with you, but I don't see why theses 2 tags would exclude each other. A license tag tell us how we could use the content. A block tag is a way to prevent indexing of a private feed, or a custom purpose feed in directories. Podcastclips has nothing to do with the block tag, but maybe should respect a license tag if present. Tldr : Block tag is keeping control on indexing, not on content usage. License tag is about content usage. Let's not mix up licensing, indexing and copyright. |
|
Yes of course. |
That's also my opinion. 😉 Also I sure hope the main purpose of this tag will be blocking indexing on catalogs when it's not relevant (private feeds, old feeds, etc), and not because you like the catalog or not. |
|
The real pain point here is the ability to block everything and then specify only which ones you allow. That’s where the abuse (or naive config) would most likely occur. Removing that hurts the tag quite a bit from its current elegance though. I want to move forward with this tag though. Let’s brainstorm a bit more to see if we can work around that single issue without making it unusable. I’ll give it some thought. |
|
To be clear, if we improve that aspect I think it’s fine. I don’t want to ditch the tag. But that part really does warrant some thought. It will happen. |
|
I may be changing my mind on the podcast:block tag. It’s not just for the podcaster, it’s for the app developer. I tried subscribing to ‘Pod Save America’ using CurioCaster, and it works, but the enclosureURLs for each episode is blocked. I tried on PodFriend, same thing, then Google Podcast, same thing. If I go to the address direct from the browser, a redirect occurs to a different url. Looks like the podcast host is doing something behind the scenes to make sure other players can’t play the content. The block tag would improve my UX by allowing me as a developer to remove that feed from search results so the user isn’t able to subscribe to a podcast that my player won’t be able to play. It seems like the podcast host is already able to block players they don't want playing their content. It seems pretty trivial to look at the referrer in the request header, and block anyone you want. Unless I want to hide that info by doing a server side proxy(which I don’t), then the podcast host can easily block anything referred from curiocaster.com. The block tag will just allow me as an app developer to know they don’t want my participation, and block their feed from being displayed |
This isn't what @thebells1111 ...
This is because Megaphone is blocked by most ad-blocking software (and has been added to the default for eero over the last few days, I understand). https://podnews.net/podcast/imvy says that Pod Save America goes through at least two redirects - Podtrac and Chartable - before hitting Megaphone's DAI server. This isn't the podcast host doing the blocking - rather differently, it's the podcast host being blocked. |
This has been confirmed. Everything is blocked when using Brave, but on Edge or Chrome, it works as expected. |
|
Hello, all - would like to reheat this proposal. Currently, the intention when podcasters use Respecting all creators, even those unable to use the podcast namespace, I would like to propose that the tag is as written, with two treatments of existing tags as standard: The podcast:block tag
Backwards compatibilityWhere a podcaster is not using the podcast namespace, we should treat the following as synonyms as follows: itunes:block If a podcaster wishes to remove their podcast from Apple Podcasts only, they should use If Update Feb 16: I've removed the googleplay namespace here, since Google have themselves removed it. |
|
I support this. Right now it’s impossible to block apple but not google using the iTunes:block tag. I know that slug lists are annoying. But I don’t see any better solution here. A list is really necessary to achieve granularity. |
|
Google will respect the "iTunes" block. So there's really no way to block only Apple Podcasts while allowing Google, under the current "iTunes" namespace. But instead of a separate yes/no tag for each desired platform, I suggest a more concise way to do this.
|
|
I like the whitelist only approach. It simplifies things. I would say that as soon as the block tag is present at all it should be interpreted as “block everything”. Then the exceptions list is who to allow. My big question here though is how to do this without some kind of slug list. Nobody likes having to reference and maintain a list over time. Can we just use a domain name minus the tld? So, to allow google.com it’s just “google” and to allow apple.com it’s just “apple”, etc. The robots.txt spec uses the bot user-agent identifier. But in the podcast world that’s very messy. Apple alone has 3 different user agents their aggregators use. |
We just need to make sure we consider the impact this would have one new podcasting apps. I would hate to accidentally squash any innovation!
I definitely think something related to domain names is a better solution than slugs. One thing I keep thinking is are we using XML correctly? We all hate it, but its what we have! A tag with no content and complicated attributes may be more appropriate like this? I dunno? |
|
Hi everyone, Here are my thoughts on all of this. I'm thinking all of this with the specs written by @jamescridland here, and of course my initial intention when we proposed this tag, you can read above here.
<podcast:block id="apple,google">yes</podcast:block>
<podcast:block id="spotify,overcast">no</podcast:block>
<!-- Only Spotify is **whitelisted** -->
<podcast:block>yes</podcast:block>
<podcast:block id="spotify">no</podcast:block>
<!-- Only Spotify and Apple are **blacklisted** -->
<podcast:block>no</podcast:block>
<podcast:block id="spotify,apple">yes</podcast:block>@daveajones At first we can use the already existing slug list of podcast:id : serviceslugs.txt. If a platform doesn't support it, it doesn't matter to have a slug for them, as they will not enforce the rule. @tomrossi7 |
<!-- Only Spotify is **whitelisted** -->
<podcast:block>yes</podcast:block>
<podcast:block id="spotify">no</podcast:block>That seems like extremely confusing syntax, like a double negative and some redundancy. I think there should be only one instance of the block tag on the channel level (items can have their own block tag). As for maintaining a list, I think we might have to leave it to the developers. Blocking Spotify is going to be pointless unless Spotify ever respects it. It's not quite like the lock tag. So maybe developers would pull-request on a repo list to claim a "slug" (whether that's their app name or a sometimes seemingly irrelevant domain name) and indicate their support for the tag. Otherwise, this seems like an almost pointless tag with not even the value of indicating an unregistered trademark with ™. (By calling it "pointless," I'm not saying it's actually pointless or we shouldn't pursue it, only that if we don't get the podcast-app developers involved, there will be no point to this tag.) |
|
(I've amended my suggestion to remove the I agree with Daniel, to a point: yes, it's useless if podcast directory devs don't implement it; but inclusion in the RSS means that it's an expressed intention from a podcaster, which they are asking directories to honour. As such, I think it's a little less pointless than it at first seems. As one example: I'm currently in the receipt of a three-page legal letter from a lawyer, threatening me with all kinds of legal action, because a podcaster wants to be only listed in Apple Podcasts and not in any other directory. That's a stupid thing to want to do, but we should also respect the wishes of creators, even stupid wishes, in my opinion. At present, there's no way of indicating that a podcast should only be in Apple Podcasts. As to the complicated syntax above - I like Tom's idea of... Question for @tomrossi7 - a) what does the Does it help if there is a reserved directory slug of Finally, I'd recommend not using domains for all this - there are some strange old domains going round, and you actually want to talk about directories/services and not the domains they may hang off. Indeed, some podcast apps don't even have a website. |
|
Moving this into phase 5 |
This is my feeling on it as well. Expressing the intent of the feed owner is a very legitimate thing to do. |
|
At it's core, for backwards compatibility, this tag syntax must perfectly match That means we're only left with modifying purpose via attributes. The syntax might not be perfectly human readable, but that's ok since XML is a markup language, not WYSIWYG. Thinking this over... |
|
This feels good to me: <!-- This means "block everything" -->
<podcast:block>yes</podcast:block>
<!-- This means "block nothing" -->
<podcast:block>no</podcast:block>
<!-- This means "block everything except spotify and google" -->
<podcast:block exclude="spotify,google">yes</podcast:block>
<!-- This means "block nothing other than spotify and google" -->
<podcast:block exclude="spotify,google">no</podcast:block>In it's basic form it operates just like the itunes block tag. When the This also has the benefit of being easy to parse from a UI down to XML. |
|
Not really a fan of those inversion changing the way you read it depending on the content. I'm not sure why/how this would be more useful syntax than the previous one we discussed, but I could be wrong. I don't see the need to be identical to itunes:block as we are creating a new tag. Retrocompatibility has no point here, as people will use the old itunes:block for retrocompatibility |
I'll do my best to verbalize the need. I should do that instead of just saying it, shouldn't I 😊. The "need" for backwards compatibility is a hybrid of technical and "political" factors. Eventually (3 years, 5 years, 10 years, ??), the podcast namespace aims to be a drop-in replacement for the itunes namespace. The itunes namespace is poorly documented, slow to adapt to change and owned by a single enormous company. It needs to be supplanted - not just added to. To that end, we need to be conscious of making sure that any tags which mimic the behavior of an itunes tag need to be unaffected by a namespace prefix swap. For instance, we currently have For every namespace discussion there are three developer parties involved: hosting companies, listening apps and third party platforms. Each one of those has a different adoption threshold they will cross with different criteria. One criteria they all share though, is ease of implementation. Tags that take zero or little coding effort to adopt will always be preferred over complexity. When a developer group sees that simply changing their feed production/consumption code from "itunes:" to "podcast:" involves zero breakage, that's a huge deal. With tags that create new behavior (like If all of that is true and legitimate, then the exclusion list mechanic is the only way I know of that this tag could work as intended (as a granular, platform level blocking mechanism) and satisfy those other "needs" above. |
|
@PofMagicfingers What if instead of having an allow/disallow mechanic, we just do disallow. So, we remove all the notion of “no” as an option. This leaves it as just “yes” blocks everything, and if “exclude” is present then allows those. Do you think that would work for you? I’d like to move on this tag but I don’t want to if you still have concerns about it. I agree that the inversion was probably too complicated. |
|
Well, that could work... But IMHO it's a bit harder to understand/read, and it fails to be a drop-in replacement of If you need exceptions, you can specify them with a new tag, using the platform attribute: I'm not seeing anything confusing or such : "podcast block Spotify? no" I find it harder to read it with exclude list and thus inversion etc, IMHO. |
Ok, so what you are saying is there can be multiple tags and platforms just look for themselves as a “no” override if there is a full “yes” block at the top. Is that a fair way to say it? |
|
Yes. Platforms looks for themselves or a generic tag. If no tags with my platform id Kind of like a robot.txt, the robot check if it matches one of the rules user agent. If not it follows the |
|
I thought of something else we should consider. Does a block tag merely prevent that podcast from being found through a podcast app, or will it actually block the app completely, even from manually adding the feed? For example, if I'm crazy and add the block tag for Overcast, should that prevent people from manually adding my RSS feed to their own Overcast app? I advise that it be a "directory" block only, not a full app block. Like a bots command for website asks that the website not be indexed, but still lets people access the website, I think the "block" tag should block the podcast only from being listed in the target directory, not preventing fans from using that app to consume the podcast. With this in mind, I wonder if we might want to consider renaming the tag to "hide." |
|
You're right it's indeed only a directory block. It would work just like itunes:block is used right now. Only blocking iTunes store presence, not usage inside Apple Podcast or iTunes through the rss feed link. It's using the term block to keep the same name as itunes:block |
|
@PofMagicfingers Does this look good now? Block Tag |
|
Yes! It looks clean and easy to understand |
|
I'd like to suggest that podcast:block should be supported at both channel and item levels, similar to itunes:block, and with similar semantics (telling a service to not list the blocked episode, either globally or by service slug). |
|
In the serviceslugs.txt are podcast hosts and apps or services included. In
theory you could also block another host, right?
E.g. you host on buzzsprout and block acast (in case of they offern an
directory or allow listening / playing podcasts from other hosts).
…On Thu, Aug 4, 2022 at 5:38 AM Dave Jones ***@***.***> wrote:
@PofMagicfingers <https://github.com/PofMagicfingers> Does this look good
now? Block Tag
<https://github.com/Podcastindex-org/podcast-namespace#podcastblock---discuss>
—
Reply to this email directly, view it on GitHub
<#179 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADE66AT4MFZF2IEKXTJGRVDVXM3MNANCNFSM4W65MKLA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I agree with this. But we should expect it will completely block the episode from even being consumed on those platforms. That's how Apple Podcasts works since iOS 14.5 because they now use their own feed proxy.
This is what the lock tag is for since migrating a feed is an "opt-in" act and not something that gets discovered or automatically imported like podcast apps would do. |
<podcast:block [id="[platform_id]"]>[yes|no]</podcast:block>
This tag allow to specify at
channelif a platform is allowed to index this podcast.This aim to clear the mess we're in with multiple clients using multiple tags : right now, if you use
googleplay:blockyou block Google, but if you useitunes:blockyou block Apple but also block Google as well.Platform id is the same as
podcast:idtag.If you do not specify the platform, it should be considered as default value, for platform not specified.
ie: this podcast is only allowed on Spotify
If there is no default tag, it is inferred as not blocked.
Here everyone is allowed :
Here only Google Podcasts is blocked :
We can discuss if this should be available at
itemlevel. If I recall correctly,itunes:blockis available at item level.This could also serve the same purpose as
<podcast:private>proposed on #167This is a transfered proposal from our former project podCloud/podcast-ext. See #173 for details.
The text was updated successfully, but these errors were encountered: