How a W3C protocol replaced the polling loop with a server-side nudge

Feed readers have always faced the same arithmetic problem: a subscriber checking a feed every fifteen minutes will wait up to fifteen minutes to see a new post. The content exists; the reader simply has not asked for it yet. Two solutions emerged to close that gap — and they work at opposite ends of the transaction.

The older fix is the conditional GET, an HTTP caching mechanism that lets a feed reader ask a server "has anything changed since I last checked?" using ETag or Last-Modified headers. If nothing has changed, the server responds with a 304 and sends no body, saving bandwidth without reducing the polling interval itself. Latency stays the same; waste is merely cut.

Small self-hosted server on a home-office shelf with ethernet cables routed neatly, indicator lights lit
Miniflux and FreshRSS will run on hardware of this order. That is the whole argument for hosting a reader yourself.Photo: panumas nikhomkhai / Pexels

The bolder fix is to invert the relationship entirely. Rather than the subscriber asking, the publisher tells. That is the logic behind WebSub.

The Hub in the Middle

WebSub began as PubSubHubbub, a protocol designed by engineers at Google around 2009. The mechanism is straightforward: a publisher embeds a <link rel="hub"> element in its feed, pointing to a hub server. When the publisher posts new content, it sends a lightweight ping to that hub. The hub, which already holds a list of subscribers for that feed, immediately pushes the updated content to each of them. A subscriber that has registered with the hub receives updates in seconds rather than minutes.

From the record

How the protocol works

  • Publisherposts content and pings the hub
  • Hubholds subscriber list; pushes updates immediately on receiving a ping
  • Subscriberregisters with the hub; receives content without polling
  • Challenge handshakehub sends a token to the subscriber endpoint; subscriber must echo it back before being added to the distribution list

Chronology

  1. ~2009PubSubHubbub designed at Google
  2. January 2018W3C renames and standardises it as WebSub

Google operated one of the first public hubs, and for years it was the dominant implementation. Superfeedr, a third-party hub service, made the protocol available to publishers who wanted to avoid operating their own infrastructure. The W3C standardised WebSub in January 2018, renaming it from PubSubHubbub and formalising the three-party relationship between publisher, hub, and subscriber.

The verification step matters to the model's integrity. When a subscriber registers with a hub, the hub sends a confirmation request to the subscriber's endpoint; only after the subscriber echoes back a challenge token does the hub add it to the distribution list. This prevents the hub from being weaponised to flood arbitrary URLs with unsolicited content.

Terminal window on a dark monitor showing a raw Atom feed in XML, angle brackets and namespaces visible, person's hands on keyboard
A feed is a text file sitting on a server. Between the publisher and the reader there is a fetch, and nothing else.Photo: Tima Miroshnichenko / Pexels

Two Solutions, One Problem

Conditional GET and WebSub are not mutually exclusive — a well-built feed reader can use both. Conditional GET handles feeds whose publishers never registered a hub; WebSub handles the rest with near-zero latency. Together they describe the full spectrum of what polling-based infrastructure can achieve without discarding the feed format itself.

Adoption has been uneven. Many WordPress sites expose a hub link by default; most static sites do not. Mastodon's ActivityPub pipeline operates on a push model that is philosophically similar but architecturally separate. WebSub remains the only W3C-standardised, feed-native push layer the open web has — modest in uptake, precise in design.