Thanks for resurfacing these requests Julien they are still very important as we have even more apps using real time today than we did a year ago when we discussed this one https://groups.google.com/forum/#!searchin/pubsubhubbub/turduckin/pubsubhubbub/a7SyYEMFnyc/NsggjhVWTjAJ
My comments are below. Overall I think you have captured the problem and solutions very well. On Sun, Nov 20, 2011 at 8:45 AM, Julien Genestoux < [email protected]> wrote: > 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. > Yeah any web resource. I recommend that we start doing interop testing by mime type. A challenge could be having subscribers handle multiple mime types. I stil think many subscribers will want to only get normalized JSON > > *- 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" > Yes. > *- 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. > Yes > > *- 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 :) > Its a very simple change from what I understand: Instead of the subscriber reading the 'X-hub-Signature' header and checking the signature is valid for the given body, they would read the 'Authorization' header which would be of the form *Bearer [ACCESS_TOKEN]* See http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-08#section-2.1 And verify that the access token is valid (lookup in the database for example). The reason why this is simpler and safer is that it would be transmitted over https. > > 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, > > >
