Hosting platform provider identification <podcast:host> / <podcast:generator> / <generator>

[Dwev]

Currently, there is no tag to positively identify who a hosting platform is, and in many cases this can be derived from the enclosure URL domains or similar - although this can also lead to errors.

When analytics companies are looking at the top hosts by number of feeds, or number of new episodes, it is important not to miss those that have custom domains, or are using CDNs like Akamai or Amazon S3.

I'd like to propose that we add to the spec a strong recommendation for hosts to include the native RSS "generator" tag with an identifier, similar to Castopod:
<generator>Castopod - https://castopod.org/</generator>
<generator>Buzzsprout</generator>
(This might be a problem for Wordpress based sites, as WP will populate the generator feed.)

or alternatively add a new tag to the podcast namespace like:
<podcast:host name="Castopod" url="https://castopod.org/" vers="1.10.5" />
<podcast:host name="PowerPress" url="https://blubrry.com/services/powerpress-plugin/" />
<podcast:host name="Sovereign Feeds" />
(where url and vers are optional)

This will then be able to positively identify which podcast hosting platform is being used, regardless of CDNs or custom domains, in any analytics that supports the tag (in turn making it a lot easier for the analytics companies to break down these type of stats.)

Thoughts?

@benjaminbellamy @johnspurlock @daveajones @tomrossi7 @joksas @yassinedoghri

[joksas]

Looks good to me!

It doesn't make much difference, but is there a reason the version attribute is named vers and not version?

[Dwev]

is there a reason the version attribute is named vers and not version?

Nope, just me shorthanding. Those three characters will save a lot of bandwidth! ;)

[samsethi]

Hi Guy

I fully support this as a new tag for Phase 8. We wanted to build a host table for analytics. We added a field to read the generator. However some hosts use this field correctly and others put in spurious data. So like you, we then tried to read the URL to determine the host name which worked most of the time but not all the time.

So we added a field to our creator's admin dashboard. If our guess, based on the URL was wrong, they could manually change it. We also added 'self' as an option. But a specific podcast:host field might be better. I am sure all hosts would automatically pre-populate this field.

[Dwev]

Hi Sam!
I really appreciate that you allow a podcaster to correct their information on the TF platform, especially when that information is programmatically derived. I wish more platforms would allow this!

Can I ask why this should wait until Phase 8? If it is universally supported, can't we still get it into Phase 7?

[johnspurlock]

A separate podcast-specific tag sounds good to me. It's in the interest of the hosting company to put good values in here (similar to podcast:block) and can be quickly implemented for all shows on a given host.

And doesn't rely on podcaster input, so has a better chance of containing non-garbage data.

[tomrossi7]

Can't you tell the host by the RSS feed host address?

[johnspurlock]

sometimes, but not always

many hosts offer custom domain support for small and large existing brands

and there are services like feedburner/podcastmirror etc

[picard102]

Yeah I know for one client we have self hosted feeds, but the files are hosted with your typical hosting service.

[tomrossi7]

many hosts offer custom domain support for small and large existing brands
and there are services like feedburner/podcastmirror etc

Ah, true.

[Dwev]

Is there any difference in how the tag should be executed?

Should it be a self-closing tag like:
<podcast:host name="Castopod" url="https://castopod.org/" version="1.10.5" />

or an enclosing tag like:
<podcast:host url="https://castopod.org/" version="1.10.5">Castopod</podcast:host>

I don't know what determines which format is best for what scenario...

Attributes are optional, but the thing inside the tags is mandatory and the main point?

[samsethi]

I like the idea of enclosing the tag. We expose the name of the host in the podcasts info popup. BTW we also expose the name of the Publisher and Present that in the info box.

We link the host to our host table to show what P2.0 tags they support. We link the publisher link to the new Publisher Feed pages.

[Dwev]

Also - I'm thinking about the name "host". I am assuming that what we are really interested in here is the web application platform used to generate and serve a podcast RSS feed. Some platforms may also host media files and the feed itself, but other platforms may be self-hosted with the media hosted on a CDN, and the feed served from some other place for some reason. In that case, do we care about the actual host (e.g. AWS, GC, Azure, a server in a closet somewhere), or the software platform used to bring a podcast RSS together?

For that reason, maybe podcast:platform is better than "host"?

Maybe another term altogether is better?

[dhk2]

If a podcaster selects "Self" in the drop-down box on Truefans, we lose the data that they are actually using Castopod on their closet server.

