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.
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?
The same way that Element does - they host a service for you that relays push notifications their Firebase Cloud Messaging endpoint for Android or iOS Instant Notifications for Apple. I believe ntfy's hosted option is the way they offset the costs of hosting this, even if self-hosted options can take advantage of those servers free of charge.
I think it's reasonable for Zulip to ask for compensation for access to these gateways, since Apple and Google do not make them available to end users free of charge, and the burden of responsibility to ensure that these systems aren't abused is on them. Also, the fact that they offer mobile push notifications for any self hosted server of up to 10 users is pretty generous, and there seems to be a Community plan option for larger servers that includes "groups of friends" as a qualifier. It really seems they're offering quite a bit.
Because ntfy doesn’t, at least not in a way that detaches you from a central authority.
On its own notification to your device will happen eventually when the ntfy app on your phone wakes up and polls. Pull, not push.
My ntfy server has a config line for an upstream, which is a service that then uses push. Basically it’s self hosted and handing off push.
The difference between ntfy and another type of push is that you don't need a server owned by the group that makes the app forwarding messages through apple or Google. You can have your chat server send messages to your ntfy server, which then arrive on your phone.
The solution for this is to install the self-hosted Zulip as a PWA, but unfortunately they don't support web push.
Yeah. This is exactly my worry: as soon as solutions to technical problems like this start going in the direction of "we'll offer a monolithic solution and charge users for access to it" instead of "we'll make it as generic as possible even if the alternatives for now are flawed", it makes me wonder about the long term trajectory of the project.
I don't mean to cast aspersions on the developers—I respect everybody's right to try to get paid for good work, and this looks like good work. I am just not convinced it's the right option for my specific needs.
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.
> 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....
i would read that write-up!