Livewire already uses XEP-0357 for push notifications. But that XEP only specifies that the XMPP server pushes a notification to an XMPP component. After that, the component is responsible for forwarding the notification onward to its destination. Livewire is using a modified version of Monal’s fpush that can push to the UBPorts Push Service for Ubuntu Touch, and now also UnifiedPush for Sailfish OS, since for some reason there is no native push service. This is why you must install the toot toot Foghorn to have working push notifications.
1 Like
I would like UnifiedPush to be part of the base Sailfish system eventually.
Speculating about the current lack of push service, I’d assume Jolla didn’t want to define yet another push implementation nor commit to keep a push server running. (Unified push was not a thing back then.)
Not familiar with Monal or the XEPs, unfortunately, so maybe I’m talking out of my hat here. What I mean is that XMPP servers can (and do) provide push themselves that can be used by other apps as well. So not adding Mozilla to the mix, however nice as they may be, would seem natural to me when the first thing on Sailfish to use push would be XMPP.
This is based on my understanding of what conversations.im does - I think it acts like a UP provider with XMPP as the transport and Conversations-the-app (or a background service of it) provides a UP distributor.
Also, according to my understanding, Unified Push doesn’t specify the protocol between provider and distributor, so my question was if you would consider adding the protocol defined here:
(Sorry if you already answered about that, but I failed to understand!)
Conversations and its derivatives acting as a UnifiedPush provider is different than XMPP push notifications. A UP provider is using the XMPP server as the actual push service mechanism for UnifiedPush traffic. XMPP push notifications via XEP-0357 are push notifications from the XMPP server for messages and whatever else to a target device.
In the case of Foghorn, Mozilla’s push service is acting as the UnifiedPush provider, similar to the Sunup Android app. I plan to eventually add at least ntfy.sh and NextPush (NextCloud). I’m not really sure I will add XMPP as a UnifiedPush provider because it doesn’t entirely make sense if the XMPP connection can go down and be disconnected. I haven’t checked to see if UnifiedPush over XMPP can make use of XEP-0357 or not. And if it does, then you’re back to needing another UnifiedPush service. So running UP push provider mode would be mutually exclusive with push notifications for Livewire.
If all of this terminology is extremely confusing and circular, you’re not alone, believe me. 
Edit: I have indeed considered adding the UnifiedPush provider mode to Livewire, and it may eventually show up (at least on SFOS, not UT). But it would require always connected mode, because otherwise it doesn’t make any sense.
1 Like
Isn’t that acceptable, though? I mean the idea is to have push messages funneled through a single always-on connection to avoid uncoordinated wake ups? (In addition to having one more way to spy on people and lock them in, if you’re Apple or Google.)
It is confusing!
My understanding of UP is something like person or system default picks a push server, apps tell their servers to use that push server, distributor on device sends notifications to the target app(s). UP defines these protocols, except the one between push server and distributor, so the transport is not locked to a specific implementation.
Anyway, thank you for all your work on this! I hope it will eventually provide the base for general push notifications on Sailfish. (And let’s not derail this thread further…)