Castopod should be in the generator tag in that case.

And it is:
<generator>Castopod - https://castopod.org/</generator>

[Dwev]

As mentioned above, the generator tag isn't always reliable. The podcaster could be using PowerPress or some other Wordpress plugin in their own server. They select "self", and the generator tag is (rightly) "Wordpress".

That's the purpose of this proposal - to positively identify the platform that has been developed for serving the podcast RSS feed.

[yassinedoghri]

I agree that the name "host" may not be accurate. Moreover, it is connotated when it comes to podcasting (I would think of the podcast host person when reading it and not the service that generated the RSS).

As @johnspurlock mentioned above, a podcast-specific tag in replacement (or rather in addition to) the <generator> tag would be great.

If <podcast:block> exists for the same reasons, ie. to add functionality to the already existing <itunes:block>, then why not <podcast:generator>?

<podcast:generator name="Castopod" url="https://castopod.org/" version="1.10.5" />
<podcast:generator name="PowerPress" url="https://blubrry.com/services/powerpress-plugin/" />
<podcast:generator name="Sovereign Feeds" />

Anyways, great proposal @Dwev 🙂

[Dwev]

Yes, generator is even more accurate, especially as a podcast namespace tag.

[theDanielJLewis]

If this is still being considered, definitely avoid the words "host" or "platform" for this context. I call companies like Captivate and Libsyn "podcast-hosting providers." Or for short, "hosting" (not the "ing"). Other possibilities could be "distributer," "cdn," or "provider."

[jamescridland]

Isn't the <generator> tag not the right thing for this? Shouldn't it copy the standard of how useragents are set?

<generator>Castopod/1.10.5 +https://castopod.org/</generator>
<generator>PowerPress +https://blubrry.com/services/powerpress-plugin/</generator>
<generator>Soverign Feeds</generator>

That's the standard for any useragent, and I'm finding it hard to understand why we can't just use the standard <generator> tag here. Sorry for asking the dumb question.

Here's a WordPress function that sets the generator name, if it helps?

function set_generator(){
  return 'Castopod/1.10.5 +https://castopod.org/';
}
add_filter('the_generator', 'set_generator');

Sorry if this has all been hashed out already.

[yassinedoghri]

@Dwev, just thought to check Podlove Publisher, which is an open source Wordpress plugin.

👉 Overwriting WordPress's <generator> tag is possible as they've done it:

https://github.com/podlove/podlove-publisher/blob/c7200b446e778d5dd7cbcab34f7032a717760dc5/lib/feeds/base.php#L182-L194

[picard102]

Are we looking for the name of the application generating the feeds, or generating the media files, with this tag?

[Dwev]

@picard102 The feeds. The media could be hosted with a CDN which might be completely different.

@yassinedoghri that's cool - so we know it can be done. I also believe there are advantages to a namespace tag as mentioned above. Open text fields can be very hard to enforce, as @jamescridland pointed out in a discussion on the location tag. Being able to define attributes such as URL and version number would be advantageous as this can be parsed in a standard way.

[jamescridland]

@Dwev The best-practice standard for a useragent is:

[Name of the app] / [version number] +https://[link]

This would appear to be relatively trivial to parse.

Benefits of a new tag - we're starting from a clean slate, so every entry should be correct.

Benefits of just clarifying how a <generator> tag should look - it's an existing standard that can be enhanced.

The location tag is a good example of where there's a lot more information that can be learnt from a unique ID in a schema elsewhere. This isn't it.

[yassinedoghri]

@jamescridland Looking at the RFC 9110 defining the user-agent format in the http headers, the url should be in between parenthesis as it would be a comment:

[product]/[product version] (+url)

It can even be multiple products next to each other, and I'm therefore wondering if it is possible for a feed to have been generated by multiple apps/services 🤔

