← Notes

What push guarantees, and what it leaves to the human

The Push API spec solves the technical problem of reaching the device with the app closed; the problem of someone seeing it and acting in time remains entirely on the other side.

The Push API documentation describes exactly what the mechanism buys: "The Push API gives web applications the ability to receive messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent".

It is a strong and narrow guarantee. It covers the stretch between the server and the device, and stops exactly there. What happens afterwards — a screen lighting up in the pocket of someone in a meeting, driving, asleep or with the phone on silent — is not a problem the specification sets out to solve, because it is not a software problem.

Multiplying channels improves the chance the message is seen, which is why firing through several paths at once makes sense. But the channels share the same recipient. Three notifications to an unavailable person are still zero service, and channel redundancy can even produce a sense of robustness the operation does not have.

The practical conclusion is about where to spend the next hour of work. If the notifications already arrive, the bottleneck has stopped being delivery, and one more channel moves nothing. What moves it is what exists on the human side: who is on call, in what window, and what the system does when the answer is nobody.