Publisher feeds

[joksas]

Following the latest episode of Podcasting 2.0 and some of our earlier discussions, @MerryOscar and I have written up a proposal of linking different feeds of a publisher together. We are willing to implement a proof-of-concept but are also looking for initial feedback!

cc: @daveajones @adamc199 @agates

Context

It is incredibly useful to identify a publisher across all the RSS feeds that they own. This would, for example, apply to podcast hosts with many shows and artists with multiple albums/singles.

Challenges

Up until now the publisher of a podcast feed has been denoted using XML tags, such as <author>, <itunes:author>, or <podcast:person>

With these freeform tags there is no canonical way of identifying the author across all of them.

If a publisher X has feeds A, B, and C:

• a podcast player cannot recommend B and C to a listener of A
• listeners cannot subscribe to all of X's feeds at once

Proposal

In addition to having feeds that contain media (like A, B, and C — we'll call them content feeds), we propose a new type of feed: publisher feed.

Publisher feeds and content feeds would have two-way references:

1. publisher feed X has references to content feeds A, B, and C
2. content feeds A, B, and C have references to the publisher feed X

The first set of references enables listeners of X to discover all of their content feeds.

The second set of references are for proof of ownership. In theory, some other publisher Y could also point to feeds A, B, and C. When multiple publishers point to the same feeds, podcast players cannot determine the real author without additional information. The references from A, B, and C to X prove that X is the real author.

Implementation

Note: variants of the proposal have been suggested in the past, for example on Podcasting 2.0 and by Alecks Gates.

For the publisher feed, we suggest a new <podcast:medium> value of publisher. The publisher feed would contain <podcast:remoteItem>s for each of the content feeds. The medium attribute in the <podcast:remoteItem> can be used to give a heads-up on the type of content feed to expect. The following example is for a publisher who owns two music albums and a podcast:

...
<title>X</title>

<podcast:guid>05c97365-89a6-41f1-bef4-e1f9e001cbed</podcast:guid>

<podcast:medium>publisher</podcast:medium>

<podcast:remoteItem
    feedGuid="35b7abaf-f93c-480b-a1c1-4d79069a895b"
    medium="music"
/>
<podcast:remoteItem
    feedGuid="d3e9aff6-c380-4660-bc8c-5a010ea21ad1"
    medium="music"
/>

<podcast:remoteItem
    feedGuid="e67244e7-943b-4345-96c4-8422fb5206b0"
    medium="podcast"
/>
...

For content feeds (like A), we propose including <podcast:remoteItem> (with medium publisher) pointing to the publisher feed:

...
<podcast:guid>35b7abaf-f93c-480b-a1c1-4d79069a895b</podcast:guid>
<podcast:medium>music</podcast:medium>

<podcast:remoteItem
    feedGuid="05c97365-89a6-41f1-bef4-e1f9e001cbed"
    medium="publisher"
/>
...

Additional considerations

Metadata in publisher feeds

The publisher feed could contain additional metadata about the publisher by utilizing existing tags. However, for the sake of simplicity, at the current stage we suggest that, in addition to the tags <podcast:guid>, <podcast:medium>, and <podcast:remoteItem> required for the two-way references, a publisher feed only has a <title> tag, denoting the name of the publisher.

If this proposal is successful, we can consider adding more metadata to the publisher feed in the future after discussions of how podcast players should interpret it.

Multiple publishers

The proposal above assumes that a content feed has only one publisher, but there is no reason why two or more publishers could not own a feed. However, for the sake of simplicity, at the current stage we suggest that a feed has only one publisher.

Like with the previous point, if this proposal is successful, we can consider adding support for multiple publishers in the future.

[MerryOscar]

This would solve the immediate issue of being unable to search for or subscribe to music artists in Podcasting 2.0 apps.

We could easily create our own artist index within Fountain but it would be unreliable and over time lead to different datasets in different apps.

The publisher feed representing the artist would mean that:

• if you viewed an artist in any Podcasting2.0 app you would see the same album (feed), and track (item) data
• users could import / export their music library via OPML in the same way they do for podcasts
• artist boosts could be referenced properly across apps with the publisher feed guids

As @joksas said we are both happy to implement a proof of concept.

[MerryOscar]

cc @blastshielddown

[agates]

Would we also have publisher playlists -- i.e. an an RSS feed with a medium of publisherL and list of remoteItems with medium=publisher?

[joksas]

Yes, I think something like https://changelog.com podcasts could be a good example. Though when you go down this rabbit hole, there are possibly unlimited hierarchy levels, i.e, lists of lists of publishers.

[agates]

Gotcha, just making sure for when I add Podping support.

[agates]

How would a podcaster handle the case where they have podcasts across different hosts? For example, one album on wavlake and one on RSS Blue.

Should we expect hosts to allow a podcaster to be able to add external RSS feeds to their publisher feed?

[joksas]

Yes, ideally hosting companies should allow to reference external content feeds. And also put back-references inside content feeds pointing to a publisher feed (because it might be at a different provider).

[keunes]

Looks good to me as a noob. I'm just wondering: should we include an (optional) URL attribute, allowing apps/services that don't want to or can't rely on some index/resolver to get the URL for a guid to still get the data?

I remember from earlier discussions that guid is better as URLs can change, but I think that this would be a good solution for the more, say, conservative apps. Even if a URL might be outdated (either in the podcast or the publisher's feed), the guid would still act as proof of 'ownership'.

(I was wondering if I should bring this up at general, 'remoteItem' level, but I think it's more relevant specific in this context because we're linking to feeds (which have URLs) rather than individual episodes (which don't).)

EDIT: I see that the Remote Items already can have a feedUrl attribute (specs). So all good 😊

[joksas]

It's definitely possible, as you point out! Though if an app doesn't support <podcast:guid>, I don't think they'll support <podcast:remoteItem> either. The only exception might be apps without a server to make the API requests.

[keunes]

The only exception might be apps without a server to make the API requests.

Which might be the situation for AntennaPod: we don't have our own server and prefer not to rely on central servers if it can be avoided. Hence my comment.

[thomasrynne]

In the example should
<podcast:remoteItem itemGuid="e67244e7-943b-4345-96c4-8422fb5206b0" medium="podcast" />
be
<podcast:remoteItem feedGuid="e67244e7-943b-4345-96c4-8422fb5206b0" medium="podcast" />
(itemGuid->feedGuid) ?

[joksas]

You're right, thank you!

[thomasrynne]

Looks good. As I said in my original comment, I think creators are more likely to create a publisher feed if the feed is meaningful to all existing podcast players. With that in mind I think publisher feeds should include normal episode items (in practise short episodes announcing a new show/album) as well as an image and description. Otherwise a publisher feed will appear as an empty feed with no image or description, just a bare title.

[thomasrynne]

I'm not sure about using a channel level remoteItem for this and also not sure about indicating the parent/child relationship with with the medium attribute (medium='publisher' meaning parent, medium='anything but publisher' meaning child).
Given that remoteItem at the channel level means "inline an item into this feed and get the details from a remote feed" you might expect remoteItem without an itemGuid to mean "inline all items of a feed into this feed" but that's not the intention here.

With the current proposal it's quite hard to describe what a remoteItem at the channel level actually means as there would be 3 different meanings. This would require very careful reading of the spec by hosts and app developers.

[joksas]

If <podcast:remoteItem> is at the channel level, I think it is sensible that <podcast:medium> and, sometimes, the medium attribute of <podcast:remoteItem> should establish how the feed is interpreted:

• <podcast:medium>musicL</podcast:medium> would mean that <podcast:remoteItem>s represent music items in a playlist
• <podcast:medium>publisher</podcast:medium> would mean that <podcast:remoteItem>s represent content feeds that the publisher owns
• <podcast:medium>music</podcast:medium> would mean that <podcast:remoteItem medium="publisher"> represents the owner of the album
• and so on.

I'm not totally opposed to making all of this more explicit by the introduction of a new tag, but I also don't see why <podcast:medium> couldn't provide this context already.

Given that remoteItem at the channel level means "inline an item into this feed and get the details from a remote feed"

Is that really the case? I think it only applies when the <podcast:medium> is set to one of the list mediums.

[agates]

Is that really the case? I think it only applies when the podcast:medium is set to one of the list mediums.

This is correct. At least that's how it ought to be used and interpreted.

[thomasrynne]

I just read the remoteItem spec and the meaning of remoteItem under channel isn't described.
I think I only know the intension from reading previous discussions.
https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#remote-item

[joksas]

Some of the <podcast:remoteItem> uses are described in other sections because it's typically used in the context of other tags, essentially to aid them in some way.

Its use at the channel level is described in the medium section: https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md#medium

[keunes]

Just a question: since we're talking about relatively simple linking, why not rely on something like link rel="publisher"?

[agates]

Medium lets us partition feeds into different types for search purposes and to help apps know what they are before deciding to parse them from other references.

[keunes]

But isn't rel attribute taking the same function as medium here? Both would be publisher and indicate the relationship between the links (rather than the medium). I'm specifically talking about this proposal – publisher, not about other remoteItem tags.

[agates]

So the link with rel=publisher in the referenced feeds? I think the issue with that is the lack of guid support.

[keunes]

I have no (or little) clue about the RSS standard. But wouldn't it be allowed to add a guid=… field/data point (by lack of a better term) in that tag, to address that issue?

[blastshielddown]

I think this would be useful for the reasons you've laid out. Do we need two-way references though? I think it adds unnecessary complexity for a creator to manage/edit feeds in multiple places across hosts (in the example @agates mentioned where content is hosted across providers). Simple enough to allow, yes, but a bit redundant.

More importantly, I don't think two-way references buy us much in terms of proof of ownership: a spoofer could easily create imitations of both the publisher feed and content feeds that reference one another however they choose. If a client trusts either one of these feeds there's no way to tell the entirety of the feeds is fake.

[blastshielddown]

I'm not sure. I guess it would depend on whether you trust either publisher feed? This example also presumes feed A is identical in both publisher feeds, but what if they aren't? Either way, even with two-way references a client would have to choose which publisher feed to believe.

My only criticism here is that two-way references don't ensure proof of validity because both sides can be compromised. I may be misunderstanding the proposal and/or your question here, though.

[joksas]

You would trust the publisher if it was referenced in the content feed that is currently being consumed by the listener.

Spoofing has always been a problem. The only way we can trust that a feed has been created by a certain human is if they confirm it through a "trusted channel"—they could link to it on their website, on social media, etc. It's never 100% safe, but in practice it is good enough.

Publisher feeds would

1. remove the need to do this for every feed an author controls
2. enable apps to understand which feeds belong to the same author

Like before, the podcaster would demonstrate to their fans that they own the publisher feed by, for example, linking to it on their site. The authenticity of the content feeds (as they relate to the publisher feed) would be verified by the references in them linking back to the publisher feed.

We are not trying to prove that a human H is the actual creator of the content in feeds A, B, and C. We can't automate that, and either way, usually, it just naturally resolves itself. We're just trying to prove that whoever controls A also controls B and C.

[agates]

I think requiring two way references could allow for multiple publishers too, say in the case of shared creation of an album.

Possibly at the item level, too, but I'm undecided on that still.

[blastshielddown]

Yes, I totally understand the motivation and how this would be useful. We've had discussions about this as Wavlake as well.

My only feedback is that the two-way reference seems unnecessary and adds complexity without much benefit. If it's assumed that a client trusts a publisher feed (and we're starting from a place of "good enough") then any references to content feeds in the publisher feed can also be taken as genuine. The back reference doesn't buy much in terms of authenticity is my main point.

That said, it might be useful to have a back reference in the content feed if a client wants to find its way to the publisher feed from the content feed, but that's not the motivation for the two-way reference as described in the proposal.

[thomasrynne]

Without the two way links a 'publisher' feed would just be a list of feeds.
Subscribing to a list of feeds has value, but it's not the same as a publisher feed.
Anyway, as you have said, I think the link to the publisher feed is important for finding the publisher feed.

Perhaps the back-linking should be optional, but then the name medium='publisher' stops being accurate.
We could use medium='collection' (as I originally proposed) but I think I prefer the name 'publisher' because it is more concrete.

[jamescridland]

It would be helpful for a full example in the root post, not just a "here are a few important tags".

https://podnews.net/rss now links to a remoteItem publisher feed. Have I done that correctly?

That's linked at https://podnews.net/static/feeds/publisher.xml - which I've also added to the Podcast Index. Is this feed correct - containing four shows?

[joksas]

Sorry for not responding earlier.

The publisher feed looks good. However, Podnews Daily links to a publisher feed with GUID 05c97365-89a6-41f1-bef4-e1f9e001cbed (note that it's not even a UUIDv5, but a UUIDv4), while inside the publisher feed the GUID is d76ccec7-e6df-5616-9d7d-8dc1fb9d9820

Regarding a full example, we can include it though I'm still not sure what the necessary tags will be. I think apps will be better suited at defining this. For example, @MerryOscar asked for an image and a description too so that a publisher page could be generated. Here's an example with Ainsley Costello: https://publishers.rssblue.com/ainsleycostello

[jamescridland]

@joksas Thank you. I've corrected the link from Podnews's RSS feed.

Regarding a full example, we can include it though I'm still not sure what the necessary tags will be.

And that's why we need a full example! I've added an image (using the <image> tag and not the itunes one), and a description.

While I'm sure many here are happy reading a specification, most people (and I'm afraid that's me) are happy starting with a full example and editing it. That gives no ambiguity as to what is expected in these feeds.

[samsethi]

[agates]

It should just be the medium of publisher -- publisherL would be a list of publishers.

[samsethi]

Here is what the GUID returns, taken from the Podnews RSS Feed, which links to James' Publisher Feed. Knowing its a publisher feed we could add it to our dedicated Publisher page.

[samsethi]

I think what is missing James is the img tag in your publisher feed <itunes:image href="https://xxxx.jpg"/>

[samsethi]

Looking at the podnews.net/rss feed. Do we need to add in a podcast:publisher tag to nest the remoteItem like we do with the podcast:podroll

We can then look for the publisher tag, read the Remote Item GUID etc. There would be no need for the @Medium:publisher.

But in the linked publisher XML file then you have medium:PublisherL as its a list.

[agates]

The L at the end of a medium indicates that it's a list of the indicated medium.

musicL being a playlist of songs
filmL being a playlist of films
podcastL being a playlist of podcast episodes

So publisherL indicates that something is a list of publishers, or a list of lists. Probably not that useful for anything we have at the moment, but potentially useful if someone wants to create collections of publishers in the future.

[samsethi]

Thanks will make the change. So can you please put a ruling on Publisher or Producer. My example is the podcast: The News Agent is produced by Persephonica but published by Global. So what should the medium be? Novel produce shows for Wondery but Wondery also produce their own shows. Happy to use either word just want a group consensus and agreement.

[agates]

Would producer just go in a person tag? Or is the intention to want to browse shows by a producer and add extra metadata about the producer?

[samsethi]

Producer in this case is not the individual but the company that actually produced the podcast (persphonica) often on behalf of a publisher (Global). The individual person called a producer is correctly available in the person tag.

On reflection because of the ambiguity of a producer, happy to use Publisher in the medium tag and happy to use Medium=Publisher.

I still think in the main feed we need to have a Podcast:Publisher tag like we have a Podcast:Podroll tag

[joksas]

@samsethi these things are important, but they're not the purpose of the current "publisher feeds" proposal. This is just about having two-way references that provide proof of who controls the feeds. Anyone can claim that they control the feed and reference it in their feed, but this is about having those backreferences in the referenced content feeds linking back to "publishers".

In the real world, "publishers" can be, well, publishers, producers, podcast hosts, etc. Really anyone who has a say of what's in the content feed and have the power to put those backreferences. Additional metadata on the type of "publisher" might be important, but I think it's better to focus on a more minimal set of features for now.

Currently, apps may create publisher pages and list the content feeds that are being referenced. If the content feed has a backreference to the publisher feed, you can trust it. For example, you can put a "verified" badge next to the artist's album.

Conceptually, it's similar to podcast:verify. It's just that this is about verifying the common controller of a number of feeds.

[theDanielJLewis]

I'm still confused. How is this different from putting your own other podcasts in the "podroll" tag?

[jamescridland]

The Podnews Weekly Review (should) link to Buzzcast as well as the Podnews Daily in our podroll. They're shows we recommend you listen to - they don't need to be ours.

The Podnews Weekly Review (should) link to Podnews, Podcast Business Journal Spotlight, et, in our publisher list. They're shows we publish.

[theDanielJLewis]

Why repeat stuff? Why not simply add an attribute to Podroll to indicate that the other podcasts you put in your Podroll are yours. Isn't that one of the reasons it's called "Podroll" and not "recommendations," "featured," or any of the other names that predated it?

[MerryOscar]

Why repeat stuff? Why not simply add an attribute to Podroll to indicate that the other podcasts you put in your Podroll are yours. Isn't that one of the reasons it's called "Podroll" and not "recommendations," "featured," or any of the other names that predated it?

the point of this proposal is primarily to allow listeners to subscribe to updates from artists - if the artist has a publisher feed then any new music released by that artist can automatically be surfaced to the listener

[theDanielJLewis]

@MerryOscar, oh, so it's a music-focused feature not really intended for the majority of podcasters? (That's not an accusatory question, just clarification.)

[MerryOscar]

this is the primary use case that we need it for right now - but it could be used for many other things going forward

[mikeneumann]

FWIW, a relatively simple example:

Simple Publisher Feed and visible on the Index.

[daveajones]

So, all said, I think all that is needed here is a “publisher” medium added to the spec, correct? We can also add “publisherL” for future proofing.

[thomasrynne]

I am pleased this is being adopted but I would prefer something closer to my original proposal.

I'm not at all attached to the names (belongsTo & child) but I don't like the idea of overloading remoteItem with both meanings.

The remoteItem tag is already confusing, adding two more meanings makes it worse.

If publisher feeds are only documented in the medium section how can someone reading a feed that uses remoteItem work out how to interpret the remoteItem tag. They might need to read the whole spec to find out. If we do use channel level remoteItems the 3 channel level uses of remoteItem should be documented in the remoteItem section of the spec.

Perhaps listing the child feeds using remoteItem is OK, but the reference to the publisher feed could be wrapped in a publisher tag?
<publisher> <podcast:remoteItem feedGuid="05c97365-89a6-41f1-bef4-e1f9e001cbed" medium="publisher" /> </publisher>

To help explain why I think this matters, imagine you want to display a feed.
You would naturally show the list of items of the feed, looping through the item tags (and now channel level remoteItem tags).
With this proposal you would need to know to remove remoteItems when the medium is publisher, because channel level remoteItems where the medium='publisher' are not 'items' of the feed, they give information about the feed.

Also, I do think there should be a suggestion that publisher feeds include some normal items so that they can be used by all podcast apps. Look at the blank page for this example feed from above

Just some feedback. I'm still happy about the adoption either way.

[samsethi]

100% agree with you. We need to wrap the publisher remoteItem inside of a podcast:publisher tag like we do the podroll.

[thomasrynne]

Sorry, I realise now my suggestion of a publisher tag came from Sam's comment above. Please interpret my comment as me 100% agreeing with Sam :)

[samsethi]

When will this tag be confirmed. Who will determine if we add podcast: publisher as a place holder or not. I would like to see the podcast: publisher top level and have all the remote items listed below like we do for Podrolls.

[daveajones]

Catching up and working on it now.

[Marzal]

Hi, what about also allowing in the normal feed to point to the publisher feed with the txt tag?

It could allow a faster adoption, given that some hosting already support that. You would only need to create the publisher feed and add a txt tag in your feed with a reason like publisher (or whatever word reach consensus) and the feedGuid in the node value. Same data, but in an already implemented tag.

Any advantage in using (or only allowing) the verification with a podcast:remoteItem ?

[nathangathright]

Even though the txt tag was written broadly to handle various use cases, that doesn’t mean the existing implementations are flexible enough to support features like this. AFAIK, Transistor.fm only supports a single txt tag per feed, which always has purpose="verify", and the text field in the UI is labeled “Verification code”. Not at all suitable for supporting non-verification use cases.

But more importantly, we can presume that any host willing to generate the publisher feeds for their customers is willing to implement <podcast:remoteItem medium="publisher"/>

[Marzal]

I had in mind the use case of podcasts/feeds hosted in companies supporting the TXT field (with more liberty) that probably would not implement the "publisher feed" or that would move reaaally slowly. So you can create your publisher feed in other place sooner or self-host it.

But I see your point, that probably would be the 0.X % of the X % that wants a publisher feed. And may be is not a bad incentive to make people improve hostings

[nathangathright]

One fringe benefit of publisher feeds I just realized is simplifying claiming multiple feeds on third-party services. If hosts support feed verification (txt or verifyOwnership) within publisher feeds, then services could authorize that user to claim all the shows in that publisher feed present and future.

I’m working on a new service that involves claiming multiple feeds and am interested in supporting this. If any hosts would like to discuss this further, please get in touch with me.

[thomasrynne]

Referencing the show, what would 'push back of any magnitude look like'? Did my comment not have enough magnitude? 😄
I really think the reference to the publisher feed should be wrapped in a publisher tag because the publisher remote item is not a normal item in the feed, it is metadata.

[daveajones]

I'm doing a prelimary write-up and will submit that for comments. Plenty more room for adjustments. Will discuss in the board room also.

[daveajones]

@thomasrynne The more I sit with this the more I think you’re right. It’s not a strictly necessary thing. But I think it would make more sense to structure it that way.

[daveajones]

Here is an initial draft of the publisher feeds mechanic: https://github.com/Podcastindex-org/podcast-namespace/blob/main/publishers/publishers.md .

Comments welcome.

[daveajones]

How does this strike you @agates ? It's simply a describer so I see no harm in it. We'll all know it can't really be trusted as canonical.

[agates]

How does this strike you @agates ? It's simply a describer so I see no harm in it. We'll all know it can't really be trusted as canonical.

It wouldn't hurt, although I don't think we should require it in hindsight.

[daveajones]

@nathangathright Can you propose this formally in the enhancement section. Just so I have something to link to in the Phase 7 to-do?

[nathangathright]

#629

[blastshielddown]

This looks good to me, @daveajones

We should have an implementation of this for artist feeds sometime this month.

[samsethi]

Thanks @daveajones

Below is a feed example we are currently producing as an export from our publisher pages. We will add the missing person tag(s) and feedurl's in our feed. We have added a generator field as I think it will be useful to know who created each feed.

I also like @nathangathright suggestion about adding a title attribute. I know these were primarily made for music artists but we have produced publisher feeds for podcast production companies. Below is the publisher feed for Global.

[samsethi]

@dave thanks for the show tonight. If you export a Publisher feed from TrueFans we already enclose the RemoteItems inside the podcast:publisher tag - here is a link to the Wondery page to grab a copy of the TrueFans RSS file. - https://truefans.fm/publishers/wondery

[thomasrynne]

I believe this is the wrong way round. I thought Dave's html header & body analogy was helpful. In RSS the body is made up of the top level bare 'item's (or 'remoteItem's) and the header is everything that is wrapped in a tag.

With that interpretation in mind the above feed would have an empty body with many remote items described as publishers of the feed in the header.

I think the body of a publisher feed is the feeds that belong to the publisher so there is no need to wrap these remote items. However, when a feed references its publisher this is information about the feed, so this remoteItem should be wrapped in a publisher tag.

[agates]

@thomasrynne is correct -- there's no need for it in the publisher feed itself (it's the same concept as a playlist without item GUIDs).

[samsethi]

Happy to tale it out of our actual publisher feed but it is needed in the original RSS feed.

[MerryOscar]

Was there a discussion on whether the feedUrl attribute in remoteItem publisher feed should be either required or strongly recommended?

I think this will help make things easier as it will avoid an additional lookup request to the podcast index api to fetch the publisher feed url.

cc @daveajones @joksas @samsethi

[daveajones]

You mean in the remoteItem tag?

[MerryOscar]

@daveajones yep! (updated comment to be more clear)

[daveajones]

The feedUrl in the remoteItem tag is already set to recommended. I think it makes sense to reiterate that in the publisher feed documentation. 👍

[MerryOscar]

ok great 👍

[samsethi]

Here is a Publisher feed from Wavlake. And I think @joksas (RSSBlue) are adding them too.

<channel>
	<title><![CDATA[Sam Means]]></title>
	<description><![CDATA[Oh, hi!]]></description>
	<link>http://github.com/dylang/node-rss</link>
	<generator>Wavlake</generator>
	<lastBuildDate>Tue, 30 Apr 2024 14:39:26 GMT</lastBuildDate>
	<podcast:medium>publisher</podcast:medium>
	<podcast:guid>c25f1156-a1df-47a8-9746-54956849442b</podcast:guid>
	<podcast:remoteItem medium="music" feedGuid="891c9ffe-1e78-4b07-a75e-7283629fb127" feedUrl="https://wavlake.com/feed/music/891c9ffe-1e78-4b07-a75e-7283629fb127"/>
	<podcast:remoteItem medium="music" feedGuid="ec8ce316-9461-48e1-8fd2-17d46f5ebe3d" feedUrl="https://wavlake.com/feed/music/ec8ce316-9461-48e1-8fd2-17d46f5ebe3d"/>
	<podcast:remoteItem medium="music" feedGuid="79412552-0b97-429e-89a3-70384dff110a" feedUrl="https://wavlake.com/feed/music/79412552-0b97-429e-89a3-70384dff110a"/>
	<podcast:remoteItem medium="music" feedGuid="d4a960d5-7a92-4407-befd-da70e5011c82" feedUrl="https://wavlake.com/feed/music/d4a960d5-7a92-4407-befd-da70e5011c82"/>
	<podcast:remoteItem medium="music" feedGuid="872dd0a3-e878-488a-b0b1-1ab2a422143b" feedUrl="https://wavlake.com/feed/music/872dd0a3-e878-488a-b0b1-1ab2a422143b"/>
	<podcast:remoteItem medium="music" feedGuid="1743d0b1-0529-4e9f-9af1-b8aff82642ff" feedUrl="https://wavlake.com/feed/music/1743d0b1-0529-4e9f-9af1-b8aff82642ff"/>
	<podcast:remoteItem medium="music" feedGuid="10612580-e40a-4cec-b26b-db7d9088630b" feedUrl="https://wavlake.com/feed/music/10612580-e40a-4cec-b26b-db7d9088630b"/>
	<podcast:remoteItem medium="music" feedGuid="215a64e0-b840-463e-96dd-9c6b9da8ab62" feedUrl="https://wavlake.com/feed/music/215a64e0-b840-463e-96dd-9c6b9da8ab62"/>
	<podcast:remoteItem medium="music" feedGuid="8e674970-d6cb-4f8e-84b7-5072e78688ec" feedUrl="https://wavlake.com/feed/music/8e674970-d6cb-4f8e-84b7-5072e78688ec"/>
	<podcast:remoteItem medium="music" feedGuid="63641906-1a58-4b2c-bbe3-3ab071aaf87a" feedUrl="https://wavlake.com/feed/music/63641906-1a58-4b2c-bbe3-3ab071aaf87a"/>
	<podcast:remoteItem medium="music" feedGuid="b309a123-8b69-4738-b923-ac62946e024b" feedUrl="https://wavlake.com/feed/music/b309a123-8b69-4738-b923-ac62946e024b"/>
	<podcast:remoteItem medium="music" feedGuid="39699072-a7a2-4e74-a69f-7d7360c2bb8e" feedUrl="https://wavlake.com/feed/music/39699072-a7a2-4e74-a69f-7d7360c2bb8e"/>
	<itunes:summary>Oh, hi!</itunes:summary>
	<itunes:owner>
		<itunes:name></itunes:name>
		<itunes:email></itunes:email>
	</itunes:owner>
	<itunes:explicit>false</itunes:explicit>
	<itunes:image href="https://d12wklypp119aj.cloudfront.net/image/c25f1156-a1df-47a8-9746-54956849442b.jpg"/>
</channel>

[MerryOscar]

@samsethi do you have the url for this feed?

[jamescridland]

@samsethi Presumably this is wrapped in an <rss> tag?

What are the itunes:owner tags doing here? The owner tag seems pointless, since it's empty; what's the "summary" for, and why is there a declaration of "explicit = false" when there is no content in this feed, just links to others?

Why are we using an itunes:image and not the standard RSS <image> tag?

I've updated https://podnews.net/static/feeds/publisher.xml which is linked from the Podnews Daily, but without the itunes stuff (which I don't believe lives here) and it reads as below.

Really important that documentation is clear. Also really important that there is documentation.

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:podcast="https://podcastindex.org/namespace/1.0" xmlns:atom="http://www.w3.org/2005/Atom" >
<channel>
<link>https://podnews.net</link>
<lastBuildDate>Tue, 30 Apr 2024 14:39:26 GMT</lastBuildDate>
<link rel="self" href="https://podnews.net/static/feeds/publisher.xml" xmlns="http://www.w3.org/2005/Atom" />	
<title>Podnews Network</title>
<image><url>https://podnews.net/static/podnews-2000x2000.png</url><title>Podnews</title><link>https://podnews.net</link></image>
<description>Podnews produces a number of shows and feeds for podcasters, as accompaniments for the daily Podnews newsletter. You can subscribe to that at https://podnews.net </description>
<podcast:guid>d76ccec7-e6df-5616-9d7d-8dc1fb9d9820</podcast:guid>
<podcast:medium>publisher</podcast:medium>
<podcast:remoteItem feedGuid="9b024349-ccf0-5f69-a609-6b82873eab3c" medium="podcast" />
<podcast:remoteItem feedGuid="396d9ae0-da7e-5557-b894-b606231fa3ea" medium="podcast" />
<podcast:remoteItem feedGuid="d04f3195-25e8-52d9-b87f-969251009f1e" medium="podcast" />
<podcast:remoteItem feedGuid="dc87f50b-8c0d-5980-8f2d-067dde67c7e4" medium="podcast" />
</channel>
</rss>

[samsethi]

@samsethi do you have the url for this feed? - here is the feed from Wavlake. The mistake in the feed is podcast:medium = publisher. That should be podcast:medium = music and then in the feed they can set the remote item as a publisher feed.

https://wavlake.com/feed/artist/c25f1156-a1df-47a8-9746-54956849442b

[blastshielddown]

From the spec proposal:

It is incredibly useful to identify a publisher across all the RSS feeds that they own. This would, for example, apply to podcast hosts with many shows and artists with multiple albums/singles.

Since this is an artist feed, it seems fitting to label it as a publisher in the medium tag as this is a way to identify the creator of multiple content feeds (in this case, albums).

[MerryOscar]

looks great! 🙌

[samsethi]

I have a problem that probably needs the collective to fix. Can we add an image attribute to the publisher feed remote item.

I have created publisher feeds for both podcasts and music. We add the title attribute as standard in our export.

However in our aggeregated Artist Page we do not have an Artist image. In our aggregated Publisher Page we added the image/logo manually. If we detect a Publisher tag in the RSS feed we automatically add the Publisher feed but have to go back to add the image/logo.

Can we add an image attribute to the publisher feed?

Publisher Page with images

Artist Page with no images

[nathangathright]

An <itunes:image> is likely already available if you fetch the feed's contents. Presuming we add an image attribute on the remoteItem tag, I’d still recommend fetching the <itunes:image> as a fallback. Can I ask why you’re not currently using that image?