Broadcast, Multi-Cast, or Topic messages via the Push API

[RichardMaher]

When/how with pushManager.subscribe() support the above?

GCM has the following: -
https://developers.google.com/cloud-messaging/topic-messaging#sending_topic_messages_from_the_server

I foresee many such messages (eg: stock price, eBay bid) prefer to arrive sans notification

[beverloo]

The Push API assumes use of the Web Push Protocol, which doesn't support these features yet either. There is some interest in enabling 1:M messaging, but mandatory encryption of payloads makes it challenging to support this for anything other than tickles.

The requirement to display a notification is a decision by some user agent (e.g. Chrome) and has no foot in the specification other than the userVisibleOnly option. Other than that, your examples actually seem like cases where you would want to show a notification.

[RichardMaher]

Hi Peter, Thanks for the reply. (I lived in Richmond and contracted in London for 10 years till 2005. Miss the pubs!)

The Push API assumes use of the Web Push Protocol, which doesn't support these features yet either.

I guess that's what I'm asking about. Who's working on V2 of the spec? 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. Can it? We don't need a new wheel just one that fits our axle.

but mandatory encryption of payloads makes it challenging to support this for anything other than tickles.

I agree. Why is it mandatory? Because we don't trust the Messaging vendor which is the same as out browser vendor? Some stuff has to be encrypted for sure but a published,broadcast,generic,context-devoid payload can surely go in the clear? But once again, how does the Java API handle it? For HTTPS can we not just rule-out CORS and use a server-hosted public key?

your examples actually seem like cases where you would want to show a notification

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?

[beverloo]

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.

[RichardMaher]

Thanks Peter!

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.

No worries mate. "Apropos" is my middle name!

[beverloo]

Let me close this issue as it's out of scope of this specification.