[Webpush] Broadcast (was Re: webpush for http2 -02)

[Martin Thomson <[e-mail]>]

On 13 February 2015 at 12:23, Benjamin Bangert <[e-mail]> wrote:
> Section 2:
> - The diagram is good, but I think adding one variant for broadcast messages
> would be good. I could see a crypto secured broadcast working like so:
>   - Broadcast Subscribe (In contrast to normal subscribe)
>   - Browser Agent makes Provide Subscription request to Application,
> including request (flag) to be issued the broadcast key
>   - Browser stores the broadcast key with the new subscription (rather than
> generating its own key)

I have proposed a separate document with a different model for
broadcast.  In that, clients/browsers/UAs don't drive the subscription
to a broadcast, that broadcast is managed by the application sender.
I got the sense that there wasn't a whole lot of interest in a
broadcast system in the initial stages.

The advantage there is that you don't have to worry about clients
having to be able to connect to push services that they might not have
a pre-existing relationship with (and therefore federate
authorization).  The disadvantage is that it drives more of the
responsibility for push fanout onto the application server.

In your proposal here, how do you see the broadcast subscription being
identified and managed?  Would an application request the creation of
one and then distribute it to its clients to subscribe to?