This is a pretty thick topic and involves a lot of changes in the spec! Generally, I believe it should not be destructive, so the current spec that applies to feed should probably be moved (and kept) to an annex/extension called "PubSubHubbub for RSS/Atom feeds" that should include all the specific points that apply to feeds.
Here are the changes I think are necessary : *- Definition* We should probably come up with a definition of what an "abritrary content" is. My "simple" answer would be : any web resource that is accessible thru a URL. *- Discovery* Right now, the discovery is very RSS/Atom centric, as it works thru the addition of an atom:link element poitning to the hub. This should be moved to the PubSubHubbub for RSS/Atom spec, as arbitrary resources may not have a "schema" which would allow for this. The answer that Monica cam up with a long time ago was HTTP Link headers. Each resource that is available thru PubSubHubbub should then just come with a Link HTTP header, with a rel indicating it's a hub, and the right href. Something like this: The Link:<http://hub-url>;rel="hub" The feed specific also insists on the required rel="self" link. This can also be enforced using the same approach: Link:<http://resource-url>;rel="self" *- Diff* The current version of the spec is very specific to RSS/Atom feeds and should be moved onto the feed's extension. the idea is that the hub may not be able to diff the content in a meaningful way. As of now, the hub is just supposed to push the difference with the "older" representation of the resource and the newer representation of that feed (namely the entries), but also a few items that are "constant" to the feed, like it's <link> elements. We should probably change the spec so that the hub sends the whole resource in its current state. Also, the hub should push the content of the HTTP headers that the susbcriber would get should he poll the resource, including the Link: headers as they are used for discovery. *- Secure Notifications* Up to now, the notifications were secured if the subscriber and the hub used a shared secret to compute an HMAC signature out of the body. The problem introduced with arbitrary content notifications is that we need to sign the headers as was as they may include data that should not be forged. Since the signature should itself be passed as a header, we have a problem. The solution that seems to solve this is to force the subscriber to use http *s *callback urls, and use the signature as a bearer token, as in the OAuth2 spec. I'd love it if someone could just provide a friendlier explaination of how things would work exactly for those like me who are not completely familiar with OAuth2 :) Again, this is a very significant change to the spec, and there is probably a couple other points that I overlooked. Please, feel free to contribute! Thanks,
