Nick Lothian pointed out an interesting point today. Not only does the IP address endpoint requirement break virtualized datacenters like AppEngine that router in/out HTTP traffic differently, it also *entirely* breaks for vhosted HTTP sites. Many sites are not accessible over HTTP/1.0 and require a specific Host: header. rssCloud makes no accommodation for this, locking those sites entirely out of the ecosystem.

Since there’s no way to guarantee that every feed reader will support rssCloud, it makes more sense as a hub admin or a publisher to start with PSHB which at least has a chance of being implemented on every host.

I think it’s likely that the ultimate measure of these two solutions is going to come from the breadth of support at the hub level. This is the piece of technology that neither publishers nor subscribers are going to create themselves, at least not in any production-quality form that scales. So it’s important to think about how implementors of hubs are going to view the APIs and the hub-specific implementation requirements.

rssCloud needs some API work to bring it up to par with PSHB’s subscription API. It’s missing any sort of validation of subscription requests: any URL that returns 200 OK is considered successful. This lets you do fun stuff like subscribing an rssCloud hub to another rssCloud hub’s subscription address (repeat ad nauseam). Dave Winer’s own rssCloud endpoint failed to validate that the rssCloud parameters were provided in the body of the POST, allowing someone to subscribe another hub to it as an endpoint.

Pubsubhubbub uses a verification key to ensure that the endpoint is actually the one that requested the subscription. Not having this sort of verification in rssCloud is opening up the system for an exploit, one of which I submitted to the author of WP rssCloud already (fixed in 0.3)!

Additionally, rssCloud requires that your endpoint match your IP address which is not always possible in many hosted web environments. This limitation also prevents you from subscribing other parties on your behalf, which is useful in the desktop feed aggregator case. I’ve already used this to build a PSHB->XMPP gateway (available here http://pubsubhubbub-xmpp.appspot.com/) that would enable it on the desktop.

Note that PSHB isn’t concerned with “new” data, but rather changes in the document overall. If a post is modified, the updated content is included in the notification ping. This means that it can be used to deliver updates from a liveblog post to subscribers in real-time, for instance.

Pubsubhubbub notifications to the hub, as well as from the hub to the subscriber would happen under an identical set of circumstances as with rssCloud. It’s not even a superset or subset of rssCloud’s notifications: they will always happen in tandem.

The big advantage for PSHB is that it does the grunt work of detecting any feed change so that every subscriber isn’t required to fetch the full feed and perform the operation that the hub would be performing on its behalf. If there’s a use case that isn’t covered by PSHB, there’s nothing stopping the subscriber from hitting the feed specified in the notification update and performing its own checks every time (effectively falling back to the same semantics as rssCloud).

From what I can tell, PSHB is somewhat influenced by Atom’s structure, in that it assumes there are a stable set of IDs for it to base the feed diff on. I’ve peered into the source and they have a significant number of testcases to deal with RSS, which is notoriously unreliable when it comes to permanent identifiers. The PSHB protocol works fine using any type of RSS, however – it just delivers a subset of the RSS document, in RSS format during every change.

FWIW, the notifications in PSHB are basically just HTTP POSTed versions of the feeds that it subscribes to, with all the unchanged feed items stripped out. There’s no magic format here: unchanged content is simply removed.

I’m curious how much of that behavior is dependent on attributes within the Atom format (of which I am fairly ignorant).

rssCloud hubs cache the digest of the *whole feed*, while PSHB hubs cache the digests of the individual RSS/atom entries. The document as it is infers that rssCloud doesn’t keep track of the feed that it is tracking.

Here’s the relevant part of the PSHB spec: “The hub caches minimal metadata (id, data, entry digest) about each topic’s previous state. When the hub re-fetches a topic feed (on its own initiative or as a result of a publisher’s ping) and finds a delta, it enqueues a notification to all registered subscribers.”

It seems like Pubsubhubbub could add a note that hubs may send “update-only” notifications and take on the only real functional difference between PSHB and rssCloud. With that change, you could port over the current WP rssCloud plugin by replacing the HTTP POST parameters and checking the result of subscription requests.