[Webpush] The Push Experience

[Benjamin Bangert <[e-mail]>]

This may not be entirely on-topic for the webpush ietf spec per-se,
but I know a lot of the right people are on this list, so I'm going to
throw this out here. If this was already proposed elsewhere, and
there's work proceeding on it, great, link me to it so we can choose a
version to support. :)

First, a little background.

Almost a month ago, Firefox 44 was released which included Push
support along with data payloads per the recent WebPush draft 02.
Since its release, we've seen some interesting uses of it, the least
of which was lots of dropped messages due to missing TTL headers which
the recent spec additions remedy.

The most glaring issue though, is some of the difficulty from early
adopters actually trying to use it. This shouldn't be too surprising,
because to provide a compelling Push experience, a developer must
understand and utilize at least 4 specs, possibly 5...

DOM API's

Notification API: https://notifications.spec.whatwg.org/
^^ There's also WebNotification API on W3C, how do developers ever
figure this out??

Service Worker API: https://www.w3.org/TR/service-workers/
Push API: https://www.w3.org/TR/push-api/


IETF
WebPush: https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/
    Dep, HTTP Encryption:
http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-00
VAPID: https://datatracker.ietf.org/doc/draft-thomson-webpush-vapid/
    Dep, JWT: http://tools.ietf.org/html/rfc7519

(Additional Dep. specs left out)

This is.... rather overwhelming to many web developers. Nevermind
trying to figure out what drafts of what specs each browser has
actually implemented. So far we have already seen libraries drop to
the lowest common denominator, which so far means we have not been
carrying data payloads even though Firefox supports it, because Chrome
does not.

This doesn't include how you ask for permissions for these things,
because technically the Notification permission is separate from the
Push permission, but afaik, both Chrome and Firefox will accept one of
them as both to reduce clutter. So you might have accepted
notifications without knowing you get push when the tab is closed,
though lots of users probably can't make that distinction..... ugh.
How these permissions are squashed, and for which browsers, appears to
be completely ignored by the docs I've seen. Do the doc writers even
realize browsers are squashing these permissions?

None of these specs speak to the user experience. Does the service
backing my browser allow 200 or 2000 notifications to be queued? Will
they all be shown? Do I want them to be? Does the browser implement
safeguards to prevent my screen from being flooded with these? Is
there a spec dictating the UX for how to handle 100 queued
notifications in a way that doesn't make the user immediately delete
the program (like the ask for permission spec)?

Even ignoring the above paragraph, which some could perhaps consider a
browser detail that should not be mandated (so we can all compete on
how compelling our notification spam management is), there's more
important questions for our developers. How do I code this in a way
that works on more than one browser given there's 4-5 API's at various
draft states implemented at different stages in each browser?

For that last question specifically, I'm proposing there a
meta-specification, perhaps called the Push Experience (I'm bad at
naming specs, no clever initials like VAPID), which essentially acts
as a global version pegging for the various spec dependencies needed
for a good Push experience.

I.e.

Push Experience Draft 1:
  - Notification API Draft N:
  - Service Worker API Draft Z:

  ....

This way it's clearly documented to a developer what the overall set
of available API's they can work with are, as a base minimum for each
browser. I'm not a spec-writer myself, so I don't even know what group
this belongs in.... whatwg? ietf? w3c? Technically it's a meta-spec
pegging specs from a variety of groups together to provide a cohesive
whole that a developer won't lose their mind over implementing. I'm
not sure there's much precedent for this, as I haven't heard of any
other emerging web tech's that involve so many specs in such a variety
of locations (back-end and front-end web dev).

I'd be happy to collaborate on this, or for some others to take over
this entirely, as I do believe having something like this is very
important to developers attempting to use Push. I'm not sure what the
appropriate venue for something of this nature to be, since it would
appear to tie together specs in at least 3 different spec groups.
Maybe it’s not a formal spec at all, but some other collaboration to
agree on minimum definitions for each phase, like the ACID 2 vs. ACID
3 browser tests so that a developer could easily see ‘How ready is my
browser for a Push Experience?’.

Thoughts?

Cheers,
Ben