Proposal: Fast Follow fallbacks and broader compatibility

[theDanielJLewis]

I understand how the current Fast Follow feature works: adding a hash to a URL.

But I strongly urge us to standard additional methods for broader support and compatibility.

Reposting an updated version of my previously shared thoughts on how I think Fast Follow should work.

1. A QR Code can go to any page a podcaster wants. That could be their FollowthePodcast.com page, a page on their site, or anything else.
2. A standard QR Code reader will load that webpage, and I would hope the page smartly displays follow/subscribe links that would work on the visiting device (like I do for FollowthePodcast.com). These embedded links can use URL schemas or other methods to launch specific apps. For example overcast://x-callback-url/add?url=https://feeds.podcastmirror.com/theaudacitytopodcast is my Overcast deep link.
3. A podcasting 2.0 app would have its own QR Code scanner. When scanning a Fast Follow URL (more on that in point 4 below), the podcast app would jump straight to that podcast (without loading a browser) within its own catalog, where the user can then tap to follow/subscribe.
4. Fast Follow URLs could be made by (and used in this order):
   A. Adding the podcast GUID to any URL, as is the current draft.
   B. Adding a tag to the headers, like podcast-guid: XXXXXX or podcast-fast-follow: XXXXXX. This tag would need to be read before following any redirect.
   C. Adding a tag in the page HTML, like <meta name="podcast-guid" content="XXXXXX"> or <meta name="podcast-fast-follow" content="XXXXXX">. A podcasting 2.0 app would follow that fallback order, and then launch the browser if no GUID.
5. Smart pages, like FollowthePodcast.com, could display the QR Code on PC browsers with the instruction, "Scan this with a Podcasting 2.0 app to fast follow!" Allowing visitors to quickly transfer the follow action from PC to phone.

The result would be an experience that could work for any device, but especially work nicely for podcasting 2.0 apps.

I would absolutely love to add the GUID header tag to all FollowthePodcast.com pages for my users, but I'm not interested in telling them to add a GUID to their URLs or lengthening the URL (which would result in a more complicated QR Code). I want it to "just work" for my members and any podcast consumers.

[jamescridland]

1. Yes, this works with the current spec.
2. Yes, you can put anything on your webpage.
3. Yes, this is exactly the use-case and works with the current spec.
4. This isn't needed, since a hash in the shared URL already contains this information
5. Yes, Podnews pages already have fast-follow links that work this way (visible on desktop). Here, try one!

[jamescridland]

I would absolutely love to add the GUID header tag to all FollowthePodcast.com pages for my users, but I'm not interested in telling them to add a GUID to their URLs or lengthening the URL (which would result in a more complicated QR Code). I want it to "just work" for my members and any podcast consumers.

The "lengthening the URL" bit isn't an issue (the QR code above has a lot of error correction added to it but isn't complex).

One potential suggestion: JSON-LD has a schema type for PodcastSeries. If you look at Podnews podcast pages, or Castopod pages, you'll see that we've both used the "identifier" field to add the GUID in there. Podchaser has JSON_LD too, but doesn't yet use the GUID as an identifier - perhaps we should try to push for that. Also in the JSON_LD is the RSS address, title, description, etc. Spotify also uses JSON_LD in this way.

If we were to strongly suggest that fast-follow pages contained a JSON_LD schema that should contain the GUID, then that would make all podcast pages on the web machine-readable, and help significantly with all kinds of things.

[theDanielJLewis]

I think 4 is extremely important and I will continue to fight for it for full compatibility, podcasters' control, and inclusivity.

I have a thousand business cards with a QR Code. How do I add Fast Follow to it since the URL is already set? I can't.

No podcaster should have to add their GUID to a URL as their only option, they should be able to add the feature to a URL without changing that URL.

Here's a clean, simple QR Code that can be scannable at small sizes:

But here's the same URL, now with Fast Follow (I think I got all the code):

[theDanielJLewis]

Having the URI as the only option requires the podcaster to do the work to include it. Where does one even find their podcast GUID?

Support the data in the headers and HTML allows anyone to easily support it through a plugin or automatic integration. And podcasters don't have to think about it again.

But if the URI is the only option, they have to know to use that URL to generate a QR Code or redirect, and they would have to ensure they properly add the GUID to the URL.

And what happens if they get it wrong or the GUID changes? Then any existing links or QR Codes that had the GUID "baked into" the URI will become invalid.

[jamescridland]

Your podcast host would give you a URL that works including the GUID. That's the ideal.

The GUID never changes, by the way. That's the whole point of it. It's algorithmically generated from the first RSS feed you ever had.

So, if we were going to change (and complicate) the spec, would you agree with putting it in the JSON schema for a PodcastSeries?

We already know that trying to put things in HTTP headers is beyond the comprehension of most podcasters anyway (see Google Podcasts for an example).

The advantages of ensuring its in a schema would help everyone. Here's the full schema in a Podnews page; but you'd be able to only have the identifier if you really wanted.

