Proposal: New element <podcast:podroll>

[snookfin]

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

<podcast:podroll>29cdca4a-32d8-56ba-b48b-09a011c5daa9, 396d9ae0-da7e-5557-b894-b606231fa3ea, 917393e3-1b1e-5cef-ace4-edaa54e1f810</podcast: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**)!

[jamescridland]

I really like this. Very good. Simple and straightforward.

[theDanielJLewis]

Check out #205, by @benjaminbellamy.

[snookfin]

@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.

[theDanielJLewis]

I was simply pointing to the prior discussions of the same idea.

And I recommend a recommend tag. I don't think "blogroll" ever really stuck, so "podroll" seems a little awkward to me. Plus, I first thought this post had something to do with midroll ads, not recommendations.

[genebean]

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.

[theDanielJLewis]

However it's implemented, I still think we should use the far more widely understand terms "recommendation" or "featured" or something like those.

[samsethi]

This is a great idea and could be implemented either at the host or on the app. As an app developer, this could be done quickly but it would proprietary and limited because it would not be part of the podcaster's RSS feed. Podchaser has implemented something like this but it is not exportable.

Therefore this can only be offered by hosts to podcasters and then added to their RSS to ensure it is both open and available to all apps.

I think Dave mentioned Kevin's blogroll idea in this weeks Podcasting 2.0 (episode 126) and that it could either be OPML within the namespace or a JSON file link like chapters.

[theDanielJLewis]

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").