Re: Dialback in PubSubHubbub

Hey Evan,

So with the dialback idea, the hub know's the Webfinger/URI addresses of
all subscribers.

But how does the hub know the list of recipients of an update? Does the
publisher send that list to the hub together with the update?

Or is the idea that the hub is tightly coupled with the publisher and
therefore "knows" the recipient list of the update?

Markus
-- 
Project Danube: http://projectdanube.org
Personal Data Ecosystem Consortium: http://personaldataecosystem.org/

On Fri, Jun 22, 2012 at 9:42 PM, Evan Prodromou <evan@status.net> wrote:

>  Folks,
>
> One of the things we've talked about as being a weakness in the 0.3
> standard is the lack of limited distribution -- delivering certain updates
> to certain people.
>
> One possible solution to this problem is dialback verification at
> subscription time. As far as I know, Blaine Cook is the originator of this
> method, but I'm not sure it's been implemented or described in detail.
>
> I've written up the idea here:
>
> http://www.w3.org/community/pubsub/wiki/Dialback
>
> Here's the basic idea:
>
>    1. When making a subscription request, the subscriber passes an
>    additional parameter, "hub.from". This is either a Webfinger<http://en.wikipedia.org/wiki/Webfinger>address or an HTTP URI supporting
>    LRDD <http://tools.ietf.org/html/rfc6415>.
>    2. If the "hub.from" parameter is present, before verifying the intent
>    of the subscriber, the hub should discover the "pubsubhubbub-callback"
>    links for the hub.from account using Webfinger or LRDD.
>    3. If the hub.callback value is not one of the links that match the
>    response, the hub should halt and return an error.
>    4. If the hub.callback value is one of the links, the hub should
>    verify the subscriber's intent. It should include the hub.from value in the
>    parameters.
>    5. At content distribution time, the hub should deliver content to the
>    endpoints that the publisher has authorized.
>
> Some notes:
>
>    - This method presupposes that there is one user per callback URL.
>    There is no information in the content distribution payload that describes
>    the intended recipient.
>    - Although it's possible to define a different callback per
>    subscription, it would probably make the Webfinger document or LRDD
>    document prohibitively large. A user with tens of thousands of
>    subscriptions, each with its own callback URL, would be too large.
>    - Communicating authorization info between publisher and hub is left
>    undefined.
>    - With this mechanism, there will be exactly one HTTP call per
>    subscriber. There is no bundling of multiple subscribers in one payload.
>    - Blaine suggests using the "From:" HTTP header. A parameter is used
>    instead.
>
> I think this mechanism is simple enough to be included in the 0.4 spec
> as-is.
>
> -Evan
>
> --
> Evan Prodromou, CEO and Founder, StatusNet Inc.
> 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
> E: evan@status.net P: +1-514-554-3826
>
>