Ok, but make the subscription request be a Salmon and get the benefit of verified (user) subscriber identity with a pointer to their Webfinger info. In many cases this would allow that request to be auto-handled based on rules (any friend can subscribe).
On Saturday, January 23, 2010, 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 p -- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer
