3 ms·

Apple routes all of them. Company sends message to Apple. Apple sends the message to your phone. App on phone delivers the message to you.

DeathArrow 3y ago
> Apple sends the message to your phone. The "send" part I understand. What I don't understand is the "store" part. And is the Apple's routing even needed? Web push notification don't need Apple, Google, Microsoft or Ubuntu between the web app and you. Can't app push notifications work in the same way?
- ben-schaaf 3y ago
  Web Push uses a browser provided "push-service", so if you're using the push API your notifications are already going through Apple.
- kyelewis 3y ago
  Web push notifications do need and use Apple, Google… between the web app and you.
- jasode 3y ago
  >Web push notification don't need Apple, Google, Microsoft or Ubuntu between the web app and you. They do. To implement "web push", each web browser vendor has their own backend server to handle notification subscriptions[1][2]. - Mozilla Firefox uses their server at "push.services.mozilla.com" - Google Chrome uses their server "fcm.googleapis.com" - Apple Safari uses "api.push.apple.com" - MS Edge uses their Windows Notification API server [1] https://stackoverflow.com/questions/53169001/web-push-do-they-use-public-servers-like-google-etc/53378967#53378967 https://stackoverflow.com/questions/53169001/web-push-do-the... [2] https://stackoverflow.com/questions/48683770/how-are-web-push-messages-delivered/48684217#48684217 https://stackoverflow.com/questions/48683770/how-are-web-pus... [3] https://news.ycombinator.com/item?id=38430226 https://news.ycombinator.com/item?id=38430226 The web push architecture requiring middleman servers in between the website and the browser is similar to native iOS apps requiring the APNS server (Apple Push Notification Server): [4] https://stackoverflow.com/questions/17262511/how-do-ios-push-notifications-work/30617904#30617904 https://stackoverflow.com/questions/17262511/how-do-ios-push...
- rollcat 3y ago
  It's a trade-off. If the device is not able to receive the notification at the time it was sent out, it has to be stored somewhere, pending delivery. It's the same with email, SMS, literally every messenger app, heck it's the same with physical parcels! You could argue the protocol should allow the sender to store the message, to allow the receiver to fetch it directly, without a middleman - and this is more or less what RSS is, except the polling architecture causes both extra latency and increased server load. But we could "fix" RSS by eliminating polling, etc - that's an easy engineering problem, the true issue would be standards/consensus. Finally, since we're talking mobile devices, you must consider battery usage. It's cheaper to keep only a single TCP connection open; this path is heavily optimized at every layer of the stack, from network hardware and drivers to the app-facing API. Notably, email notifications have to go through their own network path (there's a couple of IMAP extensions to enable push), this is part of the reason why some email apps would like to look at your email from the POV of their own hosted backend. These choices reflect the fundamental problems of mobile messaging. But we could still improve upon the status quo - like requiring E2EE for notification payload. That would be a huge effort though, as an app vendor you already need to implement APNS/FCM/Web (all very different from one another), and I'm sure every middleman would like to build their encryption slightly differently. Adoption would be slow and painful.
  - jasode 3y ago
    >, it has to be stored somewhere, pending delivery. I think the "stored?" question isn't about the minimal fraction of time notifications have to be in transient storage to even "send and immediately forget". Yes, a transitory "message queue pub/sub" architecture still needs to have some notion of "storage" to work. Instead, "stored?" is wondering about a company's discretionary and optional retention period after the successful notification delivery that isn't required by law. E.g. 30 days?, or 1 year?, or longer? ... such that those archive records of past notifications have become targets for court subpoenas and law enforcement information requests. If Apple doesn't "store" notifications in this sense, there's nothing to "hand over".

DeathArrow 3y ago

> Apple sends the message to your phone. The "send" part I understand. What I don't understand is the "store" part. And is the Apple's routing even needed? Web push notification don't need Apple, Google, Microsoft or Ubuntu between the web app and you. Can't app push notifications work in the same way?

ben-schaaf 3y ago
Web Push uses a browser provided "push-service", so if you're using the push API your notifications are already going through Apple.
kyelewis 3y ago
Web push notifications do need and use Apple, Google… between the web app and you.
jasode 3y ago
>Web push notification don't need Apple, Google, Microsoft or Ubuntu between the web app and you. They do. To implement "web push", each web browser vendor has their own backend server to handle notification subscriptions[1][2]. - Mozilla Firefox uses their server at "push.services.mozilla.com" - Google Chrome uses their server "fcm.googleapis.com" - Apple Safari uses "api.push.apple.com" - MS Edge uses their Windows Notification API server [1] https://stackoverflow.com/questions/53169001/web-push-do-they-use-public-servers-like-google-etc/53378967#53378967 https://stackoverflow.com/questions/53169001/web-push-do-the... [2] https://stackoverflow.com/questions/48683770/how-are-web-push-messages-delivered/48684217#48684217 https://stackoverflow.com/questions/48683770/how-are-web-pus... [3] https://news.ycombinator.com/item?id=38430226 https://news.ycombinator.com/item?id=38430226 The web push architecture requiring middleman servers in between the website and the browser is similar to native iOS apps requiring the APNS server (Apple Push Notification Server): [4] https://stackoverflow.com/questions/17262511/how-do-ios-push-notifications-work/30617904#30617904 https://stackoverflow.com/questions/17262511/how-do-ios-push...
rollcat 3y ago
It's a trade-off. If the device is not able to receive the notification at the time it was sent out, it has to be stored somewhere, pending delivery. It's the same with email, SMS, literally every messenger app, heck it's the same with physical parcels! You could argue the protocol should allow the sender to store the message, to allow the receiver to fetch it directly, without a middleman - and this is more or less what RSS is, except the polling architecture causes both extra latency and increased server load. But we could "fix" RSS by eliminating polling, etc - that's an easy engineering problem, the true issue would be standards/consensus. Finally, since we're talking mobile devices, you must consider battery usage. It's cheaper to keep only a single TCP connection open; this path is heavily optimized at every layer of the stack, from network hardware and drivers to the app-facing API. Notably, email notifications have to go through their own network path (there's a couple of IMAP extensions to enable push), this is part of the reason why some email apps would like to look at your email from the POV of their own hosted backend. These choices reflect the fundamental problems of mobile messaging. But we could still improve upon the status quo - like requiring E2EE for notification payload. That would be a huge effort though, as an app vendor you already need to implement APNS/FCM/Web (all very different from one another), and I'm sure every middleman would like to build their encryption slightly differently. Adoption would be slow and painful.
- jasode 3y ago
  >, it has to be stored somewhere, pending delivery. I think the "stored?" question isn't about the minimal fraction of time notifications have to be in transient storage to even "send and immediately forget". Yes, a transitory "message queue pub/sub" architecture still needs to have some notion of "storage" to work. Instead, "stored?" is wondering about a company's discretionary and optional retention period after the successful notification delivery that isn't required by law. E.g. 30 days?, or 1 year?, or longer? ... such that those archive records of past notifications have become targets for court subpoenas and law enforcement information requests. If Apple doesn't "store" notifications in this sense, there's nothing to "hand over".