Proposal: New element <podcast:podroll> #451
Replies: 18 comments 22 replies
-
|
I really like this. Very good. Simple and straightforward. |
Beta Was this translation helpful? Give feedback.
-
|
Check out #205, by @benjaminbellamy. |
Beta Was this translation helpful? Give feedback.
-
|
@theDanielJLewis #205 is struggling with complexity, much like #240 and #442. There is power and beauty here in the simplicity. That seems to be getting lost recently. The elements getting the most adoption share these attributes. We have to fight against complexity, not look for ways to introduce it. |
Beta Was this translation helpful? Give feedback.
-
|
I was simply pointing to the prior discussions of the same idea. And I recommend a |
Beta Was this translation helpful? Give feedback.
-
|
I agree that Plus, "roll" needs to be explained to someone who understands English ("the podroll tag is for other shows you recommend") whereas "recommend" is self-explanatory (or, at the very least, one level closer to being self-explanatory). |
Beta Was this translation helpful? Give feedback.
-
|
I like the simplicity here too. I disagree that blogroll never took off @theDanielJLewis - I knew of blogrolls long before I ever blogged or hosted a podcast. |
Beta Was this translation helpful? Give feedback.
-
|
However it's implemented, I still think we should use the far more widely understand terms "recommendation" or "featured" or something like those. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, using plain words rather than jargon would be better. |
Beta Was this translation helpful? Give feedback.
-
|
I would vote that it be OPML, which might be super easy for a podcast app to instantly import. But if recommended on the episode level, then I also like the cleanliness of putting it with the chapters inside the episode metadata file (often incorrectly called the "chapters file"). |
Beta Was this translation helpful? Give feedback.
-
|
I support this tag. Accordingly, Podnews now supports the We also now make the podcast GUID visible in our podcast pages (under "Information for podcasters"). Having implemented it, I'd like to propose multiple elements of this tag in the Here's Podnews's current podroll element: I'd like to suggest... ...which would show Podnews's other shows available under "Channel"; then Buzzcast and Podcasting 2.0 available under "Recommendations". |
Beta Was this translation helpful? Give feedback.
-
|
(I'm not wedded to the syntax here, by the way - please suggest something better!) |
Beta Was this translation helpful? Give feedback.
-
|
We just dropped this into the Buzzcast feed. <podcast:podroll>396d9ae0-da7e-5557-b894-b606231fa3ea,917393e3-1b1e-5cef-ace4-edaa54e1f810,7d1a25c1-c5d2-540b-95eb-ba83ec2521de,e4b357cd-e380-5b7a-bab7-02ca01f3b12c,b3a4c44f-73cf-5d38-82b8-e4475190fd97</podcast:podroll>Are there any player apps interested in exploring support? |
Beta Was this translation helpful? Give feedback.
-
|
Podfans now supports the Podroll. If we find it in the users RSS feed as described above with GUID's we add it to the podcast show page. We have also added Podroll Recommendations and Podroll Episodes. As this is NOT OPML. Do we need a simple share format/icon to allow people to import/export podrolls/playlists? |
Beta Was this translation helpful? Give feedback.
-
|
Podnews podcast pages now support the podroll. Try this page for Buzzcast as one example - look for the section marked "Other shows you may enjoy". (Caveat: Due to database limitations, this may be incomplete). You can also search for GUIDs in Podnews's search. |
Beta Was this translation helpful? Give feedback.
-
|
I love this idea. My only suggestion is in addition the guids, there's a link to the actual RSS feed in the tag. Right now, with the guid, the Podcast Index or another directory is necessary to find out which RSS feed is tied to which guid. If the link to the RSS feed was in the tag, then an app could pull the feed direct without needing to query a centralized database. |
Beta Was this translation helpful? Give feedback.
-
|
I understand that there is a GUId lookup via the Podcast Index API. https://podcastindex-org.github.io/docs-api/#get-/podcasts/byguid As an app developer, we could do the GUID lookup in the app via the API. However I agree without the actual RSS feed, this may be the first time I cannot directly read the RSS feed and understand the fields. |
Beta Was this translation helpful? Give feedback.
-
|
The simplicity of just using the GUID is very attractive to me. I also see it as a Trojan horse for adoption of the GUID. Most services will have a database of shows, and a GUID ought to be captured and stored in that database. Ideally, services should be using the GUID rather than any proprietary identifier; but even if that's not the case, the GUID comes with any Podcast Index response and ought to be captured and stored. There is a GUID lookup in the API, and Dave is working on a simple DNS-based resolver that could make life even quicker. Drawbacks with using an RSS feed include a growing list of outdated links, as podcasts move between hosts - around 1% move every month. The GUID is a permanent ID for a podcast, and this is the ideal place to use it, in my opinion. |
Beta Was this translation helpful? Give feedback.
-
|
GUID lookups require an HTTP request every time just to get the feed. But using feed URLs should work fine and are usually redirected. I have more faith in the performance of redirects than having to do lookups all the time. |
Beta Was this translation helpful? Give feedback.
-
|
They don't require an HTTP request if they're already in your shows database. An RSS feed can differ though - Podnews has many different ones to help track. This seems an optimal use of the GUID to me. |
Beta Was this translation helpful? Give feedback.
-
At that point it's not really different than the <rss xmlns:podcast="https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md" version="2.0">
<channel>
<title>Podcasting 2.0</title>
<description>The Podcast Index presents Podcasting 2.0 - Upgrading Podcasting</description>
<link>http://podcastindex.org</link>
<docs>http://blogs.law.harvard.edu/tech/rss</docs>
<language>en</language>
<generator>Sovereign Feeds</generator>
<pubDate>Fri, 21 Apr 2023 19:52:40 +0000</pubDate>
<lastBuildDate>Fri, 21 Apr 2023 19:52:40 +0000</lastBuildDate>
<podcast:locked owner="adam@curry.com">yes</podcast:locked>
<podcast:funding url="https://paypal.me/podcastindex">Value 4 Value</podcast:funding>
<managingEditor>adam@curry.com (Adam Curry)</managingEditor>
<webMaster>adam@curry.com (Adam Curry)</webMaster>
<itunes:owner>
<itunes:email>adam@curry.com</itunes:email>
<itunes:name>Adam Curry</itunes:name>
</itunes:owner>
<item>
...
</item>
<item>
...
</item>
<podcast:remoteItem feedGuid="a94f5cc9-8c58-55fc-91fe-a324087a655b" itemGuid="https://podcastindex.org/podcast/4148683#1" />
<podcast:remoteItem feedGuid="a94f5cc9-8c58-55fc-91fe-a324087a655b" itemGuid="https://podcastindex.org/podcast/4148683#3" />
<podcast:remoteItem feedGuid="a5ad6f3f-a279-504c-bc6a-30054e6b50e1" itemGuid="tag:soundcloud,2010:tracks/319791095" />
<podcast:remoteItem feedGuid="a5ad6f3f-a279-504c-bc6a-30054e6b50e1" itemGuid="tag:soundcloud,2010:tracks/319789777" />
</channel>
</rss> |
Beta Was this translation helpful? Give feedback.
-
|
I like |
Beta Was this translation helpful? Give feedback.
-
|
@daveajones what was all that "do one thing really well" talk? Sorry, I'm not a fan of this mod. |
Beta Was this translation helpful? Give feedback.
-
|
The "one thing" thing got complicated when people started proposing |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
In case my tone is not coming through, I'm being a little silly here. More seriously, I do not agree that remote item and blogroll are similar at all. Blogroll is just a list of podcasts that I like. If you're a fan of my show, you may want to check them out. That's it. Nothing more complicated about it. I would prefer, as a podcaster, that listening apps display the podcasts I recommend before using whatever recommendation voodoo they cook up on their own. Remote item, as I understand it, would let me drop someone else's content into my feed. I don't see myself ever doing this and wouldn't be super thrilled if someone did it to one of my episodes without my permission. I get that it would still pull from my host and all that, but I'm not comfortable with possible bad associations (I don't want my episodes being part of random playlist). I think if remote item gets approved it would need a companion element giving explicit permission ( |
Beta Was this translation helpful? Give feedback.
-
|
As I've said in the remoteItem tag, I'm not really very keen on that either. I'd like to give some form of editorial reason why I'm linking to individual episodes. But, I guess I can see some benefit to separately linking to an episode that I want to recommend; which is different from just throwing one episode into a feed. |
Beta Was this translation helpful? Give feedback.
-
|
Taking Dave's comments into account... I'd like to propose the following: podcast:relatedThe Its purpose is to link to related podcasts and/or episodes. It is intended to allow creators to link to other shows they make, feature in, or recommend. It may take the place of algorithmic recommendations. In the UX of a player, it would display at the bottom of the podcast's page, where recommendations usually live, like this: This is not a remoteItem into a list of shows. This should always be separate in the UX of any podcast app. formatOn a basic level: The above uses a feedGuid (the "podcast GUID") to link to another podcast. RSS feeds are not used here because RSS feeds are not guaranteed to be permanent; the GUID is, however, a permanent value associated with a podcast. This can be looked-up by a client from the Podcast Index API, or stored in a podcast app's database. On a more advanced level: The optional The optional I should say though that frankly, the simple |
Beta Was this translation helpful? Give feedback.
-
|
Any comment on this pull request? It's just the og, vanilla version of this tag without any bells and whistles. |
Beta Was this translation helpful? Give feedback.
-
|
Still think the name is an anachronism, and not something people under 30 will immediately know the purpose of. |
Beta Was this translation helpful? Give feedback.
-
|
@picard102 As something in the RSS feed, I'd hope that podcast hosting companies supporting it would give it better UX than "podroll". But, as ever, negative criticism is always made better with a positive suggestion. |
Beta Was this translation helpful? Give feedback.
-
|
podcast:list to name a few. Along with the rel tag would make the tag more understandable. |
Beta Was this translation helpful? Give feedback.
-
|
We've also already raised terms like "featured," "related," and "recommended." |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I still think this needs the structure of remoteItem because that's the building block we can eventually plug into any element that needs to reference an external thing (feed, item, tag, etc). Can we do it this way: <podcast:podroll>
<podcast:remoteItem feedGuid="a94f5cc9-8c58-55fc-91fe-a324087a655b" />
<podcast:remoteItem feedGuid="3083cd45-c371-46e8-9bad-1827bfe549f8" />
<podcast:remoteItem feedGuid="0e95de4a-1728-4d84-8ed0-3f00f8f6c27e" />
<podcast:remoteItem feedGuid="a5ad6f3f-a279-504c-bc6a-30054e6b50e1" />
</podcast:podroll>This doesn't add any more complexity and keeps remote references consistent across the entire namespace. Think of it this way: if the tags are types, we're just creating a structure that contains 1 or more members of type "remoteItem". In this case, since we only need to reference a guid, it's all we include. I feel strongly that this is better than just raw guids themselves. From an aggregation standpoint it's also easier since I can let the XML parser do the work it's already doing instead of having to write extra csv parsing logic. |
Beta Was this translation helpful? Give feedback.
-
|
Looks good to me, Dave - and agree, this allows for additional flexibility. I've updated the Podnews Daily RSS feed - podnews.net/rss - with this new style. |
Beta Was this translation helpful? Give feedback.
-
|
I don't get the remoteItem thing, but I'm not a programmer. If it's helpful for you guys, I can disagree and commit. |
Beta Was this translation helpful? Give feedback.
-
|
It's just as easy to do with Dave's suggested format - but easier for XML parsers to deal with. Additionally, it allows us flexibility in the future to add reason-codes for each show (if we want to); allows us to link directly to episodes (if we want to); and other things, without having to blow this up and start all over again. |
Beta Was this translation helpful? Give feedback.
-
|
Overall I think this is a positive change but the remoteItem tag now has three separate meanings which will make it hard to talk about. The three meanings are:
Some examples of the confusion this could cause are
Here is an example using three separate names (remoteItem, itemLink & feedLink): <podcast:podroll>
<podcast:feedLink feedGuid="a94f5cc9-8c58-55fc-91fe-a324087a655b" />
</podcast:podroll>
<podcast:remoteItem>
<podcast:itemLink
feedGuid="917393e3-1b1e-5cef-ace4-edaa54e1f810"
feedUrl="https://feeds.example.org/917393e3-1b1e-5cef-ace4-edaa54e1f810/rss.xml"
itemGuid="asdf089j0-ep240-20230510"
medium="music" />
</podcast:remoteItem> |
Beta Was this translation helpful? Give feedback.
-
Yes, it does. Same as if a podcast app supports the
This doesn't seem problematic to me as long as the spec is clearly written. The intent would be intuited from what the structure is. Parsing XML is essentially a big state machine anyway. You see this usage pattern in things like Bootstrap framework. |
Beta Was this translation helpful? Give feedback.
-
|
Added to phase-6 branch: https://github.com/Podcastindex-org/podcast-namespace/blob/phase-6/docs/1.0.md#podroll |
Beta Was this translation helpful? Give feedback.
-
|
Since podroll has been accepted into Phase 6, I think this discussion can be closed. |
Beta Was this translation helpful? Give feedback.
-
Back in the day, every blog worth its salt had a blogroll. A simple list of other blogs that the author wanted to link to. There were no rules around what a blogger included in their blogroll. Related content, stuff they found interesting, friends, sports teams, paid promotion, whatever. It was just a list of links to other blogs. Life was simple.
Now we have podcast apps all trying to solve the "discoverability problem." Some apps are trying to build smart recommendation engines that evaluate listening habits and blah blah blah. Why don't we just let podcasters make their own recommendations?
Introducing the Podroll
That's it. A stupid simple element that holds a bunch of GUIDs. It would live at the
<channel>level and listening apps could look up the GUIDs using the index API (or their local copy) and create unique experiences for displaying the podroll podcasts. Hosting companies can create simple tools for searching for podcasts and adding them to their podroll. The dependence on the Podcast Index is intentional here. If you want a podroll, and I think podcasters will want it, then you better get familiar with the index.There have been a lot of discussions, and rightly so, around `` #240 , `` #442 , ``, etc. This is quite different. This is a simple use case, it borrows from the wonderful history of blogging, could be implemented by hosts and listening apps quickly, and could prove to be quite popular with podcasters (**add me to your podroll**)!
Beta Was this translation helpful? Give feedback.
All reactions