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
