1. The idea behind #UnifiedPush is amazing. An open protocol to share push notifications over any asynchronous channel (websocket, Redis, MQTT etc.) is what open-source apps have needed for years. Sure, there will always be those who say "push notifications are a distraction, and I'm happy to ditch them". But individual choices/behaviors shouldn't shape the development of a technology - especially when people want a genuine open alternative to something that they like/need to use.
2. UnifiedPush support from individual apps is still scarce. So far I've only found the NextCloud app itself (which only supports UP-NextPush), #Fedilab and #Element. Support on #Tusky has allegedly been implemented in the latest release, but I haven't yet managed to make it work. Let's roll up our sleeves and make sure that more and more of the apps that we like support open notification services!
3. The notification providers' client apps themselves are still quite buggy, and documentation still very sparse. I have used UP-Example from F-Droid to test the UP services. Only ntfy managed to deliver notifications end-to-end to my devices. Gotify reported an "unknown error" without many details from the logs. UP-NextPush is still very unstable both on the client and server side and I couldn't manage to deliver any notifications.
4. The protocol (and the apps that implement it) needs to slowly be extended to cover as many as possible of the features that have been implemented in the past decade. Action buttons, icons from URLs, custom background images, updates to existing notifications etc.: a couple of these features have been (partly) implemented by 1-2 providers, but we need open standards (especially for action buttons and gestures) if we want to ensure inter-compatibility.
Interesting replacement, esp. #UnifiedPush
Are you considering replacing Firebase in its entirety? I know there's a number of interesting #FOSS alternatives around, though none are simple 1-to-1 alternatives depending on what features you use. There was a recent HN discussion on that.
Supabase tries to be more a 1-1 replacement of Firebase though, while the alternatives based on UnifiedPush are more like general-purpose mechanisms to deliver asynchronous messages regardless of the platform - and I'm ideally looking for something that can work on any platform, not only Android. But let's see, if Supabase has managed to implement something more usable on Android I may even opt for it in the short term.
2. Talking about Nextcloud and UnifiedPush :
Just to clarify, NextPush is not related to Nextcloud team/project, but a Nextcloud application
Also, there is a project to get Nextcloud notification without google services but it is not related to UnifiedPush
3. Gotify-UP is being deprecated. We plan to update the doc asap and release a version of Gotify-Up to inform users.
Also, sad you couldn't install NextPush, which should be straight forward :/. We can help if you need to.
4. The protocol has absolutely nothing to do with notifications features like buttons, icons etc. It just deliver messages to applications.
For instance, Element have notifications with quick replies, calls answer etc even with UnifiedPush.
5. Finally, all of this show one thing: we need to improve our doc/communication. We'll be glad to answer your questions, and improving our doc with your remarks
@zgou thanks for the well detailed responses!
1. Yes, I'm aware of the list of supported apps - btw, FluffyChat would have been my natural choice for Matrix given its support for UnifiedPush, but the latest build doesn't even start on any of my Android devices. I'm also aware that the support for UP on Tusky and Element is still available only on the main branch - and that's what I tested, and that's what I've had issues with. My workaround for now is to use a Platypush cronjob that polls Mastodon and Matrix over their APIs for new events and it pushes notifications over ntfy/Gotify. But it's definitely a workaround that may technically not be within reach for many users. All these considerations just reinforce my point that the protocol and technology are very promising, but there are only a bunch of apps that support them. And even some of the apps that support UP still have only experimental support.
2. On the NextCloud/UnifiedPush...the situation is a bit confusing to say the least :) I have noticed that there are several unrelated projects that are incompatible with one another. Maybe it's worth joining the efforts on that side? And maybe also try to get the development of UP directly under NextCloud's umbrella. Projects like /e/OS and LineageOS may definitely opt for better NC integration if it provided a good uniform and reliable system to deliver notifications.
About the struggles with NextPush - I have the UnifiedPush Provider installed on my instance, Redis and the nginx proxy properly configured, but on all of my Android devices the app starts throwing "NextPush is disconnected" after a while, with no relevant errors logged on the server.
3. Is there going to be an upcoming release of Gotify with UP support? The service and the app are already quite mature, and it'd be nice to also have UP support built on them.
4. I believe (but it's just my two cents) that support for extended features such as icons/actions/backgrounds (and, IMHO most importantly, update of existing notifications by ID) may be something good to support in the protocol itself. Actionable and rich notifications have been standard features on Android for a decade, and they also provide free native integration with e.g. wearables and smart displays. Closed source apps like Tasker already provide support for actions and icons - albeit (again IMHO) poorly implemented/standardized. Some people may want to switch to open-source alternatives, but they may also be used to the current experience. And if we tell them "this is the open-source alternative, but it just delivers non-interactive text from A/B and nothing more" they could be discouraged. Sure, individual apps could implement their own solutions for these problems. But in my experience it's always better to invent the wheel only once through a good standard than letting n solutions invent n different wheels that aren't compatible with one another.
A platform about automation, open-source, software development, data science, science and tech.