I approve of this idea. On Sat, Jan 23, 2010 at 7:06 PM, Blaine Cook <[email protected]> wrote:
> I've been busy so didn't get a chance to reply to this right away, but > I want to second (or third or fourth as the case may be) Julien's call > here. > > I think that what he's getting at is actually the most important use > case for PubSubHubbub, and the existing spec doesn't *quite* provide > the necessary tools, even for publishers who run their own hubs. > > The scenario I want to enable is deferred approval of subscriptions to > private content. > > For example, take a publisher, Tom, and a subscriber, Sally. Tom is > publishing a journal of his innermost thoughts on hist own website, > and doesn't want that content to be public. However, he'd like his > friends to be able to read the journal. Let's assume for now that > we're living in the future and that they want to use PSHB to receive > his journal entries. > > Tom has three options: > > 1. He can give all of his friends a private URL, and hope that they > don't share it. He will not be able to retract access, since it's just > one URL. > 2. He can give each of his friends a different URL. He can retract > access by ceasing publishing to any one of these URLs. > 3. He can give all of his friends, or anyone who isn't his friend, the > same URL, and decide whether or not to give them access as they come > and ask. > > Option (1) is clearly not going to work if Tom has more than one or > two friends. Option (2) is the model Flickr uses for their guest > passes and is often referred to as "casual privacy" or "URL-based > capabilities". This is a good model, except that Tom has to distribute > the URL to his friends, and so needs an out-of-band mechanism to share > his content with them. Option (3) is how virtually every social > network operates, and enables people that Tom wouldn't think to share > a private URL with, but with whom he might want to share his content > to ask for permission. > > You can see my bias here; I want Option 3 to be supported over > PubSubHubbub. > > In order to do this, any subscription requests need to be approved by > Tom. So, when Sally asks her feed reader to subscribe to Tom's feed, > Tom's hub must wait until Tom gets back at his computer to verify the > request. > > Julien's mechanism is great, but I'd propose that for both sync and > async subscriptions, the *confirmation* (i.e., that the callback URL > is valid) should proceed, and that either 204 or 202 be returned to > Sally immediately. Asynchronously, the hub.mode=authorize should be > sent to the URL specified in the feed's <link rel='authorization'> in > order to notify Tom that he has a new subscription request. > Furthermore, I think an extra step of redirection is needed, wherein > the authorization response can be treated asynchronously, so that > Tom's blogging software can say to the hub: "I've received your > request to allow [[sally's callback URL]] to subscribe to [[tom's > feed]], but I don't know the answer yet", and later send the hub a > callback that says "that subscription is (approved/denied)."[1] > > When Tom gets back and approves or denies the request, it may be ideal > for his hub to notify Sally's callback URL with this information, so > that Sally doesn't have to keep trying in order to know whether or not > Tom has denied her request, or if he just hasn't been publishing > anything. > > I think there are a few gaps (i.e., beyond the callback URL, how does > Tom know who's asking?) for which I have some possible answers[2], but > I'd like to hear others' thoughts on this (especially Brett's and > Brad's). Julien, in particular, can you think of any problems with the > hub returning 202/204 to the subscription request, but then later > rejecting the subscription if authorization is denied? > > b. > > 1. Yes, I realize how close this is to symmetric hubs; I'm not sure > it's the same thing, but one step at a time. > 2. 9 letters, begins with 'w', ends with 'r' > > 2010/1/21 Julien <[email protected]>: > > Here is another example of the use of this "publisher callback". > > > > We host a hub for Tumblr. When a client (say friendfeed) reads a > > tumblr feed, it finds that the feed is managed by Superfeedr. It then > > logically subscribes to Superfeedr to get it feed. We need to make > > sure that this feed is managed by us (in other words, that Tumblr will > > ping us for it). Up until now we checked the domain. That's not > > enough... because Tumblr allows its users to use their own custom > > domain. The callback could be used for that : the publisher can easily > > say whether the feed is "legit" or not. (Checking the inclusion of the > > hub <link> is obviously not enough because anybody could add that to > > their feeds...) > > > > > > On Jan 20, 4:15 pm, Julien Genestoux <[email protected]> > > wrote: > >> Alright, thanks for the awesome feedback! Let me try to reply to all 3 > >> comments without someone else jumping in the discussion :) > >> > >> On Wed, Jan 20, 2010 at 2:02 PM, Alexis Richardson < > >> > >> [email protected]> wrote: > >> > Julien > >> > >> > First, thank-you and well done for writing this down. > >> > >> > Second, this type of behaviour is quite common in things like > >> > financial services market data feeds. Often in such cases, a > >> > middlebox or middleman takes responsibility for what would ideally by > >> > an end-end relationship between producer and consumer, but which for > >> > some business reason is brokered. > >> > >> > Third, I agree with Bob's comments. > >> > >> > I also feel this potentially complicates the spec and subscription > >> > process for just one particular use case. > >> > >> Well, maybe I should have emphasize much on that in my writting, but > it's > >> really an extension because I expect to not change the behavior of hubs > and > >> subscribers who have not implemented it. > >> > >> > In an ideal world, a > >> > publisher who wanted to know who was subscribed via PSHB, could just > >> > set up and run their own hub. > >> > >> Well, yes, and no... publishing and broadcasting are 2 different jobs > I'd > >> day. Even though you read the guardian every day, it's not a guardian > >> employee who sells it to you. I'm not sure this is a good analogy > analogy > >> but I think that the hubs' job is pretty clear : gather the list of > >> subscriber and send them content, whatever that is. I think publishers > >> should not necessarily do that job. > >> > >> > But let's say that they cannot or will > >> > not do that for some reason. Instead they might run a private hub, > >> > but delegate its hosting and management to a middleman service. Enter > >> > superfeedr as a suitable such provider. But if superfeedr is acting > >> > on behalf of a publisher in this way, then why can't the mechanisms > >> > for sharing subscription data and auth lists with that publisher also > >> > be private? > >> > >> Because the decision involved on whether who should subscribe or not has > to > >> be "obscure" for the hub. For me the hub should ignore the data, as much > as > >> it should ignore the reasons why somebody would subscribe and why > somebody > >> would publish. By delegating the decision to the publisher, then, each > >> publihser can enforce his own policy. > >> > >> > What is the benefit of including it in the spec? > >> > >> > I'd rather see hubs being able to turn down subscriptions for any > >> > reason they like, and possibly silently. > >> > >> > Please note that the above is not a strongly held view ;-) I am keen > >> > to understand more about what you are proposing. But at this stage I > >> > think this should either unspecified, or (perhaps?) be spelt out even > >> > more strongly and thought about in relation to authentication and > >> > discovery in general. > >> > >> Another example would be NYT's recent move toward "paid" content. They > might > >> want to say : hey we want a hub, we don't want to make the list of > >> subscription public and yet, we only want paying services to access it. > I > >> think the publisher callback works quite well in that case. > >> > >> > alexis > >> > >> On Wed, Jan 20, 2010 at 3:02 PM, Pádraic Brady <[email protected] > > > >> > >> wrote: > >> > Hi Julien, > >> > >> > Having thought about I had a few conclusions. Being an implementor > (loves > >> > me code ;)), it would certainly be simple to do so no complaints > there. I > >> > was curious how you saw this operating in a synchronous mode of > subscription > >> > - the more indirect requests needed, the longer we're keeping > Subscribers > >> > waiting. I'm particularly sensitive to us engaging in transactions > which > >> > will start hitting bottlenecks like PHP's maximum execution time limit > (let > >> > alone whatever the locally set HTTP timeout is). I nearly always > favour > >> > async mode (where possible) but most Subscribers I suspect won't want > the > >> > added complexity and will prefer synchronous. > >> > >> To be, this is the weakest point : adding one more query may slow the > >> process even more. I have no solution to it, except maybe just accept > it. > >> Obviously both requests (to verify the intent and to verify the > >> authorization) could be done in parallel, but that would bear the risk > of > >> inconsistency for the publisher who might allow an unconfirmed > subscription. > >> > >> > >> > >> > The privacy issues I really don't see. Use of any technology is always > >> > subject to the client exposing something of their identity. The > exposure of > >> > certain details like their callback URL doesn't seem to be much of an > issue. > >> > By definition it's already publicly exposed so what else is there to > keep > >> > private? We're not looking for Joe Doe's name, address and credit card > >> > details ;). Why don't we apply this same principle to Hubs? Aren't > >> > Subscribers handing them private information in this case already?? > >> > >> Agree with all that : there is no privacy issue for me. If publishers > are > >> willing to push their content into the wild, I think it's a valid > concern > >> that people who subscribed accept to be seen as subscribers. When you > poll > >> : you can't hide. It should be the same for pushed content. > >> > >> At the end of the day, I really think this has a huge amount of > potential > >> > >> > with is underplayed by its very modest intent. I think that's the main > weak > >> > spot of the proposal - it's very specific ;). Then again, its specific > >> > nature is what makes it simple to grasp and implement. For myself, I > would > >> > definitely like to see Publishers being able to get some kind of > feedback in > >> > real-time in this vein. It may not be foolproof but on a personal > note, I > >> > already have some funky programming tampering with my feeds so certain > IPs > >> > get a feed full of copyright infringement messages instead of my > actual > >> > content. Surely a modest blogger like me can't be the only one plagued > by > >> > content stealing. > >> > >> ... > >> > >> > >> > >> > There is absolutely no reason why we should be linking the nature of > feeds > >> > to the nature of Pubsubhubbub - they may be marginally related but > both > >> > offer two very different distribution methods that merely share a > common > >> > distributable format. It seems quite acceptable that Publishers have > the > >> > right to impose additional restrictions. They can already do it to > some > >> > extent with feeds, but real-time data and interactions with a Hub > offers a > >> > far richer environment to work within. > >> > >> I agree with all that! > >> > >> Paddy > >> > >> Pádraic Brady > >> > >> http://blog.astrumfutura.comhttp://www.survivethedeepend.com > >> OpenID Europe Foundation Irish Representative < > http://www.openideurope.eu/> > >> > >> On Wed, Jan 20, 2010 at 3:27 PM, Alex Barth <[email protected]> wrote: > >> > The draft spec doesn't account for a change in policy. How would a > >> > publisher pull access for a subscriber that seemed harmless at the > >> > point of subscription but turned out to be malicious later? Depending > >> > on the subscription renewal policy there would be at least a > >> > considerable time span where a subscriber would still receive > >> > notifications. Is this time span neglectable? > >> > >> That's a valid concern and when thinking about it, I thought we could > >> explictly specify in the extension that if a hub accepts a subscription > then > >> it's accepted for its whole span. Obviously, one requirement from a > >> publisher would be to have limited lease... If they want to ban > somebody, > >> they can refuse subsequent queries... and eventually all the > susbcriptions > >> will be refused. > >> > >> > In my mind the core of the problem is that fat pings aren't good when > >> > you need to worry who's subscribing. > >> > >> > I am currently using pubsubhubbub for protected feeds. I took the > >> > liberty in my implementation to support a 'light ping' that forces the > >> > subscriber to fetch the feed from the original source - authenticated, > >> > over a secure connection. This allows me to distinguish between > >> > subscribers and - if necessary - disallow access on a granular level. > >> > A very useful feature for feeds of paid content or in my case - feeds > >> > of user credentials in a federated system of sites. > >> > >> That would work, yes. Except that some publishers want both fat pings > and > >> visibility. I think Dave Winer's move a few weeks ago came after he had > a > >> chat with Tumblr and Tumblr's hub is at Superfeedr. > >> > >> > Correct me if we're talking about *completely* different things here. > >> > >> Nope, related... > >> > >> > >> > >> > >> > >> > Alex > > > -- Jeff Lindsay http://webhooks.org -- Make the web more programmable http://shdh.org -- A party for hackers and thinkers http://tigdb.com -- Discover indie games http://progrium.com -- More interesting things
