Allow configuring push notification provider

[Xiretza]

Your use case

What would you like to do?

I want to use UnifiedPush even if google services are claimed to be available.

Why would you like to do it?

I have MicroG installed on my phone. Unfortunately it claims to provide google services even if those aren't actually set up (no google account signed in), which means that EXA won't try to fall back to UnifiedPush.

How would you like to achieve it?

Ideally, the push provider platform (google/unifiedpush) as well as the exact UnifiedPush provider (e.g. ntfy, NextPush, etc) would be configurable.

Have you considered any alternatives?

If I understand correctly, the F-Droid app, once available, won't support google push services at all, so that would also solve my particular issue.

Additional context

No response

Are you willing to provide a PR?

No

[bmarty]

We are making progress on this, but I have noticed that ntfy.sh is not sending Push when the request is coming from matrix.org.

Here is the homeserver log:

Failed to push data to @UserRedacted:matrix.org/im.vector.app.android/https://ntfy.sh/upRPREDACTEDWI?up=1:
<class 'synapse.http.RequestTimedOutError'> 504: Timeout connecting to remote server

When using the troubleshoot notification from EXA, it works, because requesting ntfy.sh from the device is not rate limited, and the test Push is correctly routed to the device and then to the application.

I have asked here if there is something we can do about it.

Similar issue on Element Android: element-hq/element-android#7069

(discussed internally in this message).

[p1gp1g]

In order for the client to be able to troubleshoot this case, when the homeserver can't reach the push gateway, which seems to happen regularly for self-hosters: there should be a new client <-> server MSC.

This MSC should define a client request ordering a test notification from the push server to the gateway. Currently, the test notification is send by the client which make this issue invisible.

Many users self-hosting their homeserver and their push server forget to set the synapse's ip_range_whitelist parameter.

[bmarty]

@p1gp1g it would be awesome. Currently this part is not checked during the notification troubleshoot test suite, but if every tests are passing and the user still do not get push (can be tested easily by sending a message in a DM using another account) the broken link between the homeserver and the push gateway is generally the cause of the issue.

Another option would be to send a test Push when registering a pusher, so this can validate that the pusher is operational.

[p1gp1g]

The test push during registration is a good idea. The same test endpoint could be used during troubleshooting and automatically during registration then

[bmarty]

Done in #2873 (EXA 0.4.13)

[wrenix]

Hmm, a got Error, if tip on a option and i could not select one:

---

[Xiretza]

Hmm, a got Error, if tip on a option and i could not select one:

See #2895