logoalt Hacker News

ameliaquiningyesterday at 10:37 PM5 repliesview on HN

Mobile push notifications are a special case because it's literally not technically possible to self-host them. Or rather, it's possible if you build the iOS and Android apps from source and distribute them through TestFlight or an analogous Android channel, but it's not possible for the developer of an App Store or Play Store app to allow its users to point it at a different push-notification server, because the public key has to be hardcoded in the app binary. So if you want your self-hosted Zulip server to work with the Zulip client apps in the App Store and Play Store, you have to use Zulip's push server, and there's nothing Zulip can do to fix that.

Matrix works analogously; if you use the Element app from the App Store or Play Store, then you're using Element's push notification server, even if your Matrix homeserver is self-hosted. It's possible that Element allows their server to be used gratis in situations where Zulip charges a fee, I don't know their policies or anything, but in principle Matrix still leaves you exactly as dependent on a third party's goodwill unless you make your friends install a privately distributed mobile app.

Zulip IIUC does not restrict self-hosting of any feature that's technically possible to self-host.


Replies

vitroyesterday at 11:29 PM

But how ntfy does it then? It is one app that allows you to subscribe to multiple different notification endpoints. I have uptime notifications set up this way.

Wouldn't it be possible for Zulip to go this route as well?

show 3 replies
Saline9515yesterday at 11:05 PM

The solution for this is to install the self-hosted Zulip as a PWA, but unfortunately they don't support web push.

show 1 reply
caconym_yesterday at 11:07 PM

I understand that (IIUC in Matrix the client decides what push gateway to use, and the Element client just hardcodes matrix.org and lets anyone use it for free), but it doesn't really do much for my practical concerns. I'm looking for something my users can tolerate (which means no monthly fee) and that I can be reasonably confident won't rugpull us or vanish in the next ~10 years.

show 1 reply
cyberaxyesterday at 10:57 PM

> because the public key has to be hardcoded in the app binary

Nope. On iOS the flow is:

1. Generate a "push token" on the device (with the user's approval).

2. Send this token to your server.

3. Now you can send notifications to the device via this token. Your server needs to authenticate itself with Apple, and this requires an Apple account. But it's not linked to an individual app.

The situation is different on Android. Google went out of their way to make it impossible to customize `google-services.json` at runtime. So the built-in "easy" flow won't work. But notifications ultimately work using veeeeery obfuscated remote procedure calls to Google Play Services and you can run them manually. I need to do a write-up about this....

show 2 replies