Subscribe by email, free
Your daily briefing for podcasting and on-demand

A podcast industry guide to WebSub, or PubSubHubbub - what it is, why it's worth supporting

March 22, 2019 · Updated May 22, 2019 · By James Cridland · 5 minutes to read

PubSubHubbub sounds almost the same as “blahblahblahblah”. Because it’s a ridiculous name for anything, you’d be absolutely right in ignoring it and thinking it’s got nothing to do with podcasting. That’s why it’s really known as WebSub these days: sounds less stupid, but it’s the same thing.

You’d be wrong to ignore it though. PubSubHubbub fixes one of the main problems for podcasting - in an elegant manner that’s backwards-compatible with every single podcast app out there.

The Problem

Podcasting works using an RSS feed, which is essentially a list of your episodes. A podcast app will, every so often, pull down a new copy of your RSS feed - and see if there’s a new episode of your podcast in there.

So, podcasting is PULL, not PUSH. When you upload a new episode of your podcast, you need to wait for the various podcast apps out there to pull your RSS feed. And that’s fine, most of the time. Usually, podcast apps (or the servers they’re connected to) will check your podcast RSS feed every few hours, and everyone’s happy.

But this causes a few issues:

What’s needed

What we need is some way for a podcast app to know when a podcast has been updated.

Wouldn’t it be great if you could upload a podcast, and somehow every single podcast directory out there knows that your podcast has been updated, and instantly tells podcast apps? PUSH not PULL?

And wouldn’t it be good if it was free to use, and really easy to implement?

That’s what pubsubhubbub is.

How PubSubHubbub works.

It’s just like a WhatsApp group. I post a text message to WhatsApp, and WhatsApp sends that text message automatically to everyone wants to be a part of that group.

A publisher of a podcast lets apps subscribe to get told about new events, like a podcast being uploaded, using a hub (run by the publisher or run by someone else).

I publish a new podcast, and my podcast host automatically tells the hub that I’ve published it. The hub has lots of servers subscribed to it, and it tells all of them to look at my RSS feed again because it’s changed.

Some podcast hosts and apps already support it

When Podnews publishes a new episode of our podcast, our podcast host notifies our hub that we’ve done so. The system that runs Google Podcasts is subscribed to our hub: and less than a minute later, my Android phone says that there’s a new episode available.

A more technical run through for a publisher

Our RSS feed has a line right at the beginning of it that says which hub we use. It looks like this:

<link rel="hub"
  href="https://pubsubhubbub.appspot.com/"
  xmlns="http://www.w3.org/2005/Atom" />

As you can see, it just points to a server at pubsubhubbub.appspot.com. That’s a free one, run by Google (though you can build your own if you want - it’s decentralised and free, just like podcasting is).

When we publish a new episode, we then run this PHP code.

//Update Google PubSubHubbub
$data = array(
  'hub.mode' => 'publish',
  'hub.url' => 'https://podnews.net/rss'
  );
$handle2 = curl_init('https://pubsubhubbub.appspot.com/');
curl_setopt($handle2, CURLOPT_POST, true);
curl_setopt($handle2, CURLOPT_POSTFIELDS, $data);
curl_setopt($handle2, CURLOPT_RETURNTRANSFER, true);
curl_setopt($handle2, CURLOPT_HTTPHEADER,
  array('Content-Type: application/x-www-form-urlencoded'));
$result = curl_exec($handle2);
curl_close($handle2);

This tells the hub that we’ve published something. The hub then goes off and tells everyone to go and take a look at our RSS feed because it’s changed.

That’s literally it, there are no more steps.

Here’s the full specification - it’s been a “thing” for over ten years now.

If a podcast directory or app doesn’t support it, it ignores the line in your RSS. And if it does support it, it means almost instant updates for your podcast.

As a podcast app, how should we implement it?

We’d recommend adding a subscription endpoint in addition to your existing RSS polling service. That way, you’ll get instant updates to WebSub-compatible podcasts, but your existing systems will automatically keep updated.

So why doesn’t everyone support it?

That’s a great question. In fact, we don’t know who does support it, and who doesn’t.

Google Podcasts specifically recommends it, and supports it. Given that - and the ease of implementing it - you might think that it’s worth every single podcast host supporting this service. But that’s not, yet, happening.

On an episode level, none of Libsyn, Spreaker, Podbean, Simplecast, ART19, ABC Australia, Blubrry, Whooshkaa, Anchor, or Megaphone support it. However WNYC does (through Feedburner), and Feedpress also supports it.

It’s harder to check which podcast apps support it: we can see some of our data from our secondary hub, and know that Inoreader, Feedly and other RSS readers are using it.

If more podcast publishers supported WebSub, it would significantly reduce support queries (“why isn’t my latest episode showing in XXXX app?”), and has no negative effects. It’s a tiny amount of work, for potentially great benefit.

If you’ve comments on this: please, use our comments box below.

—James is the Editor of Podnews, and was first involved in podcasting in January 2005.

Previously...

<< Google Podcasts will soon have a website (and it'll run on iOS too)

Our supporters (become one)

Gold supporters

Silver supporters

Get a global view on podcasting and on-demand with our daily news briefing

Subscribe to our daily newsletter by email, free