View Issue Details

IDProjectCategoryView StatusLast Update
0001337Composrsyndicationpublic2020-03-22 20:16
ReporterChris GrahamAssigned To 
Status non-assignedResolutionopen 
Product Version 
Fixed in Version 
Summary0001337: WebSub (PubSubHubbub) support
DescriptionImplement support for WebSub (previously named PubSubHubbub) in addition to the existing RSS cloud support.
Additional InformationGoogle are preferring PubSubHubbub. I had an exchange with a Google engineer on when PubSubHubbub was released, and they had not even heard of the official RSS cloud feature when they were designing PubSubHubbub - now it's political, as Google are pushing their own standard (grr...).
TagsType: Mobile, Type: Performance
Attach Tags
Time estimation (hours)5
Sponsorship open


related to 0002108 closedChris Graham Support Growl-style notification API 
related to 0002109 non-assigned Support any notification API via third-party platform (idea staging issue) 
related to 0002107 non-assigned Web push notifications 


Chris Graham

2015-12-05 16:04

administrator   ~0003231

Feedly uses pubsubhubbub, but does not currently support Push Notifications. I imagine at some point it will, at which point this will be an effective notification system when the web_notifications RSS hook is connected through to it.

Chris Graham

2015-12-08 20:50

administrator   ~0003234

If implementing this we should drop the RSS cloud feature. I don't think anyone on the Internet is even using it. Few people use PubSubHubbub explicitly, but at least it is supported by Feedly, which is the leading feedreader.

Chris Graham

2019-06-21 19:15

administrator   ~0005977

PubSubHubbub should be implemented as a background task, unlike the current RSS cloud implementation.

Chris Graham

2020-03-22 20:16

administrator   ~0006480

Looking at this again, I can see that WebSub isn't really very open. The ping protocol between hubs and publishers is not defined - just the protocol between hubs and clients.
"The specific mechanism for the publisher to inform the hub is left unspecified. For example, some existing public hubs [1] [2] [3] ask publishers to send a POST request with the keys hub.mode="publish" and hub.url=(the URL of the resource that was updated)." []

I'm not sure exactly why we'd want to implement 3rd party companies personal standards in Composr. It seems a bit bizarre to me, handing off control to the private companies who are choosing to implement hubs - the W3C should have properly specified it.

The whole advantage of WebSub over RSS Cloud is that the heavy lifting is off-loaded to the hub. So we can't realistically implement a hub ourselves as that defeats the whole point. But if we implement for some company's specific hub protocol, we are not being open.

The only reason I could see to implement private companies WebSub ping protocols is if our implementation of RSS Cloud really was being overwhelmed by lots of users requesting to be pinged about updated resources at the same time. This has never been a problem, and I don't expect it to be - as there are only a handful of feed readers out there that are going to implement subscription to an RSS Cloud server (Feedly?) - and few people use RSS anyway.

Issue History

Date Modified Username Field Change
2019-06-21 19:15 Chris Graham Note Added: 0005977
2020-03-22 20:05 Chris Graham Summary PubSubHubbub support => WebSub (PubSubHubbub) support
2020-03-22 20:05 Chris Graham Description Updated View Revisions
2020-03-22 20:16 Chris Graham Note Added: 0006480