I brought an issue up in the early days and got a few decent responses and a number of irrelevant attacks which I guess was because I was considered the RSSCloud guy on the PuSH list. Just thought I'd toss that in here. ; )
But it had to do with the architecture of PubSubHubbub and respecting copyright. At some point in a a widely grey area there is a line between syndication and unauthorized redistribution of content. I don't know where it is and it might even begin with the publishers intention or implicit license they give by making a feed available. While I tend to lean toward more open licenses for content, not everyone does. And because hubs can daisy chain content down lines, whether or not your hub is respectful might not mean you aren't part of a questionable distribution chain. That last part is certainly not the strong part of what I'm saying. Just saying we should think about what it means to redistribute parts of the web that owners might not have intended for syndication. Aside from that concern which I'm sure you have already thunk about, I think it has incredible potential with the explosion of semantic web data arriving on the web. So much so that I could see feeds being unnecessary for many sites since all the pages are marked up well enough that the description of the content is just as easily digestible from the web page as it was from the feeds. Almost, at least, though there would still be the overhead of the crawl, I guess. But for many blog style sites, a sematically marked up home page is practically as good as a feed. On Sun, Nov 20, 2011 at 11: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. > > *- 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, > > >
