Re: [w3c/push-api] userVisibleOnly should be standardized to match browser behaviour (#313)

the required `userVisibleOnly=true` is nothing but annoying. I do wish to use "silent" push to keep the client in sync with a 3-way-data binding and unsubscribe to changes when leaving the site. I also do not want to create an active open web socket connection as some cloud providers (like heroku, cloudflare workers and google cloud functions and others) wish to forcefully determinate the connection to save resources if the connection last more than 30s. Anything over that and you have to pay a higher fee/plan or resort to some wide scaled AWS solution to handle thousand of connections simultaneously that one server alone can't handle. Some server side solution also don't have web socket support as it's not event driven, like PHP

I would also like to do some p2p webrtc signaling between 2 peers that are online without having to spin up a websocket connection.

There is so much good stuff you can do with "silent" push but it is avoided b/c users have a tendency to block desktop notification.
ppl associate desktop notifications as something annoying as they are sometimes are prompted directly upon visiting a site without much context. It sometimes show ads, or sends out push notification too frequently of something that you aren't interested in or don't have fine graned control over

i also totally agree with @garygreen about syncing notification across devices as some messages can be marked as read and then being totally irrelevant. 

---

ppl can disobey  "must show a desktop notification"  as they are free to simply just update the site if it's visible to the user so it dose not need to show a desktop notification when the user is active on the site... `userVisibleOnly` do not provide any  guarantee that developer is going to show a desktop notification.

there is a useful feature to only allow sending silent push only when the user is active on the site cuz updates will only be happening on the site when users are online. and ppl don't wish to have to see that annying prompt dialog
I would be totally fine with a really hard penalty/qouta-limit and only be allowed to make some few amount of silent web push when the user isn't on the site and if it meant that i could avoid having to prompt the user for showing desktop notification...

i do not think web push should be associated with desktop notification. Since silent push is a total other ball game. 
`web push !== desktop notification` so i therefore do not think web push should require any special permission or prompting dialog. I do not think chrome no longer needs it's `userVisibleOnly` option any more as it already have a mean to limit quota/budget on silent web push. developer are going to want to request permission to desktop notification in order to keep sending web push while the user is "offline" 

I'm more okey with `await swReg.pushManager.subscribe()` throwing an error b/c you haven't requested permission to show desktop notification yet then it is to have to pass in a dum flag `userVisibleOnly: true` 

I really think it should be fleshed up into two different things. desktop notification should not have to anything with web push:es.

it should rather be a way for "desktop notification" to reset the amount of push:es you are allowed to send

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

Message ID: <w3c/push-api/issues/313/1166638986@github.com>