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

[s1m@infosec.exchange]

@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

[daniel@gultsch.social]

@S1m 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 https://codeberg.org/iNPUTmice/up/src/branch/master/README.md (which already has multiple independent implementations) and I would write the code.

[daniel@gultsch.social]

@S1m 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.

[s1m@infosec.exchange]

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

[s1m@infosec.exchange]

@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 😅

[s1m@infosec.exchange]

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

[s1m@infosec.exchange]

@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@gultsch.social]

@S1m public in the sense that it was discussed during the 2023 summit.

Notes from the summit https://pad.nixnet.services/oy6MKVbESSycLeMJIOh6zw#

And here is some work on the spec https://pad.nixnet.services/TRjHpDkUSrep9jqzcjY0uw (but as I said my proposal to use WebPush was sort of rejected so this link doesn't mention WebPush)

[s1m@infosec.exchange]

@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@gultsch.social]

@S1m The FCM WebPush thing is understood. (I think at that time in 2023 I was only 90% sure that it would actually work in practice) it's maybe not totally clear in the notes but it was clear in the room.

[s1m@infosec.exchange]

@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@gultsch.social]

@S1m yes. Marvin was in the room. We knew it should work in theory but hadn't conducted an end to end test yet.

[s1m@infosec.exchange]

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

[daniel@gultsch.social]

@S1m I will make my case for WebPush again if the topic comes up again (Maybe at the 2026 summit in 2 weeks).

[daniel@gultsch.social]

@S1m mobile distributions will likely also ship a default instant messaging application. Why not make that @dino and kill two birds with one stone?

Dino is already one of the go to IM applications on Linux on Mobile.

[s1m@infosec.exchange]

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

[fluttersh@pony.social]

@S1m @daniel @dino would be nice if push was a freedesktop implementation with dbus or something like that

[s1m@infosec.exchange]

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

[fluttersh@pony.social]

@S1m @daniel @dino noice!

[daniel@gultsch.social]

@S1m @dino Anonymous XMPP login aka without registration is an entirely solved problem. This could be used before the user configures their own account or for users that don't have XMPP.

I mean obviously let's have all the distributors but the XMPP as a distributor angle is the one I'm personally most interested in.