Piero Bosio Social Web Site Personale

@daniel @dino I understand. One idea I like is having many applications distributor & connector.

As every user have many apps installed on their phone, many users have UnifiedPush support without installing anything else.

The user pick one random app once to get push notifications, and all the apps use this app as a distributor.

If the distrib app is uninstalled, all the apps migrate to another distributor.

If the distrib app's server is down, all the apps fallback to another app until the server is up again (cf. TEMP_UNAVAILABLE)

So we have a resilient push notification system :)

@fluttersh @daniel @dino It uses dbus under the hood: https://unifiedpush.org/developers/spec/dbus/

@daniel @dino

Using a dedicated service has many advantages:

• it is a service, and can be managed by service managers
• it provides a push service without any authentication/registration
• it is a single-purpose service for push notification
• the current service we have is extremely lightweight

On the other side:

• XMPP requires a user account: everybody doesn't have one, and it requires additional user setup (e.g. login) *
• it isn't a single-purpose service, so it cannot be pre-installed just for push notifications. It may be pre-installed for other reasons but not push alone
• People who don't want/need to use XMPP may prefer to not get an XMPP client always on

* Theoretically, we could have a transparent auto-registration. I don't know if some servers are open to do that

But, as everything is done to allow the user to use the service they want, if your XMPP client can provide push notifications, nothing stops you from using it, and stopping the default service :)

@daniel OK, interesting. So it wasn't made on a wrong assumption then

@daniel OK, good to know.

I personally learned it at the end of 2023, after marvin added it to their gist: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0aaeb74/revisions

At this time, and yet today, it was widely assumed that a gateway to FCM was required

@daniel Hm, too bad they don't want to rely on existing standards

This could relieve the client developer from needing to run a gateway for e.g. web apps (you still need one for APNS/FCM due to the credentials).

Moreover, it seems to have been rejected partly on a wrong assumption: FCM can be requested with web push. And I don't know for APNS, Apple has moved in this direction for installable web apps

@daniel Was the discussion about Push Notifications 2.0 XEP public? It would great having a link to follow the process

https://codeberg.org/UnifiedPush/wishlist/issues/35

@daniel But we're far from this situation. The current status is great 👍

@daniel And, that's good having efficient distributor services available with applications that aren't specific to this task, but I think it would be great if they could also use another service too. It wouldnt be suitable if all applications were providing the service but not using it 😅

@daniel On Linux, the need is clearly the other way around, mobile distributions will likely come with their default service

@daniel Do you know if there is a XEP to send web push notifications from an XMPP server?

For the reference: https://github.com/dino/dino/issues/1809

UnifiedPush has already been around for five years! Now is the perfect time to look back and forward.

https://s1m.fr/unifiedpush-5-years/

#UnifiedPush #android