@Dwev 👉 I guess this could make sense for wordpress for example:
Podlove/4.1.6 (+https://podlove.org) WordPress/6.5.2 (+https://wordpress.org)

Also, note that the + sign appears to be a common practice but is not mandatory when it comes to prefixing urls. (source https://webmasters.stackexchange.com/a/51891)
That being said, I don't know why the choice of it, maybe for faster parsing? In other words: would looking for a + sign instead of http or https to extract the url be faster?

[Dwev]

So it looks like there is a majority agreement that the generator tag is the right place for this.

For that to work, there needs to be agreement on the format inside the tag, with the suggestion of using a user agent style string getting agreement.

There are a few people (including me) that can see added value in a specific podcast namespace tag, but we can table that for now.

Since the generator tag is not in the podcast namespace, I'd suggest this is a better recommendation to come from the PSP which covers all namespaces used for a podcast feed. @samsethi could this go into 1.1 do you think?

[samsethi]

I am happy to go with the consensus but a generator may still be different to the host. Also podcast:host is another step in removing older tags and one day having a pure Podcasting 2.0 namespace of tags in the future.

In TrueFans we have written our own code to detect the host automatically and where we can't we allow the podcaster / creator to self-select. With my PSP hat on I will ask all the hosts if they would make the necessary changes to this field.

[samsethi]

This is the reason the generator field v host does not work. Podnews RSS feed is close to the gold standard of how an RSS feed should work. Here we see a generator field with "Podnews LLC" which is correct, Podnews was the generator but 'self' is the host. As an app how am I supposed to know Podnews is self hosted? Its easy with Podnews as everyone knows that but what about another site that is self hosted and unknown to many people. Are we to assume anything not on the known list of podcast hosts is self-hosted.

[jamescridland]

That's because we have no standard - nobody has said what the field should contain. And this is up to us to do. We don't need to develop a new tag: we can just use the existing one.

It should read: Podnews LLC +https://podnews.net or Podnews LLC (https://podnews.net) - depending on your read of the useragent standard - in this case, for I am the host and also the generator of the RSS feed, and I don't have a versioning system.

But the wider question is... an RSS feed isn't necessarily the host of the audio. I could host with Blubrry, but produce my RSS feed using PowerPress. What would you want it to say there?

[Dwev]

The media host can more easily be derived from the enclosure URLs, and I don't think it's as important to explicitly say where the media is. This could be S3, or Cloudflare, or any number of things. I don't think parsers of the RSS need to have the media host be explicit in the metadata. Then we add alternativeEnclosure tags, and suddenly, we have multiple media hosts.

I believe generator may be enough, unless there is a compelling reason to know the media host that cannot be derived from the URL.

[samsethi]

But the wider question is... an RSS feed isn't necessarily the host of the audio. I could host with Blubrry, but produce my RSS feed using PowerPress. What would you want it to say there?

That is the real question. Generator would be Powerpress but the Host would be Blubrry. I think that is why a new host tag was proposed to overcome this issue. Unless you extend the generator field to include a host attribute?

[theDanielJLewis]

While this is interesting for industry analytics, it would not be actually useful because not enough hosting providers would implement it to be of statistical value.

Besides that, there's almost no value in this for the most important people: the audiences—let alone any value for podcasters, developers, or advertisers. Really, I think this is valuable only for analysts and journalists. And for that reason, I think we shouldn't invest any time into developing this because it doesn't actually offer much benefit to anyone but a few people.

[Dwev]

Well, there are statistical analysis platforms out there that compile this data and use it to publish "top podcast hosting" lists and other such things. Unfortunately,

Currently, there is no tag to positively identify who a hosting platform is, and in many cases this can be derived from the enclosure URL domains or similar - although this can also lead to errors.

When analytics companies are looking at the top hosts by number of feeds or number of new episodes, it is important not to miss those that have custom domains, or are using CDNs like Akamai or Amazon S3.

So, there is definitely value for hosting / feed generation app companies to be accurately identified and not slip through the cracks because they offer self-hosting or third-party media hosting options. The healthier the entire eco-system is, the better it is for podcasters. Audiences, creators, developers, and hosts, are all essential ingredients here.

[samsethi]

Hi

I think RSS data is a mess right now. Sadly many hosts fail to validate the data in fields before they publish the RSS. We have missing GUIDs. missing episode titles etc. Sadly we have to re:validate every feed, every time it is published to ensure there are no errors.

The more we can get accurate validated data in the RSS fields the better it is for apps.We have added a host label in the App UI to show the host but we do it solely from the URL. We had hoped the generator field/tag would have been used for this but that is a real mix of hosts and other info so we can't rely on that.

We use the host field to create this host table. https://truefans.fm/hosts and we show that tags each host supports as well as the number of podcasts. We would love to make this table more dynamic to show weekly/monthly changes.

We also have plans to use this data to help creators decide if they want to switch from one host to another based on the podcasting 2.0 features they do or don;t support. The same as Feedburner or PodMirror.