in reply to S1m

mastodon - Link to source

Daniel Gultsch

I have been talking to @larma about making Dino a UnifiedPush distributor. Similar to Conversations, Dino would be an ideal candidate to facilitate push notifications for other apps on Linux on mobile.
In that case we would like standardized a variant of the protocol that is outlined here codeberg.org/iNPUTmice/up/src/… (which already has multiple independent implementations) and I would write the code.

Cookie monster!

codeberg.org
@Marvin W
in reply to Daniel Gultsch

mastodon - Link to source

Daniel Gultsch

The other way round (making XMPP apps wake up upon receiving WebPush notifications) is currently not standardized. We are talking about a Push Notifications 2.0 XEP and I have been advocating for using WebPush but I have also met some resistance because XMPP server devs aren't super keen on a hard dependency to HTTP.
And personally I find the other direction, making the XMPP client a distributor, much more interesting.
in reply to Daniel Gultsch

mastodon - Link to source

S1m

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

in reply to Daniel Gultsch

mastodon - Link to source

S1m

@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 :)

@Dino
in reply to Daniel Gultsch

mastodon - Link to source

S1m

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 :)

Android

UnifiedPush Spec: AND_3.1.0 Index Resources Overview Push Distributor Distributor manifest End User Application End User Application Manifest Registration Broadcast Receiver org.unifiedpush.android.distributor.REGISTER org.unifiedpush.android.
UnifiedPush
This entry was edited (1 week ago)
in reply to helly

mastodon - Link to source

Daniel Gultsch

@fluttersh @dino there would be some default 'rewrite proxy' (like up.conversations.im in #Conversations_im for example). And then you would also have some default XMPP server that allows anonymous login but can only connect to said rewrite proxy. I guess one could also allow list certain extensions. But for the domain allow list we already have the building blocks in place. I guess technically the login server and the rewrite proxy could be the same domain even. That's just boring details.
#conversations_im @Dino @helly
⇧