[Webpush] Message payload format

[Peter Beverloo <[e-mail]>]

Hi Martin,

On Thu, May 15, 2014 at 5:16 PM, Martin Thomson <[e-mail]>
 wrote:
>
> >     * Definition of the payload itself.
> >
> > This seems to be missing in the draft. I assume we’ll work on this later?
> > :-).
>
> Doug asked about it too.
>
> That was entirely intentional.  The payload is defined.  It's whatever
> you can put in an HTTP PUT.


I see. I understand that by consolidating the Push registration Id and the
endpoint, as the Web Push API currently describes, the developer would be
able to utilize the entirety of the HTTP PUT request body for the data
payload.

There are a few reasons why I don't think this is a good idea.

    (1) It requires a push message to have a 1:1 relationship with a
specific channel.

This is sufficient for many instant messages use-cases, but presents a
limitation for broadcasting (1:N relationships) use-cases.

To name two examples, in the instant message situation a message might be
directed to a group of people. For a news service, an important article
will be sent to a series of users, not just individuals. Sending individual
HTTP requests for each of them introduces a large amount of overhead.

You mention that it compromises end-to-end security, I would like to
understand what you are thinking of exactly. It is true that the developer
loses the ability to use per-user encryption keys when multicasting a
message, but unless the draft enforces payload encryption this seems like a
trade-off which the developer should make.

    (2) It limits the ability to specify advanced options.

GCM supports various advanced options, which have gained a lot of traction
from developers. To name a few notable examples of our features:

collapse_key - override previous messages to a channel having the
same collapse_key.
time_to_live - timeout before which the message should be delivered, before
it will be dropped.
delay_while_idle - postpone delivery of a message until the user wakes up
their device.

Given the traction these features have, I would propose including options
in the protocol. These could be specified in the query string of the PUT
request, but this doesn't scale very well, especially when considering the
1:N relationships.

As such, what would your opinion be on using a minimalistic JSON syntax?

{
    "recipients": "..", // 1:1
    "recipients": ["..", ".."], // 1:N

    "data": ..., // an object or an opaque string.

    "delay_while_idle": 1, // optional options.
}

We can consider standardizing smaller satellite specifications to describe
the available options, and the basic behavior to expect from them.

Thanks,
Peter