Proposal - <podcast:txt> tag for freeform content #543
Replies: 51 comments
-
|
Also #342 |
Beta Was this translation helpful? Give feedback.
-
|
In #356 there was a really good suggestion that the "service" attribute might be used so you could differentiate when you have multiple tags who should be looking for the text. |
Beta Was this translation helpful? Give feedback.
-
|
A text tag in order to verify ownership … isn't that what the verify tag is supposed to be for? |
Beta Was this translation helpful? Give feedback.
-
|
A tag specific to verify is good for verification but an open text tag can be used for verification and anything else you want to use it for in the future. Just like DNS. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the world never envisioned use cases like SPF records. But having a generic TXT record allowed those things to come to pass. Very valuable imo. |
Beta Was this translation helpful? Give feedback.
-
10-4. Makes sense. |
Beta Was this translation helpful? Give feedback.
-
|
Added |
Beta Was this translation helpful? Give feedback.
-
|
I dig this variation. I'm for it! 🙌 Let's ship this so we can start using it! |
Beta Was this translation helpful? Give feedback.
-
|
Brilliant. As soon as I saw the initial description I was immediately reminded of TXT in DNS, which you obviously then referenced...and that has proved immensely valuable due to its flexibility. I know feature-creep is always something to be wary of when proposing additions, but I think this one will actually mitigate quite a bit of that because of its fundamentally flexible nature. |
Beta Was this translation helpful? Give feedback.
-
|
Since we're dealing with a podcast feed here and not domains, I suggest we consider a name other than "text." Maybe "metadata" or "attribute" or something like that. The reason I think "text" might not be good is that it could conflict and cause confusion with other text fields we'll want in the future for actual text. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @theDanielJLewis |
Beta Was this translation helpful? Give feedback.
-
|
What about |
Beta Was this translation helpful? Give feedback.
-
|
I like “meta.” |
Beta Was this translation helpful? Give feedback.
-
|
We have a winner then! 😊 |
Beta Was this translation helpful? Give feedback.
-
|
If no more comments are made on this tag before November 1st, I'd like to recommend this for formalization into the namespace. This tag is simplistic, has lots of prior art and has been discussed off-line for quite a while now. I don't think there are any lingering surprises here. There is also a timing issue to go ahead and get this on the books before end of year (2022) since early 2023 is when email addresses will most certainly start disappearing from feeds. |
Beta Was this translation helpful? Give feedback.
-
|
Buzzsprout already removed emails from their feeds today, so I am going to fast track this. It's written up now. Some eyeballs on this would be good, to make sure there are no typos or mistakes, and to make sure it reads well: https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#txt |
Beta Was this translation helpful? Give feedback.
-
|
Looks solid. Thanks so much for hearing me out on this one at PM Dallas - and now it’s already formalized. Cheers. |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to foresee more possible uses of this tag. Should we maybe adopt something either more specific than Should we give guidance on how long the |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to change naming at this point. What's there works fine. For expiration time, are you speaking specifically about the "verify" purpose? Otherwise, it would be impossible to make a blanket recommendation on that given the open nature of the tag. For domain verification using DNS TXT, I think most people never remove them. I see that debris hang around a lot. |
Beta Was this translation helpful? Give feedback.
-
|
This looks great and the name is super. For domain verification using DNS TXT - not only do most people not remove them, but removing them can stop the domain being verified. This allows, for example, someone to sell a domain to someone else, and not remain verified in things like Google Analytics, etc. But that's probably up to the consumer of the TXT field, and does not need to be part of the specification as far as I can see. |
Beta Was this translation helpful? Give feedback.
-
|
PS: @mijustin if your screenshot above is your planned UX - worthwhile considering that |
Beta Was this translation helpful? Give feedback.
-
|
DNS verification is often reconfirmed and thus the need to maintain the DNS information indefinitely. But something like a podcast-verification code is short-term. Maybe we can encourage developers to offer a timeout option when a podcaster populates the field, with a default of something like 48 hours before removal. Otherwise, we'll end up with RSS feeds having 20 TXT tags and none of them needed anymore. |
Beta Was this translation helpful? Give feedback.
-
|
100% on this:
Let's get this shipped, and worry about future iterations later. Again, hosting providers are already having to use other fields (Copyright, Keywords) for these, so the sooner we can have a dedicated field, the better.
Even this might not be a big deal. Verification doesn't happen super often. If they need to verify something again, they can replace this value in the field. In these cases, our customer support is usually guiding the podcaster anyway, so there will likely be some hand-holding no matter what. @daveajones we'll be adding this to Transistor feeds shortly! |
Beta Was this translation helpful? Give feedback.
-
🎉🚀 |
Beta Was this translation helpful? Give feedback.
-
|
This is how its done! |
Beta Was this translation helpful? Give feedback.
-
|
It'd be great to have some examples of why this might be used in an item instead of only in channel. |
Beta Was this translation helpful? Give feedback.
-
|
I see this tag is a pressure release valve for standardization. It could be useful as a place to put item-specific verification data as we do for alternateEnclosure's integrity field; across the value block for example. i.e. a hash may be calculated across certain areas of an item, and a service may exist to verify that hash using keys and signatures that may not exist in the feed. |
Beta Was this translation helpful? Give feedback.
-
|
This is now live on Transistor! 🙌 https://transistor.fm/changelog/verification-code/
@tedhosmann you should adjust the wording on your support emails from:
to
|
Beta Was this translation helpful? Give feedback.
-
|
I believe this is now in the namespace, and I'm therefore closing this thread. |
Beta Was this translation helpful? Give feedback.
-
After discussions with @tedhosmann about owner verification within feeds, the need for a tag that can hold free form content was brought up. The initial use case for this tag would be so hosting platforms can provide a way for their feed owners to input a random string into the feed that other platforms will then use to confirm they are the feed owner. The concept is based on the TXT record in DNS. To make it truly flexible, it can exist in the channel or in items and there can be more than one.
Txt
<podcast:txt>Holds free form text up to 4000 characters in length. Any valid XML character can be used here.
Parent
<channel>or<item>Count
Multiple
Node value
This is a free form string from the podcast creator. Please do not exceed
4000 charactersfor the node value or it may be truncated by aggregators.Attributes
128 characters.Examples
Beta Was this translation helpful? Give feedback.
All reactions