Proposal: <podcast:contact> - More control over contact information

[stpp2]

Basically today most feeds include an email address for contact/verification purposes.

This is not always great because -

1. Some hosts override it with their own email addresses (i.e. Anchor)
2. It exposes personal information that you might not want to share publicly (let alone being scraped by dozens of apps)

The proposed tag could include something like a contact URL, physical mailing address (yeah it's 2021, but still), phone number, or email as well.

Guess it could look like this: <podcast:contact type="url" href="https://contact-page.org/">Optional Text?</podcast:contact> <podcast:contact type="phone">1234567890</podcast:contact> <podcast:contact type="contact" method="email">email@address.com</podcast:contact> <podcast:contact type="address">Address, City ZIP12345, State, Country, Planet</podcast:contact>

This was briefly discussed in #10, where @daveajones also proposed the following tags - <podcast:contact type="feedback" method="link">[link to a forum or chat room]</podcast:contact> <podcast:contact type="advertising" method="email">[email address]</podcast:contact> <podcast:contact type="abuse" method="email">[email address for DMCA takedowns, etc.]</podcast:contact>

[jamescridland]

What problem is this trying to solve, please?

If it's "but Anchor puts crap in these tags" then the answer is that Anchor stops putting crap in these tags.

If it's "people scrape this information" then the answer isn't adding even more information, surely?

[vv01f]

besides @jamescridland objection … a good example for me was the first <podcast:contact type="url" href="https://contact-page.org/">Optional Text?</podcast:contact> … there you can have a semantic collection of more contact data (although even the podcast:person url might suffice fot that). More data in the feed directly is overkill in my eyes and I never got why email would be a good choice as the sole entry.

[stpp2]

@jamescridland Honestly I just think contact information can be an important tag in podcast feeds. The reference to Anchor was merely to point that the existing email tag doesn't fit all cases.

The proposal also includes other methods beyond email. If you want people to be able to contact you without sharing your email address(es), then a link (or several links) to a contact URL or a form is quite efficiently fighting the scraping mentioned. If you accept voice messages or calls over the phone, then a phone number is useful. If you accept physical mail for feedback, reports etc., then a mailing address could help.

I suppose, businesses or organizations could use tags like address/phone, or add multiple emails/links to reach separate persons involved.

The bottom line is that it gives the podcasters more control on what contact info they share (if they opt to do so) and how they do it.

@vv01f I agree, you can include a semantic collection of additional data via an external URL. With that said, if you only want to include one property (like a single URL or address), it might be an overkill.

[picard102]

It's so easy to create email accounts for free, so I'm not sure I see why an exposed email is even a problem that needs to be addressed.

[picard102]

Any movement on this proposal? Now that Apple is depreciating their tag, it would be nice to have a standardized way to include contact information in the feed.

[jamescridland]

@picard102 The way forward is to use a verification code instead, to prove that you are the owner of the podcast. That could be useful for, say, podcast awards who want to prove that the submission has come from the owner of the podcast.

Verification codes are supported already by Transistor, a Canadian podcast company; and will hopefully be supported by Buzzsprout and Podbean. It appears that Apple Podcasts are also supporting verification codes when you transfer ownership of a podcast, judging by the Transistor writeup.

For use-cases: all podcasts come with a url to a website as a mandatory field, where contact information in any form can be placed. Email addresses can be placed in episode notes as a form of feedback if required. The verification code, aka podcast:txt, allows programmatic checking of ownership of a podcast where you want to be sure who owns it.

Programmatic contact details in podcast feeds have historically been abused; there seems - as far as I can see - no reason to enable that.

[picard102]

Verification is a separate issue imo, and as you've pointed out already well served by other tags. In my use cases I'm looking to get / provide contact information for the podcast, which this proposal would seem to address.

Specifically for our awards use case, the nominations process is open and anyone can nominate any podcast for an award. Often those podcasts are not in our database and we need to contact the podcast owner to get specific information from them to be eligible. With hundreds of nominations contact information in the feed allows us to do this without scraping the information from another source.

If the issue is abuse, then the solution seems to addressing the abusers, rather than prevent users from including this content.

[jamescridland]

Specifically for our awards use case, the nominations process is open and anyone can nominate any podcast for an award. Often those podcasts are not in our database and we need to contact the podcast owner to get specific information from them to be eligible. With hundreds of nominations contact information in the feed allows us to do this without scraping the information from another source.

Thanks for the clarification.

If the issue is abuse, then the solution seems to addressing the abusers, rather than prevent users from including this content.

There doesn't seem to be any prevention here: a podcaster can include their email address in the episode notes. The <managingEditor> and <webMaster> RSS tags are there to add contact details if podcasters wish. And they can continue listing their details in the <itunes:owner> tag, which is soon to be deprecated but that doesn't mean it can't be there. But they don't need to any more.

Your use-case is, unfortunately, the same as the spammers: "we've found your RSS feed and we've got something you might find interesting". Yours is a great, positive use of those contact details. But, there's no way to only release email addresses to the nice people, but not to the nasty ones.

[daveajones]

This is also a perfect use case for a robust <podcast:person> tag to be included at the channel level for the host and/or others. It doesn’t provide an email address, but does give a more clear indication of who the person in charge is, which can ease the finding process.

[picard102]

There doesn't seem to be any prevention here

Maybe prevention isn't the best word, but the result of not having a formal alternative is that companies will not provide their users the ability to provide this information in an alternative tag. We've had two companies recently pull the contact information from their feeds by default. One allows the users the option to add it again, the other does not and who suggests scraping the website (also what spamers do).

[stpp2]

FWIW, I'm still standing behind my initial suggestion here - this can help specifying different contact options directly in the feed. It can be fully optional and you won't necessarily have to expose an email address or sensitive information.

[jamescridland]

We've had two companies recently pull the contact information from their feeds by default.

Buzzsprout, Transistor and Podbean all pull the contact information from their feeds by default (14.6% of the market), while Anchor fills it with crap that doesn't work by default (a further 21.9%), so that's more than a third of all active podcasts out there which don't have contact data in them. More will follow. ("Ask your favourite podcaster to claim their podcast!" might work. Arguably, unsolicited email to an RSS feed isn't following Canadian privacy law anyway.)

