Unfortunately, not schedulable as far as I know, the notification needs to be sent while the web worker is running. Again, I'd very much love be wrong about that, but I don't think there is any way for, just as an example, a habit tracking PWA to say "ask the user at 10:00AM every day if they've gone for a morning bike ride."

But you can get that behavior... if you set a web server and force the user to make an account and then log all of their habits in your server and then send out the notification yourself. Because... it's unfair for me to blame Google in this instance, I don't know it's their fault, but I do blame Google and I suspect it's their fault. I could be wrong though.

I don't know how fine grained you want your notifications to be, but you can get pretty far without storing user data by splitting notifications by topic on the queue, or by filtering client-side in the service worker itself.

But even then, the UX seems pretty bad; when I first created an app with web push, a few years ago, there was zero guarantee that notifications would ever show up, and they seemed to fall through very often, when the client (at least with Firefox Android) sits in the background; https://stackoverflow.com/q/60809681

i can't tell if the situation has improved recently -- anecdotally it seems like it's a bit better now -- but depending on what sort of notifications you want to push, that quickly becomes a complete showstopper.

> there was zero guarantee that notifications would ever show up, and they seemed to fall through very often, when the client (at least with Firefox Android) sits in the background

That could also be a longer conversation, but yeah, that was also my conclusion, and again... I don't have proof that this is Google's fault, but it stands out to me that notifications as they're built today are primarily useful for spammy advertisements and engagement requests and are extremely unreliable for everything else.

If your primary use case for notifications is telling the user that your blog published a new article or reminding them to check into their account or advertising a sale, then notifications are great; and you don't really care about reliability in that instance.

If you want notifications to be something the user can really rely on, ie calendar appointments, sign-in attempts, etc... they don't seem like they're trustworthy enough to do that.

Of course, we need those OS-level restrictions around notifications to stop abuse and spam, but that's only because it's super-easy to start spamming the user in the first place. And my pet conspiracy theory is that Google on some level looked at notifications and said "it's more important that it be easy for a blog to get somebody to click yes on this, than it is for us to build a transparent process to the user that would allow us to make the delivery more granular and more reliable." Instead of making it harder for websites to get notifications permissions in the first place, Google made them less reliable; the model is that you will have a bunch of sites that can spam you but they'll spam you unreliably.

Again, I can't prove that, and maybe things have improved, but it's just weird how the entire spec seems designed around advertisements/spam, even to the detriment of everything else.

You don't need an account and you can encrypt the message before queuing it on the server. Silly stupidity inefficient and won't work offline but it is quite easy to make a generic push message scheduling server that just pushes around blobs as requested by client-side code.

That's an interesting point. It's still pretty messy and inefficient, but you're right, you could at least get away with not exposing user data, even if you're still transmitting it around.

That's a good suggestion, I should play around with that some time.