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

[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.

[s1m@infosec.exchange]

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

@daniel @S1m @dino prosody by default have the s2s restrictions for anonymous accounts, but wouldn't operators need to host servers that only do certain xep support for anonymous accounts as well?

[fluttersh@pony.social]

@daniel @S1m @dino I guess just disabling most/some modules should be fine

[daniel@gultsch.social]

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