Dude, I'm saying it is relevant and since it IS RELEVANT it should be its own topic and not diluted into any other topic...
On Nov 20, 2011, at 10:17 PM, Matthew Terenzio <[email protected]> wrote: > I thought it was hugely relevant. Sorry. You see, I can't seem to win here. > I'll go back to keeping my mouth shut. > > On Sun, Nov 20, 2011 at 4:14 PM, Julien <[email protected]> wrote: > 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, >> >> >> >