<script type="application/ld+json">{"@context":"http:\/\/schema.org\/"
"@type":"PodcastSeries",
"about":"How To, Education, Marketing, Business, Technology",
"accessMode":"auditory",
"author":"Daniel J. Lewis",
"creator":"Daniel J. Lewis",
"genre":"How To, Education, Marketing, Business, Technology",
"headline":"The Audacity to Podcast",
"inLanguage":"en",
"publisher":"Daniel J. Lewis",
"name":"The Audacity to Podcast",
"description":"Giving you the guts and teaching you the tools to start and grow your own podcast for passion or PROFIT!",
"image":"https:\/\/podnews.net\/r\/t\/594\/8170-423958ec.jpeg",
"url":"https:\/\/podnews.net\/podcast\/i6ay",
"sameAs":"https:\/\/theaudacitytopodcast.com\/",
"identifier":"664675c6-78b5-5e2c-95c9-b93accaaabc9",
"webFeed":"https:\/\/feeds.podcastmirror.com\/theaudacitytopodcast",
"aggregateRating":{"@type":"AggregateRating",
"ratingValue":4.7272727272727275,
"ratingCount":11,
"bestRating":5
}}</script>

[jamescridland]

I would also add - both those QR codes are fine to scan. If we've learnt anything over the last two years, it's that QR codes are robust, that they work even if they're quite complex, and people understand them.

This complex one has been in use in every store and cafe for the last two years in my state. Another, much more complex one, has been used down the road in NSW.

[theDanielJLewis]

Further, supporting non-URI methods would allow all past URLs and QR codes to still work.

So for the woman who put her podcast website QR code on 2,000 business cards, she could activate something on her site and all those 2,000 business cards are suddenly Fast-Follow-compatible.

Or for the man who put a subscribe/follow URL in the episode notes for all his past 1,000 episodes, a quick switch makes all 1,000 of those past calls to action now Podcasting 2.0 friendly.

This really isn't complicating the spec, it's providing for much greater control, versatility, and prevents waste.

@jamescridland, can you help me understand why you're opposed to it? So far, all I've understood from you is essentially "the URI is sufficient," but no reasons against these fallbacks.

[jamescridland]

I was just trying to keep things simple for developers, and didn't see the benefit of the change. A lot of the reasons given were just concerns about the current hashtag construction.

But it seems that JavaScript can read response headers of pages - and can parse for the <meta> tag, so I can see this being workable. I'd suggest the header tag is correctly capitalised as in the current IANA HTTP header list, so it should be Podcast-GUID:

Alternatively, as a different suggestion to using the <meta> tag, why not use (and encourage) the current PodcastSeries schema? The benefits of using proper schema in podcast pages would give a benefit to crawlers everywhere - notably, this schema includes the RSS feed, the guid (here marked as "identifier") and access to logos and other things.

You'll find this schema in, among other places, Podnews, Podchaser, Spotify and Castos.

{
	"@context": "http:\/\/schema.org\/",
	"@type": "PodcastSeries",
	"about": "How To, Education, Marketing, Business, Technology",
	"accessMode": "auditory",
	"author": "Daniel J. Lewis",
	"creator": "Daniel J. Lewis",
	"genre": "How To, Education, Marketing, Business, Technology",
	"headline": "The Audacity to Podcast",
	"inLanguage": "en",
	"publisher": "Daniel J. Lewis",
	"name": "The Audacity to Podcast",
	"description": "Giving you the guts and teaching you the tools to start and grow your own podcast for passion or PROFIT!",
	"image": "https:\/\/podnews.net\/r\/t\/594\/8170-423958ec.jpeg",
	"url": "https:\/\/podnews.net\/podcast\/i6ay",
	"sameAs": "https:\/\/theaudacitytopodcast.com\/",
	"identifier": "664675c6-78b5-5e2c-95c9-b93accaaabc9",
	"webFeed": "https:\/\/feeds.podcastmirror.com\/theaudacitytopodcast",
	"aggregateRating": {
		"@type": "AggregateRating",
		"ratingValue": 4.7272727272727275,
		"ratingCount": 11,
		"bestRating": 5
	}
}

[theDanielJLewis]

The schema would be great, and I would think that—or a <meta> link—would be easier for someone to add to a site or webpage than a header tag, because it's simply a block of code.

The unfortunate thing, however, is that the URL body must be loaded in order to read either schema or meta tags. Thus the header tag would be far more performative.

[theDanielJLewis]

It's been a year. I'd like to refresh this because this feature is almost completely audience-focused (and I think we need to consider the audience with more of our features).

I fully support a GUID in the URL hash to trigger Fast Follow. And I also still think we need to support fallback methods of an HTTP header and an HTML <meta> tag.

The main reasons I think we need these fallbacks:

1. So existing QR Codes (especially printed ones) don't have to be changed.
2. So existing link URLs (like in episode notes) don't have to be changed. (This could be a good consideration for Proposal: universal in-app episode linking #422, too.)
3. So the integrated camera's OCR can even fast follow from a printed URL.