Matt, These are valid concerns, but given that this is off topic ( with regard to supporting arbitrary contents) it would be great if you could repost that as another topic, so we can keep this clean. I'll see if we can delete your comment and mine after you've reposted it where it belongs.
Thanks for understanding! -- Julien Genestoux Sent from phone, please pardon brevity and typos. On Nov 20, 2011, at 9:59 PM, Matthew Terenzio <[email protected]> wrote: > 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 https > 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, > > >
