Podcasting Feeds

[dshanske]

@manton commented that one of his goals for JSONFeed now that 1.1 is out was to revisit how to iterate on podcast feeds using JSONFeed. https://jsonfeed.org/podcasting

Opened this issue to document prior art(specifically Media RSS and iTunes vendor extensions) and to brainstorm what information may be needed.

[dshanske]

Media RSS Specification: https://www.rssboard.org/media-rss

• Media Grouping(https://www.rssboard.org/media-rss#media-group) - Probably unnecessary as the assumption is that in a podcast feed that all attachments to an item are representations of same.
• Media Content(https://www.rssboard.org/media-rss#media-content) - Default might be a useful option to identify the default medium for the podcast. as might height, width, and language(which is already a property of an item). Summary/description also might be allowed at the attachment level as used in Media RSS. Image/banner_image would also allow for thumbnails/posters for video and audio elements.
• Media Credit(https://www.rssboard.org/media-rss#media-credit) - There is an issue as to whether the author should be considered, in an audio/video medium, to be the 'creator'.Being as this is podcasting though, we would need to cover hosts/guests possibly as optional fields.
• Media Copyright(https://www.rssboard.org/media-rss#media-copyright) and License(https://www.rssboard.org/media-rss#media-license) - There is no field, top level or otherwise for identifying copyright and licensing.
• Media Scenes( https://www.rssboard.org/media-rss#media-scenes) - There is this growing concept of identifying chapter and other information in media...

[dshanske]

iTunes XML Namespace - https://help.apple.com/itc/podcasts_connect/#/itcb54353390

• Author - appears in both the feed and item levels and is a name. At the feed level it is the name of the author of the podcast. At the item level it is the name of the author of the episode.
• Tags/Category - is allowed in JSONFeed at the item level but not the feed level. At the feed level, it could represent, like iTunes category, the categories/tags of the entire feed.
• Summary - is also allowed in JSONFeed at the item level but not the feed level.
• Type - Episodic or Serial -
• Season/Episode - Season or Episode number
• Episode Type - Full, Trailer, or Bonus If a trailer and no season or episode number, this represents a show trailer, otherwise, a season or episode trailer/teaser. If a bonus, and no season or episode number: a show bonus, but if it has either a season or season and episode number, a bonus representing the season or the individual episode.

[bcomnes]

I implemented an _itunes extension for JSONFeed that lets you generate a compatible Apple Podcast RSS feed from said JSONFeed:

https://github.com/bcomnes/jsonfeed-to-rss

Been in production on https://gumcast.com since last year.

Next up, looking to support JSONFeed 1.1 and Google Play podcast extensions.

[dshanske]

@bcomnes Isn't it better to explore official additions?

[bcomnes]

That reply was neither in support or against adding additional official fields. Open to that, or an official/standardized format extension that serves a similar purpose.

Just reviewed the _cast which also looks like a nice, non-vendor specific set of additional fields all podcast should support, not already found in JSONFeed.

[manton]

Thanks y'all! @bcomnes, what do you think about using the vendor-neutral field name _podcast instead of _itunes as suggested here? It feels like this is a good time to move away from the "iTunes" name even if it's inspired by Apple's RSS extensions.

[bcomnes]

I think that or the existing _cast extension is a great idea for a vendor neutral podcast extension containing common podcast fields not found in vanilla jf, and would ideally contain enough data to map or expand into a vendor specific extension (mostly), or simply be leveraged during a conversion process when converting to vendor tailored rss.

As of now these vendor specific extensions really only serve as an api for conversion, although they do map 1:1 to the xml extension they convert to.

There are a number of very specific vendor fields that probably should remain just in their own namespace. I think the worst outcome would be one giant union of vendor options in a single extension.

Maybe a rule of thumb for fields in this converged podcast extension is: new fields not found from vanilla jf and utilized in at least two vendor extensions or in a native jf podcast app subscription.

I'm currently looking into doing a google play podcast extension next.

If _cast is already supported in more niche podcatcher apps for subscriptions (I think... hooray!), and provides enough data to cover the requirements of these vendor specific extensions, then I would be willing to converge onto that.