Re: [push-api] Broadcast, Multi-Cast, or Topic messages via the Push API (#188)

> Who's working on V2 of the spec?

The Web Push working group at the IETF. https://datatracker.ietf.org/wg/webpush/charter/

Please make sure that you familiarize yourself with the problem space before engaging in discussion there, as all of your questions have been previously discussed.

> Given all the messaging services that are up and running at the moment and broadcasting 1:M being a supported feature with "mature" APIs, it can't be too hard to bring the Javascript Push API up to speed.
> ...
> Why is it mandatory?

Existing users of push messaging talk to a defined set of push services— they choose which ones are supported, because they will have to amend their services to cater for the many proprietary push protocols out there.

This is different for the Push API. The UA gives you an `endpoint` to which you can talk using the Web Push Protocol. You don't have to care about the _who_ of the endpoint, it just works. This means that we have an unbounded set of possible intermediaries, not all of whom you may trust, which is by design.

> Because we don't trust the Messaging vendor which is the same as out browser vendor?

This is most definitely not always the case.

> Some stuff has to be encrypted for sure but a published,broadcast,generic,context-devoid payload can surely go in the clear?

Tickles probably could, but they have the significant downside that it needs a client-side request, which we've learned to be a frequent point of failure. Push services are very good at delivering messages.

> But once again, how does the Java API handle it?

By not requiring encryption.

> You want to annoy the user with a notification every time a stock-price changes? Or do you just want to change it on the screen?

Again, the restriction is not imposed by the specifications.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/188#issuecomment-197876261

Received on Thursday, 17 March 2016 13:20:41 UTC