traveler1 3 days ago | next |

Whilst this is theoretically a nice idea for security/privacy, wouldn’t there be throughput/latency concerns over mobile networks if you aren’t just connecting to one server and getting all your notifications in one go? One of the biggest slow downs on mobile data is the initial handshake, so repeating that for each of your apps doesn’t seem worth the trade off to me.

hollow-moe 3 days ago | root | parent |

This is the goal, in the same way Google does for FCM: the Play Services maintain a connection with their servers to get the notifications and then send them to the different apps. Here's it's the same with a server you control and know it won't read whatever is in that notification, without draining the battery because there's only the Unified Push app maintaining the connection.

GranPC 3 days ago | root | parent |

> know it won't read whatever is in that notification,

Aren't notification contents E2E? The website is rather light on details.

goku12 3 days ago | root | parent | next |

Notifications don't appear to be E2EEed. They are encrypted in flight. But they do change formats while on the servers. For example, the application server contacts the push server using Web Push (like a webhook), but the communication from push server to the distributor app on the end device is using some other protocol like XMPP, Server send events or WebSockets. This obviously requires decryption.

But the encryption shouldn't be a big issue as @morith pointed out. The application server can send a notification to the end user application simply asking it to refresh. The second image on their home page (https://unifiedpush.org/) illustrates this.

MattJ100 2 days ago | root | parent |

Yeah, existing proprietary (e.g. Apple/Google) push notifications are not E2EE, so apps that need to convey sensitive information (secure messaging apps, etc.) tend to take this approach already regardless of push provider.

moritzruth 3 days ago | root | parent | prev |

IIUC notification contents are application-defined. So if you're building a weather app and don't care about encryption, your content can literally be "It's going to be sunny." Signal, on the other hand, would only send "please refresh" and then it's the app's responsibility to act on it.

mmwelt 3 days ago | prev | next |

A pity that iOS doesn't support UnifiedPush and probably won't in the foreseeable future[1].

[1] https://unifiedpush.org/users/faq/#will-unifiedpush-ever-wor...

jqpabc123 3 days ago | root | parent |

This essentially kills it's utility for a lot of use cases.

KetoManx64 2 days ago | root | parent |

Does it? If you're using an iPhone are you really expecting to be able to use a third party project like this for notificatioms with how locked down IOS is and Apple's limitations on what is allowed to be installed on your device?

jqpabc123 2 days ago | root | parent |

You just reiterated my point --- and expounded on why it would be more accurately called "DroidPush".