@stpp2 I wonder if "please mark up your contact details on your website with schema" is the right thing here? Just wondering if it's a thing that has to be in the RSS feed?

[picard102]

Arguably, unsolicited email to an RSS feed isn't following Canadian privacy law anyway.

We're in full compliance with CASL.

I wonder if "please mark up your contact details on your website with schema" is the right thing here? Just wondering if it's a thing that has to be in the RSS feed?

Not sure how this solves the proposed problem of spam? Scraping websites for emails isn't much different than an RSS feed. Unless the argument is that it's optional, which is what this tag would be as well.

[daveajones]

I think there has to be a measure of reality acceptance here. The reality is that Apple is driving this change and email addresses in podcast feeds are, from here on out, not going to be reliable in any way, no matter what tags we come up with. I still like the contact tag idea and think it has utility, but it’s not going to solve the issue of wanting to be able to just scrape feeds for the email address in order to contact the owner.

For the awards scenario, it seems like requiring a valid contact email on the submission form is the only way to make it work programmatically and reduce the manual collection efforts (which seems to be the core issue). Outside of that (which adds friction) I can’t see any way to do it going forward.

[daveajones]

I plan to bring this up on the next board meeting so we can get the entire issue in front of more people. There may be great ideas out there that would help.

[staceygoers]

@daveajones did you talk about this in the board meeting and can you share a summary? :)

[theDanielJLewis]

I still like this idea, especially since it supports a contact method other than a raw email address—like a phone number or contact page.