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 >> 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, >> >> >> >
