Conversations (the XMPP client) has also figured out a way to receive notifications without using centralized servers by keeping an TCP open thus avoiding any centralized servers for push notifications. Modern XMPP servers can be instructed to only use the TCP connection when a notifying message arrives to avoid radio and battery consumption. Conversations also can act as a UnifiedPush distributor for other apps which don't want to maintain their own TCP connection.
How does this handle frequent network/tower changes (think high-speed train) and such?
There are also the privacy implications, if you have separate connections to a server for every single app, every single app knows exactly when you get home and go to work (by monitoring when you're connected to WiFi and connecting from a broadband operator and when you're on mobile.)
The goal or Unified Push is that you have one push provider you install (Conversations, NextCloud, ntfy) that ofher apps integrate you. Apps register a callback URL through the provider on your phone, report that to their own servers, and when it becomes time to notify the user, the server submits a POST request to the app server.
If set up right, there will be two persistent connections at most: one to Google/Apple, one to the provider you have registered. The app will inform the other applications on the phone of the notification, so there is no need for any other individual connections back home.
This is an alternative for what happens now when apps can't make contact with platform notification services (either because of network failures or because of the push service being disabled): suddenly, every app falls back to their own custom notification socket, or notifications stop showing at all.
The mobile platforms really need to provide an API like "the radio is now on, please do your thing", so all apps can coordinate when they're active, and save battery.
QUIC makes changing IPs cheap & trivial, send one packet to server to poll for new messages, server responds with one or more packets to get pending messages delivered, and will push messages to that IP from there on.
I'm not quite sure how it handles network changes, but Conversations has worked well for me even on trains and cars in the last 2 years. Maybe this? https://xmpp.org/extensions/xep-0198.html
Yes, XEP-0198 is how reconnects (network changes, train tunnels, etc.) are handled. When the client reconnects to the server they exchange where each received up to before the disconnect and each side resends anything that was dropped.
This blog post covers some more recent improvements at https://blog.prosody.im/fast-auth/ - it makes XMPP (and therefore Unified Push) even smoother on lossy and high latency networks.
