Podcast-specific prefixes using podcast-level GUID

[jamescridland]

This looks a great idea, and Podnews has committed to getting its data in there and seeing what happens. I think my method of producing RSS feed will break a few things, so worth kicking the tyres.

What occurs to me is that, rather than have prefixes that look like...

https://op3.dev/e/podnews.net/audio/podnews220916.m4a

...it might work better for the prefixes to start with the podcast-level GUID. In this case, Podnews's audio would be:

https://op3.dev/9b024349-ccf0-5f69-a609-6b82873eab3c/podnews.net/audio/podnews220916.m4a

...which could then mean the answer to the following:

a) "what podcast was this a download for?" - it should be simple to reverse-lookup which podcast it is (since the Podcast Index API, and other services, can use the GUID that is already contained in many podcast RSS feeds)

b) "how many downloads has my podcast had" - this GUID could be indexed, with an API call like /api/1/podcast/9b024349-ccf0-5f69-a609-6b82873eab3c perhaps.

This could be relatively simple to back-engineer; a podcast GUID is a set length and is recogniseable.

Perhaps this would also assist in monetisation efforts - only computing podcast-specific data when a specific GUID has been registered by an account.

(Actual audio URLs can, and do, differ and may be many different types for the same episode.)

[daveajones]

I really like this concept James.

[drpancake]

This makes a lot of sense. The only feasible alternative I can think of is allowing full-text search filtering of episode URLs e.g. "podnews.net" but that's going to be more resource intensive — and there's an issue if the podcaster switches all of their episodes to a new host.

[jamescridland]

Funny you should say that - that was my original suggestion!

I'm not sure that all podcast hosts serve audio with a clear podcast ID which would make that work. https://www.buzzsprout.com/1538779/11326945-happy-20th.mp3 does (that's Podland);
https://anchor.fm/s/81678e4c/podcast/play/57638732/https%3A%... does (the 81678e4c is a podcast ID);
...but that seems to rely a little too heavily on a podcast enclosure URL.

More to the point, Podnews audio URLs are...

https://op3.dev/e/podnews.net/audio/podnews220916.mp3?_from=podcastindex.org
https://op3.dev/e/podnews.net/audio/podnews220716.opus?_from=podkast-kaios
https://op3.dev/e/podnews.net/audio/podnews220916.m4a?_from=googleaudionews
https://op3.dev/e/podnews.net/audio/podnews220916.m4a?_from=pocketcasts.com

...and a system looking at RSS feeds and trying to match audio to episodes will have a hard time.

[johnspurlock-skymethod]

So here's been my thinking internally about rolling up episode urls to a "show".

Maintain a low barrier to entry

In the majority of cases, it should suffice to include the basic prefix and tell us the show. For self-hosters: show comes from a dropdown from the podcast index db, so we know it's a public show, and stable across feed changes. We can index the shows to index guids and episode urls (exact matches only) For host integrations, we'll rely on external feed crawlers to find them and notify us (like my own new episode system)

For quicker indexing

Allow the prefix to contain a reference to the show. Ideally without creating YAPI (Yet Another Podcast ID). Really love the idea of trying to use PI's podcast-level guid tag for this, but not all shows support. Perhaps this could encourage support. Host integrations could/should include this automatically

OP3 will still need to verify the podcast reference in the prefix (ie refetch, index items and enclosures), to protect against typos, copy/pasting, and the other inevitable bad input.

Non-stable enclosure urls

99% of feeds have static enclosure urls. We can match the url received in the request exactly to an item in the public feed. However, OP3 should also make it possible for publishers that include dynamic variation (like the podnews feed), to include an episode/item reference in the prefix as well. It should still be publicly verified (fetch the feed, ensure item references in the enclosure correctly reference their enclosing item) again to guard against typos / bad actors cloning feeds

Prefix parameters

I see both of these (podcast reference, item reference) as the first two of potentially many optional parameters that OP3 may support to tunnel additional info back to the system (think podcast network, user-defined tags, etc in the future)

The basic prefix should always be supported: https://op3.dev/e/<target-url>

But optional parameters should be supported via standard mechanism, with standard short names

e.g. https://op3.dev/e,<param-name>=<param-value>,<param-name>=<param-value>/<target-url>

I'd suggest the first two supported, optional parameters to be:
pg: Podcast guid: Unencoded raw guid value from the podcast:guid tag (we know the format)
eig: Encoded item guid: urlsafeBase64-encoded item/episode-level value from the tag. Encoded since it's arbitrary, can be an url itself! Base64 chosen over hex since guids may be longish

https://op3.dev/e,pg=61673dc5-0a31-4f87-9b86-eff1c27b233d,eig=aXRlbWd1aWQ=/<target-url>

How does that sound?

[jamescridland]

Thanks for this, John.

For me, simply using wildcards in the URL, which is now supported, is enough for all my use-cases.

I do like the idea of optional parameters for other things (possibly for pulling in - for advanced users - more dynamic information from RSS feeds or other methods of sorting downloads. x

[johnspurlock-skymethod]

Ok, so I rolled out prefix parameters this week, and started with pg as described above - allowing folks to specify the Podcast Guid for the show in question. Also the new setup page makes it easy for anyone to lookup the Podcast Guid of their show.

While not strictly required, it will allow OP3 to attribute episodes to shows more qulckly, and is actually enough to support James' url variation as well, since I'll be able to make a match given the urls in the feed, even if they do not match exactly.

Thanks for integrating already @jamescridland - keep an ear out for any listeners running into problems. The url looks strange, but should be fine in all players - from the backend it looks like it appears to be working smoothly so far.