You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding podcast:locked tag and working with independent podcasters, podcasters who are not using a managed platform. In our case, podcasters who host their own podcast on their own website using WordPress with PowerPress. In these cases there is no way to provide a email verification system as one would be verifying themselves.
Currently the wording states "The purpose is to tell other podcast platforms whether they are allowed to import this feed. A value of yes means that any attempt to import this feed into a new platform should be rejected." This is fine for an independently managed (not tied to a service) podcast. If yes is set, we will not allow the podcaster to import.
The last part "When importing a feed, if the hosting provider has already verified the owner="" email address on their own system, and the email matches what is listed in this tag, it is safe to import the feed.", this assumes that the podcaster is on a platform with a mechanism to verify the email address. In the situation where they are self hosted, they would be verifying themselves. Further, in the 'owner' parameter it states "The owner attribute is an email address that can be used to verify ownership of this feed during move and import operations.". I assume since the "can be" is in this line, for the situation we are handling, we can ignore the owner email field and simply use the tag value of "no" to indicate that the feed can be imported.
In other words: <podcast:locked>yes</podcast:locked> PowerPress will not allow the podcaster to import the feed. If <podcast:locked>no</podcast:locked> or not set, PowerPress will allow the podcaster to import the feed.
Some clarity and confirmation our approach is acceptable is appreciated.
The text was updated successfully, but these errors were encountered:
In other words: podcast:lockedyes</podcast:locked> PowerPress will not allow the podcaster to import the feed. If podcast:lockedno</podcast:locked> or not set, PowerPress will allow the podcaster to import the feed.
That seems like a fine approach! @daveajones do you see any issues with it?
Regarding podcast:locked tag and working with independent podcasters, podcasters who are not using a managed platform. In our case, podcasters who host their own podcast on their own website using WordPress with PowerPress. In these cases there is no way to provide a email verification system as one would be verifying themselves.
Currently the wording states "The purpose is to tell other podcast platforms whether they are allowed to import this feed. A value of yes means that any attempt to import this feed into a new platform should be rejected." This is fine for an independently managed (not tied to a service) podcast. If yes is set, we will not allow the podcaster to import.
The last part "When importing a feed, if the hosting provider has already verified the owner="" email address on their own system, and the email matches what is listed in this tag, it is safe to import the feed.", this assumes that the podcaster is on a platform with a mechanism to verify the email address. In the situation where they are self hosted, they would be verifying themselves. Further, in the 'owner' parameter it states "The owner attribute is an email address that can be used to verify ownership of this feed during move and import operations.". I assume since the "can be" is in this line, for the situation we are handling, we can ignore the owner email field and simply use the tag value of "no" to indicate that the feed can be imported.
In other words:
<podcast:locked>yes</podcast:locked>
PowerPress will not allow the podcaster to import the feed. If<podcast:locked>no</podcast:locked>
or not set, PowerPress will allow the podcaster to import the feed.Some clarity and confirmation our approach is acceptable is appreciated.
The text was updated successfully, but these errors were encountered: