4 ms·

> They sound like they have the capabilities you need I'm curious about what sounds so endearing about them to app developers. I wrote a WebPush scheduler once

> They sound like they have the capabilities you need I'm curious about what sounds so endearing about them to app developers. I wrote a WebPush scheduler once that implemented the VAPID protocol. Along the road I came across a myriad of resources that hinted at the fact that it's a heavily restricted feature, due to the fact that browser vendors know it's mostly abused for spam. I kinda figured you wouldn't implement them unless you're forced to explore any avenue for engagement.

michaelt 3y ago
Theoretically you might use them for a calendar app reminding people of upcoming appointments, a video call app receiving a call, or things along those lines. Of course we all know that in reality, 99.9% of usage is engagement spam.
- josephg 3y ago
  Yeah. I don’t know why browsers have them enabled by default. Banning web notifications in my browser is one of the first things I do whenever I set up a new machine. I don’t want every second shitty news site to show browser dialogs asking if the site can spam me, even when I’m not on the page. What a horrible experience and a horrible feature.
- modeless 3y ago
  What I'm saying is it's literally not possible to use them for a calendar app or a video calling app or anything along those lines. People simply won't get the notifications until ten minutes after the person called or the calendar event started. (No, it's not consistently 10 minutes, it's random, and can be several hours in the worst case, so you can't schedule the notification earlier to compensate in the calendar case). If these things were possible then maybe people would see the benefit of web push. But spam is the only possible application right now, so spam is all you see. It's really unfortunate because there are many other legitimate uses that should be possible...
  - danShumway 3y ago
    Let me add to this, they're also not possible to use without a serverside component. Using them for a calendar should be possible without a server, you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. I agree with this, Google made a system that's only good for spam, refuses to fix it or expand on it, and as a result everyone hates it.
    - jessehattabaugh 3y ago
      > you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. This isn't entirely true; WebPush is server only, but the Notification API can be used locally. You could schedule a timeout that causes a notification, as long as the page stays open, and to do it while the page is closed you could use a ServiceWorker. Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user.
      - modeless 3y ago
        ServiceWorkers are subject to the same delay issues. In fact the ServiceWorker requirement is the whole reason for the issue in the first place: receiving a Web Push notification requires running a ServiceWorker and Android won't let it run in the background except at certain times. IMO the fix is to change the Web Push API so that you can send (or schedule ahead of time) notifications that can be displayed without activating the ServiceWorker. Alternative solutions would be for Android to relax the restrictions that prevent ServiceWorkers from running, or for Chrome to try to fit ServiceWorkers into the existing restrictions somehow. But for some reason Google refuses to try any of these, and so Web Push rots.
      - danShumway 3y ago
        > but the Notification API can be used locally The problem is that the notification API is next to useless. If I remember correctly, the uselessness of the notification API was one of the driving forces behind devs being so excited about web push. Finally we have a way to send notifications when the app is closed. Except... no, not really, because Google messed up that too. I don't understand why it's so complicated to be able to just schedule a notification to go off at a specific time the same way that native notifications work, but apparently Google thinks that would be a horrible overreach of the web. Now Bluetooth and MIDI access on the other hand, they're fine with that. Google thinks that stuff is very good to have the web. Just don't let the user set alarms, that would be dangerous. /s Snark aside, the short response is that I don't think this counts as "scheduling" -- scheduling is not "leave a process active and then manually fire the notification once you've personally checked that it needs to fire. And I have seen people try to get this working using background sync, push notifications, all kinds of nonsense. It's just bad design that people are even attempting to figure out those kinds of tricks. This is the kind of weird design that only makes sense when you remember that it came out of an advertising company. > Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user. The key difference is that if a user disables native notifications, it's because they want to. If a service worker closes, it's for some opaque reason that the user may not even be aware of. It's not user-controlled. User-controllable permissions are great. Android-controlled permissions that are opaque to the user and can't be overrided even for critical apps like alarms are less good. Also, it's just wildly inefficient and clunky -- what we want out of notifications is not to run a background process, it's to schedule an event to happen at a specific time and to let the OS handle it. I don't want to be running code to make an alarm trigger, I want to update an event queue. Maybe I want the ability to run code in response to an event, but even that is less important than being able to say "please show the user this piece of text at 5:45 and give them a link to open the PWA." Regardless, I shouldn't need a running service worker to tell the phone OS that in 30 minutes a notification should pop up. ---- What should happen is you schedule a notification with text and a timestamp, you get an ID back and put it in local storage, a UI is surfaced to the user by the OS that allows them to view notification access and upcoming notifications and set limits, and the app can use the returned ID if it's activated or syncing to edit the notification or remove it before it fires. And ideally web push notifications would hook into that API. Maybe provide a way to respond to events or run code in response to the notification if you want to get fancy. That would be the sensible, human way to design a notifications API if we were optimizing for user control, privacy, reliability, and developer ease of use instead of optimizing almost entirely for advertising and spamming people. At the very least you'd think users should have permissions and control over how notifications work instead of the phone just silently messing with things. Absolutely ludicrous that we've made an API that's so unreliable that it can't be used for timers, but also that doesn't have enough control to allow me as a user to filter notifications that apps send.
afavour 3y ago
I’m not sure why Web Push is often singled out for this criticism, the same goes for app notifications. I’ve never actually gone down the road of creating one but in theory you could make an almost entirely decentralized peer to peer messaging service with a PWA implementing the Web Push API to exchange messages. I agree that sadly most of the use cases are spammy nonsense but it remains an interesting API to me.

michaelt 3y ago

Theoretically you might use them for a calendar app reminding people of upcoming appointments, a video call app receiving a call, or things along those lines. Of course we all know that in reality, 99.9% of usage is engagement spam.

josephg 3y ago
Yeah. I don’t know why browsers have them enabled by default. Banning web notifications in my browser is one of the first things I do whenever I set up a new machine. I don’t want every second shitty news site to show browser dialogs asking if the site can spam me, even when I’m not on the page. What a horrible experience and a horrible feature.
modeless 3y ago
What I'm saying is it's literally not possible to use them for a calendar app or a video calling app or anything along those lines. People simply won't get the notifications until ten minutes after the person called or the calendar event started. (No, it's not consistently 10 minutes, it's random, and can be several hours in the worst case, so you can't schedule the notification earlier to compensate in the calendar case). If these things were possible then maybe people would see the benefit of web push. But spam is the only possible application right now, so spam is all you see. It's really unfortunate because there are many other legitimate uses that should be possible...
- danShumway 3y ago
  Let me add to this, they're also not possible to use without a serverside component. Using them for a calendar should be possible without a server, you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. I agree with this, Google made a system that's only good for spam, refuses to fix it or expand on it, and as a result everyone hates it.
  - jessehattabaugh 3y ago
    > you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. This isn't entirely true; WebPush is server only, but the Notification API can be used locally. You could schedule a timeout that causes a notification, as long as the page stays open, and to do it while the page is closed you could use a ServiceWorker. Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user.
    - modeless 3y ago
      ServiceWorkers are subject to the same delay issues. In fact the ServiceWorker requirement is the whole reason for the issue in the first place: receiving a Web Push notification requires running a ServiceWorker and Android won't let it run in the background except at certain times. IMO the fix is to change the Web Push API so that you can send (or schedule ahead of time) notifications that can be displayed without activating the ServiceWorker. Alternative solutions would be for Android to relax the restrictions that prevent ServiceWorkers from running, or for Chrome to try to fit ServiceWorkers into the existing restrictions somehow. But for some reason Google refuses to try any of these, and so Web Push rots.
    - danShumway 3y ago
      > but the Notification API can be used locally The problem is that the notification API is next to useless. If I remember correctly, the uselessness of the notification API was one of the driving forces behind devs being so excited about web push. Finally we have a way to send notifications when the app is closed. Except... no, not really, because Google messed up that too. I don't understand why it's so complicated to be able to just schedule a notification to go off at a specific time the same way that native notifications work, but apparently Google thinks that would be a horrible overreach of the web. Now Bluetooth and MIDI access on the other hand, they're fine with that. Google thinks that stuff is very good to have the web. Just don't let the user set alarms, that would be dangerous. /s Snark aside, the short response is that I don't think this counts as "scheduling" -- scheduling is not "leave a process active and then manually fire the notification once you've personally checked that it needs to fire. And I have seen people try to get this working using background sync, push notifications, all kinds of nonsense. It's just bad design that people are even attempting to figure out those kinds of tricks. This is the kind of weird design that only makes sense when you remember that it came out of an advertising company. > Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user. The key difference is that if a user disables native notifications, it's because they want to. If a service worker closes, it's for some opaque reason that the user may not even be aware of. It's not user-controlled. User-controllable permissions are great. Android-controlled permissions that are opaque to the user and can't be overrided even for critical apps like alarms are less good. Also, it's just wildly inefficient and clunky -- what we want out of notifications is not to run a background process, it's to schedule an event to happen at a specific time and to let the OS handle it. I don't want to be running code to make an alarm trigger, I want to update an event queue. Maybe I want the ability to run code in response to an event, but even that is less important than being able to say "please show the user this piece of text at 5:45 and give them a link to open the PWA." Regardless, I shouldn't need a running service worker to tell the phone OS that in 30 minutes a notification should pop up. ---- What should happen is you schedule a notification with text and a timestamp, you get an ID back and put it in local storage, a UI is surfaced to the user by the OS that allows them to view notification access and upcoming notifications and set limits, and the app can use the returned ID if it's activated or syncing to edit the notification or remove it before it fires. And ideally web push notifications would hook into that API. Maybe provide a way to respond to events or run code in response to the notification if you want to get fancy. That would be the sensible, human way to design a notifications API if we were optimizing for user control, privacy, reliability, and developer ease of use instead of optimizing almost entirely for advertising and spamming people. At the very least you'd think users should have permissions and control over how notifications work instead of the phone just silently messing with things. Absolutely ludicrous that we've made an API that's so unreliable that it can't be used for timers, but also that doesn't have enough control to allow me as a user to filter notifications that apps send.

afavour 3y ago

I’m not sure why Web Push is often singled out for this criticism, the same goes for app notifications. I’ve never actually gone down the road of creating one but in theory you could make an almost entirely decentralized peer to peer messaging service with a PWA implementing the Web Push API to exchange messages. I agree that sadly most of the use cases are spammy nonsense but it remains an interesting API to me.