But what is your email client using for notifications?
If it's using intermittent/timed fetch, that runs into the latency problem (taking longer to receive notifications). Push notifications exist to solve that problem.
If it's using IMAP's IDLE, MAPI's push, or JMAP's push, that's just another long-running HTTP or websocket connection.
And this protocol (along with the proprietary push notif aggregation services it is aiming to replace) exists to deduplicate those many long-running connections into a single connection out to some hardwired server that manages the many services/connections for it.
> But what is your email client using for notifications?
Local notifications?
I don't see the problem here with email, it seems to work well that it is great for my use case.
When you're offline with push notifications only the latest notification gets sent, not the previous notifications. This seems by design for notifications.
At least with E-mail I can see a history of emails that was sent to me.
I just see push notifications as a flawed concept that doesn't make sense for decentralised services.
I don't know what you mean by local notifications, but if you get a notification when a mail arrives, it's most probably because your mail client uses Google or Apple's push service if you use a regular mobile device, or if you installed and configured microG.
And here's your issue: your app that has nothing to do with Google relies on a centralised Google service, and depends on a proprietary library that speaks to some proprietary code running on your device.
Alternatively, your app isn't doing this, but then it risks being unreliable and stop notifying you if the system kills your app because it's been inactive for some time to save battery, or to reclaim memory, and/or it uses more battery than it could.
This post is not about a way to have more notifications: it is an answer to these issues.
> ... but if you get a notification when a mail arrives, it's most probably because your mail client uses Google or Apple's push service if you use a regular mobile device, or if you installed and configured microG.
Except it doesn't?
The Mail app on my iPhone doesn't use push notifications, fetch works well and I still get local notifications. No external push service at all.
> Alternatively, your app isn't doing this, but then it risks being unreliable and stop notifying you if the system kills your app because it's been inactive for some time to save battery, or to reclaim memory, and/or it uses more battery than it could.
You're saying a bunch of "issues" that never actually happened with me or anyone really, there is actually no issues here.
See how I introduced your case later with "Alternatively"? You saw it since you quoted me.
Fine, your email app works well in fetch mode. It took you three roundtrips to mention your actual setup despite having been asked about it quite early and despite it being a critical element in this discussion. Omitting to mention that doing this choice, your notifications are delayed.
Fetch mode is totally a valid choice, email doesn't need to be real time for every one. It will actually save battery life from what I can read: you don't need constant polling. Of course, push notifications are for real time stuff. What costs battery life or requires a push notification service on current widespread mobile devices is timely notifications. I can't help you if you fail to see how this can be useful, even if you don't personally need this or are against the idea.
Despite a thread that started well (yeah, notifications via emails, a decentralized, open standard, why not? It's terrible for many reasons including deliverability and the fact that you need to be notified of new mails so it's a bit of a chicken and egg issue, but sure, let's discuss), you don't seem actually curious or interested in the topic at hand, preferring to stick to your original point of view, to ignore the answers from all of us and to ultimately show contempt and spite to people discussing with you here. By the way, frankly, loose the scare quotes, they are ridiculous. Of course Apple Mail's fetch mode will be reliable on iOS but that doesn't make the topic trivially solved and yes, the problem exists despite what you are stating.
You are calling something over engineered without stopping to wonder why the complexity, assuming it's useless.
I mean, my point with E-mail is to say it already IS a solved problem.
Many services and apps use E-Mail so there is no need to setup additional infrastructure unlike push notifications. That is the complexity.
Send an email notifying me to test@example.com is more intuitive than setting up a push service.
Push notifications suffer from deliverability more frequently (regularly expiring tokens) than E-mail so much so, that when your device is offline and it gets back online, you only get the last notification. This is by design.
Having apps use fetch doesn't mean it's delayed, you can set it to a shorter duration but 5 minutes is the default.
But, it is over engineered as this is complexity that we do not need and would have a higher maintenance and setup than just using E-mail.
I think you are thinking about something different. So "Push Notifications" can refer to two different things.
The user oriented term refers to on-device notifications that pop up at the top of the screen. Those are technically just normal notifications but people like to call them push notifications for various reasons.
Push notifications in the technical sense however refer to a system for remote services to notify a client that something happened rather than the client manually polling the server for new updates. It's the difference between the client asking "do you have anything new" and the server telling the client "hey pay attention you have something new". This is what we are talking about when we say push notifications.
Email clients that automatically get new emails in the background all either do so using fetch polling or push notifications. The traditional method is fetch polling at a regular interval but nowadays most email clients support push notifications. We are discussing a tool that these clients can use behind the scenes to provide these push notifications for the email client in a battery and data efficient manner.
Push notifications work with any app. It is nicer to group notifications by app, and have app specific behavior. Emails add an extra step to get to the content in the app.
Gmail does push notifications. Otherwise, have to wait for the client to poll the server.
If it's using intermittent/timed fetch, that runs into the latency problem (taking longer to receive notifications). Push notifications exist to solve that problem.
If it's using IMAP's IDLE, MAPI's push, or JMAP's push, that's just another long-running HTTP or websocket connection.
And this protocol (along with the proprietary push notif aggregation services it is aiming to replace) exists to deduplicate those many long-running connections into a single connection out to some hardwired server that manages the many services/connections for it.