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

[Martin Thomson <[e-mail]>]

The question here for me is how much a protocol can enable this and
how much is best left to services like Notification Hubs, etc...
Those services are offered to those who wish to generate push messages
and as such are less encumbered by a need for standardization.  In
fact, much of their value-add derives from the flexibility and
expressiveness of their APIs. They benefit from standardization of a
push protocol in that their downstream interactions become
homogeneous, but a standard for aggregation might only act as a
constraint.

The intent with the aggregation draft I described was to allow a
single push service provider to provide aggregation capabilities
across its endpoints.  That leaves open the possibility of an
aggregator that operates across multiple push services (like the
aforementioned),  It's hard to see how that could be driven from
anything but the application side, where standards are less urgent.

At this stage, my proposal seems more like a half-measure, and I'm
reconsidering whether there is anything worth standardizing on the
aggregation front.  Do you think that there is something here worth
pursuing?

Either way, I think that our efforts are best concentrated on
completing the basic protocol first.


On 25 February 2015 at 08:00, Elio Damaggio <[e-mail]> wrote:
> Hi Martin,
>
> Continuing the discussion on broadcast, from our experience of designing and operating Azure Notification Hubs, we realized that the major hurdles for users of a push aggregation system are the following:
>
> 1.      Push aggregation have to be regularly synched with other data stores.
> Aggregation sets are application data, e.g. list of people in "platinum" status, list of users following a certain sport team, enterprise or social groups. The protocol has to be amenable to synching operations. In our experience forcing explicit management of the topics (creation and deletion) hampers these operations compared to more flexible approaches where tags are associated to device tokens. Azure Notification Hubs is not the only system that uses this kind of grouping; Urban Airship and Parse (now Facebook) have a similar systems. Reference: https://msdn.microsoft.com/en-us/library/dn530749.aspx.
>
> 2.      Topic updates happen from both device and topic perspectives.
> This means that it should be possible to say "add/remove topics A,B, and C to this user", and also "add/remove users 1,2, and 3 to/from this topic". In a system where both of this kind of updates happen concurrently, having to explicitly keep track of topic creation and deletion is burdensome.
>
> 3.      Sending to dynamic sets.
> Given the effort that goes into synching topics between the push system and other stores, it is usually preferable for both the users and the implementer of the push aggregation system to allow Boolean expressions on topics to be used as targets. Consider a sports application that sends a reminder to everyone in Boston about a game between the Red Sox and Cardinals. If the client app registers tags about interest in teams and location, then the notification should be targeted to everyone in Boston who is interested in either the Red Sox or the Cardinals. This condition can be expressed with the following Boolean expression: (follows_RedSox || follows_Cardinals) && location_Boston
>
> Notification Hubs, Urban Airship and Parse all support this feature. Even if this feature is not required to be implemented in all aggregation servers, it follows that a push endpoint, that is independent of a specific topic and that takes a target topic (or Boolean expression on topics), is probably better suited than a topic-specific push URL.
>
> Elio
>
> -----Original Message-----
> From: Webpush [mailto:[e-mail]] On Behalf Of Martin Thomson
> Sent: Thursday, February 12, 2015 8:41 PM
> To: Benjamin Bangert
> Cc: [e-mail]
> Subject: [Webpush] Broadcast (was Re: webpush for http2 -02)
>
> 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?
>
> _______________________________________________
> Webpush mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webpush