Summary

  • PubSubHubbub replaced the feed reader's repeated question—“anything new?”—with a publisher, a hub and a callback. The 2010 working draft described the hub fetching changed feeds and distributing updates. Speed came from moving the checking and fan-out to an intermediary.
  • WebSub's 2018 W3C Recommendation made the operating bargain plain. A hub's 202 Accepted acknowledged a request that still needed validation and callback verification. Subscriptions had expiring leases; the subscriber had to renew before the hub's clock ran out. An open protocol still put each update behind a live desk.

The reader stopped knocking on every door

A feed reader that wanted fresh posts could keep asking each publisher's server for the same feed. Most answers would say nothing had changed. The PubSubHubbub Core 0.3 working draft of February 2010 opened with a blunt complaint about polling and proposed a different route. A publisher advertised a hub in its Atom or RSS feed. When the feed changed, the publisher notified the hub. The hub fetched the feed, found the change and sent a notification to subscribers' callback addresses.

That is a clever way to remove a crowd from the publisher's front door. The publisher sends one change notice to a distributor; the distributor deals with the audience. The original draft's reference implementation targeted Google App Engine, yet the draft said the protocol itself was open and anyone could run a hub. The architecture did not require one corporate switchboard. Every particular subscription, however, passed through the hub that the publisher advertised.

The subscriber had to do more than ask. Its subscription request named the feed, the hub and a callback URL reachable from the network. The hub then sent a hub.challenge to that callback, and the subscriber had to echo it to prove it wanted the subscription. That verification kept a stranger from subscribing or unsubscribing someone else's endpoint by filling in a form. The hub also held the subscriber list and decided when a changed topic would be fetched and distributed. Replacing polling with push relocated work, not responsibility.

A receipt could arrive before a subscription existed

In January 2018, the W3C published WebSub as a Recommendation, the new name for PubSubHubbub. Its versioned technical specification kept the publisher–hub–subscriber structure and described topics as web resources rather than only Atom or RSS feeds. A publisher advertised topic and hub URLs; a subscriber discovered them and sent a form POST to the hub. The hub would later deliver the updated content with a POST to the subscriber's callback.

The status code in the middle is easy to misread. A capable hub was required to answer a subscription request with HTTP 202 Accepted. In the specification, that meant the request had been received and would proceed to validation and verification. The hub could still reject a topic or callback under its own policies. It could send a denial to the callback. It had to challenge the callback and check the echoed token before treating the request as confirmed. A green receipt was the start of an exchange, not a subscription certificate.

The hub's clock supplied the second boundary. The 2010 draft allowed leases and described the hub rechecking subscribers for automatic refresh. The 2018 Recommendation required hubs to enforce expiration and forbid perpetual leases. It required the hub to send hub.lease_seconds on a subscription challenge; the subscriber had to request renewal before that time elapsed. A feed could stay public, the publisher could keep updating it, and a subscriber that missed its renewal could fall out of the push path. The update did not disappear from the feed; its scheduled delivery to that callback ended.

These are concrete controls for a real service, not decorative protocol fields. The publisher chooses and advertises hubs. The hub chooses whether to accept a callback or topic, verifies intent, maintains leases and queues distribution. The subscriber maintains a reachable callback and renews. The standard permits multiple hubs and independent implementations, which prevents the protocol from assigning a permanent monopoly. It still assigns a live operational role to each selected hub.

The delivery desk stayed open only while staffed

The W3C specification required the publisher to inform its designated hubs of an update, but left the publisher-to-hub notification method to their agreement. Once notified, the hub retrieved content and sent it to callbacks. A failed delivery could be retried within the hub's own limits; the hub had to keep the subscription active until its lease ended. Each stage therefore had a different receipt: publisher change, hub notification, accepted subscription request, verified callback, active lease, delivered update. Collapsing them into “the web went real time” hides where an item could wait.

The great trick of PubSubHubbub was to stop every reader from repeatedly asking every site the same question. WebSub preserved that trick and wrote down the lease and validation machinery needed to keep the distribution list honest. The bill for fewer polls was a new obligation: somebody had to run a hub, somebody had to keep a callback reachable, and somebody had to renew the subscriber's place in line.