Not receiving notifications on the F-Droid version with unified push

[K4LCIFER]

Steps to reproduce

1. Install unified push (e.g. ntfy.sh)
2. Install Element X via F-Droid
3. Receive a message
4. Observe that no notification is received.

Outcome

What did you expect?

I would expect to receive a notification.

What happened instead?

I didn't receive a notification

Your phone model

Google Pixel 6

Operating system version

Android 14

Application version and app store

0.4.14

Homeserver

matrix.org

Will you send logs?

No

Are you willing to provide a PR?

No

[bmarty]

Hello @K4LCIFER , thanks for reporting. For some reason, sometimes an error occurs when registering the pusher. I am investigating it.

To unblock you, can you navigate to Setting/Notifications then scroll to the bottom. If the current push provider is displayed and in Error, you can click on it and select again "Ntfy". It should help.

Also note that if your a matrix.org user, push may be rate limited by the ntfy server.

It's also possible to run the notification troubleshoot tests to see what could go wrong.

[K4LCIFER]

@bmarty: To unblock you, can you navigate to Setting/Notifications then scroll to the bottom. If the current push provider is displayed and in Error, you can click on it and select again "Ntfy". It should help.

I don't appear to have any push provider information on that page.

---

@bmarty: Also note that if your a matrix.org user, push may be rate limited by the ntfy server.

I don't think that's the case here. I've received notifications from other services at higher rates through Ntfy than through Element.

---

@bmarty: It's also possible to run the notification troubleshoot tests to see what could go wrong.

It appears that there is no issue and it is able to find the UnifiedPush provider.

---

The issue is still persisting.

[alnmy]

Same issue, GrapheneOS with self-hosted ntfy.sh instance that has other notifications working but not from Element X. Also same results from the troubleshoot tests.

[alnmy]

Same issue, GrapheneOS with self-hosted ntfy.sh instance that has other notifications working but not from Element X. Also same results from the troubleshoot tests.

My issue has been resolved. Essentially, my push server was behind a VPN which my server could not access. I would consider it a bug that the notification troubleshooter reports the "test push loop back" as being completed, when the server could not do this.

[bmarty]

The "Test Push loop back" test does not involve the Matrix homeserver. But yes, I agree that the communication homeserver -> push gateway is not covered by the troubleshoot tests, and this is annoying. This is the only part that is not covered.

This is discussed at matrix-org/matrix-spec-proposals#4078

[anytimesoon]

I'm also facing this. Element receives the notification, but element x does not. All the notification troubleshooting tests pass.

I'm running calyox os on a fair phone, and the latest version of element x from the playstore

[tomhanax]

same problem here, using F-Droid version

[K4LCIFER]

I hope that the severity of this issue is labelled rather high — it severely impacts the usability of the app.

[voidzero]

I've tried both the Play Store version of ntfy and the F-Droid version, both are not giving me notifications, except for when I use the troubleshoot notifications button in Element X, or when I use Firebase. Where is the issue?

Subscribing to a new topic on ntfy and posting to that with curl does give me notifications for that topic. Using the Fedilab Mastodon client with ntfy also does work.

[dessalines]

Can confirm that unifiedpush with ntfy is not working with the version on f-droid. ntfy correctly shows the topic, but nothing comes through.

I'm using the default server for ntfy.sh.

[gtdm]

I've tried switching to FluffyChat after noticing this issue but that client has the same issue. No notifications at all... so I guess it's related to ntfy (or it's default instance) and not Element X?

[K4LCIFER]

so I guess it's related to ntfy (or it's default instance)

If so, it would probably be the actual service and/or app and not the default instance as @alnmy mentioned that they have the problem (they self-host a ntfy instance).

[spaetz]

If so, it would probably be the actual service and/or app and not the default instance as @alnmy mentioned that they have the problem (they self-host a ntfy instance).

Nope, alnmy said 'Essentially, my push server was behind a VPN which my server could not access.'. So, they had a completely different problem. I am pretty sure the 'problem' is on the ntfy.sh side. Try a different ntfy server (eg https://ntfy.envs.net/ ) and see if that one works any better.

[anytimesoon]

In my case, we can rule out the ntfy server since the notifications come through for element, but not element x

Edit to clarify that the messages come through on element x, but I get no notification for it. When I open the app, I can see a green dot indicating that there is a new message in a conversation, but there was not system notification about it

[gtdm]

In my case, we can rule out the ntfy server since the notifications come through for element, but not element x

Are you sure that the notifications come through ntfy? I've never had to use UnifiedPush with the "old" Element app because it had a timer-based notification system under the hood.

Edit: I'd actually really like to get the timer-based notification system in Element X too. Would save me the hassle from having to use UnifiedPush/ntfy at all since no other app I use requires those.

[anytimesoon]

Definitely coming through ntfy. The battery drain from constant polling lead me to add ntfy to my stack.

That said, it's been a few days since I've had any dropped notifications at this point

[K4LCIFER]

[@anytimesoon] That said, it's been a few days since I've had any dropped notifications at this point

You're receiving notifications for Element X through Ntfy? I haven't received a single notification with Unified Push and Ntfy since I opened this issue. It also seems that I'm not receiving notifications on element-android with Ntfy.

[p1gp1g]

The "Test Push loop back" test does not involve the Matrix homeserver. But yes, I agree that the communication homeserver -> push gateway is not covered by the troubleshoot tests, and this is annoying. This is the only part that is not covered.

This is discussed at matrix-org/matrix-spec-proposals#4078

This exact issue is more related to matrix-org/matrix-spec-proposals#2821 (which has to be recreated)

[MatMaul]

You should put Element X as Unrestricted regarding battery optimisation, and not Optimized which is the default.

This is because:

• received push notif doesn't contain the payload since it's E2EE
• Element X needs to fetch the encrypted content and decrypt it in the background
• when an app is wake up by FCM, it is given special treatment by the OS and can access the network and do stuff in the background for a certain period of time
• this is NOT the case for UP based push

TLDR, you need BOTH the push provider AND Element X to be unrestricted regarding battery optimisation.

[MatMaul]

@bmarty: it may be useful to warn the user of that and propose to the user to open the optimisation battery screen directly, when an UP provider is used instead of FCM.

[K4LCIFER]

I'm not sure that's the issue. I have "Allow background usage" enabled for both Element X and Ntfy, yet I am receiving no notifications.

[voidzero]

Yeah battery optimizations has nothing to do with it, it's the first thing I tried.

[bmarty]

It can help to change the setting for battery optimisation when the application is in background, or even not running, but sometimes the Push are not received even when the application is in foreground, so screen on, with charger plugged in, fast Wi-Fi, etc.

[caspervk]

@MatMaul in #3031 (comment):

You should put Element X as Unrestricted regarding battery optimisation, and not Optimized which is the default.

This is because:

* received push notif doesn't contain the payload since it's E2EE

* Element X needs to fetch the encrypted content and decrypt it in the background

* when an app is wake up by FCM, it is given special treatment by the OS and can access the network and do stuff in the background for a certain period of time

* this is NOT the case for UP based push

TLDR, you need BOTH the push provider AND Element X to be unrestricted regarding battery optimisation.

This seems to be the answer!

During doze, the notification is properly received through UnifiedPush (ntfy-sh) and passed to Element X, but Element seems to be unable to retrieve the actual notification from the server (adb logcat | grep -E "ActivityManager|Ntfy|$(adb shell pidof -s io.element.android.x)" + Element X logs):

10-22 19:38:17.773 12559  3824 D NtfyWsConnection: ntfy-sh.example.org/uphunter2 (gid=1, lid=6): Received message: {"id":"asd123","time":1729618697,"expires":1729661897,"event":"message","topic":"uphunter2","message":"{\"notification\":{\"counts\":{\"unread\":1},\"devices\":[{\"app_id\":\"im.vector.app.android\",\"data\":{\"default_payload\":{\"cs\":\"203b48bd-5c79-46d2-a343-c1151b8ff535\"},\"format\":\"event_id_only\"},\"pushkey\":\"https://ntfy-sh.example.org/uphunter2?up=1\",\"pushkey_ts\":1729618509}],\"event_id\":\"$Cocha3ohqu2oos1nui3uong7huuyaele\",\"prio\":\"high\",\"room_id\":\"!iFo6ohthua7Aesab:matrix.org\"}}"}
10-22 19:38:17.786 12559  3824 D NtfySubscriberService: [https://ntfy-sh.example.org/uphunter2] Received notification: Notification(id=asd123, subscriptionId=34053450, timestamp=1729618697, title=, message={"notification":{"counts":{"unread":1},"devices":[{"app_id":"im.vector.app.android","data":{"default_payload":{"cs":"203b48bd-5c79-46d2-a343-c1151b8ff535"},"format":"event_id_only"},"pushkey":"https://ntfy-sh.example.org/uphunter2?up=1","pushkey_ts":1729618509}],"event_id":"$Cocha3ohqu2oos1nui3uong7huuyaele","prio":"high","room_id":"!iFo6ohthua7Aesab:matrix.org"}}, encoding=, notificationId=1547116709, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false)
10-22 19:38:17.790 12559 14972 D NtfySubscriberService: [https://ntfy-sh.example.org/uphunter2] Dispatching notification Notification(id=asd123, subscriptionId=34053450, timestamp=1729618697, title=, message={"notification":{"counts":{"unread":1},"devices":[{"app_id":"im.vector.app.android","data":{"default_payload":{"cs":"203b48bd-5c79-46d2-a343-c1151b8ff535"},"format":"event_id_only"},"pushkey":"https://ntfy-sh.example.org/uphunter2?up=1","pushkey_ts":1729618509}],"event_id":"$Cocha3ohqu2oos1nui3uong7huuyaele","prio":"high","room_id":"!iFo6ohthua7Aesab:matrix.org"}}, encoding=, notificationId=1547116709, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false)
10-22 19:38:17.790 12559 14972 D NtfyNotifDispatch: Dispatching Notification(id=asd123, subscriptionId=34053450, timestamp=1729618697, title=, message={"notification":{"counts":{"unread":1},"devices":[{"app_id":"im.vector.app.android","data":{"default_payload":{"cs":"203b48bd-5c79-46d2-a343-c1151b8ff535"},"format":"event_id_only"},"pushkey":"https://ntfy-sh.example.org/uphunter2?up=1","pushkey_ts":1729618509}],"event_id":"$Cocha3ohqu2oos1nui3uong7huuyaele","prio":"high","room_id":"!iFo6ohthua7Aesab:matrix.org"}}, encoding=, notificationId=1547116709, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false) for subscription Subscription(id=34053450, baseUrl=https://ntfy-sh.example.org, topic=uphunter2, instant=true, mutedUntil=0, minPriority=0, autoDelete=-1, insistent=-1, lastNotificationId=DIKcW8ZVBWSI, icon=null, upAppId=io.element.android.x, upConnectorToken=91a1b80e-29ff-4afd-b060-b08766afaab4, displayName=null, dedicatedChannels=false, totalCount=446, newCount=446, lastActive=1729618616, state=CONNECTED)
10-22 19:38:17.791 12559 14972 D NtfyUpDistributor: Sending MESSAGE to io.element.android.x (token=91a1b80e-29ff-4afd-b060-b08766afaab4): 382 bytes
10-22 19:38:17.799  1516  1740 D ActivityManager: sync unfroze 25342 io.element.android.x for 3

2024-10-22T17:38:17.825271Z DEBUG elementx: [Push/VectorUnifiedPushMessagingReceiver] New message | 
2024-10-22T17:38:17.835299Z DEBUG elementx: [Push/PushHandler] ## handling pushData: !iFo6ohthua7Aesab:matrix.org/$Cocha3ohqu2oos1nui3uong7huuyaele | 
2024-10-22T17:38:17.851021Z DEBUG elementx: [Push/PushHandler] ## handleInternal() | 
2024-10-22T17:38:17.866613Z DEBUG matrix_sdk::http_client::native: Sending request num_attempt=1 | crates/matrix-sdk/src/http_client/native.rs:55 | spans: get_notification{room_id="!iFo6ohthua7Aesab:matrix.org" event_id="$Cocha3ohqu2oos1nui3uong7huuyaele"} > try_sliding_sync > sync_once > send{server_versions=[V1_0, V1_1, V1_2, V1_3, V1_4, V1_5, V1_6, V1_7, V1_8, V1_9, V1_10, V1_11] config=RequestConfig { timeout: 4s } request_id="REQ-22" method=POST uri="https://synapse.example.com/_matrix/client/unstable/org.matrix.simplified_msc3575/sync" request_size="653 B"}
2024-10-22T17:38:17.873655Z DEBUG matrix_sdk::http_client: Error while sending request: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("synapse.example.com")), port: None, path: "/_matrix/client/unstable/org.matrix.simplified_msc3575/sync", query: Some("timeout=1000"), fragment: None }, source: hyper_util::client::legacy::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: No address associated with hostname" })) }) | crates/matrix-sdk/src/http_client/mod.rs:228 | spans: get_notification{room_id="!iFo6ohthua7Aesab:matrix.org" event_id="$Cocha3ohqu2oos1nui3uong7huuyaele"} > try_sliding_sync > sync_once > send{server_versions=[V1_0, V1_1, V1_2, V1_3, V1_4, V1_5, V1_6, V1_7, V1_8, V1_9, V1_10, V1_11] config=RequestConfig { timeout: 4s } request_id="REQ-22" method=POST uri="https://synapse.example.com/_matrix/client/unstable/org.matrix.simplified_msc3575/sync" request_size="653 B"}
2024-10-22T17:38:17.874665Z  INFO matrix_sdk_ui::notification_client: fetching notification event with a /context query | crates/matrix-sdk-ui/src/notification_client.rs:540 | spans: get_notification{room_id="!iFo6ohthua7Aesab:matrix.org" event_id="$Cocha3ohqu2oos1nui3uong7huuyaele"}
2024-10-22T17:38:17.875378Z DEBUG matrix_sdk::http_client::native: Sending request num_attempt=1 | crates/matrix-sdk/src/http_client/native.rs:55 | spans: get_notification{room_id="!iFo6ohthua7Aesab:matrix.org" event_id="$Cocha3ohqu2oos1nui3uong7huuyaele"} > send{server_versions=[V1_0, V1_1, V1_2, V1_3, V1_4, V1_5, V1_6, V1_7, V1_8, V1_9, V1_10, V1_11] config=RequestConfig { timeout: 30s } request_id="REQ-23" method=GET uri="https://synapse.example.com/_matrix/client/v3/rooms/!iFo6ohthua7Aesab:matrix.org/context/$Cocha3ohqu2oos1nui3uong7huuyaele"}
2024-10-22T17:38:17.879637Z DEBUG matrix_sdk::http_client: Error while sending request: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("synapse.example.com")), port: None, path: "/_matrix/client/v3/rooms/!iFo6ohthua7Aesab:matrix.org/context/$Cocha3ohqu2oos1nui3uong7huuyaele", query: Some("limit=0&filter=%7B%22lazy_load_members%22%3Atrue%7D"), fragment: None }, source: hyper_util::client::legacy::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: No address associated with hostname" })) }) | crates/matrix-sdk/src/http_client/mod.rs:228 | spans: get_notification{room_id="!iFo6ohthua7Aesab:matrix.org" event_id="$Cocha3ohqu2oos1nui3uong7huuyaele"} > send{server_versions=[V1_0, V1_1, V1_2, V1_3, V1_4, V1_5, V1_6, V1_7, V1_8, V1_9, V1_10, V1_11] config=RequestConfig { timeout: 30s } request_id="REQ-23" method=GET uri="https://synapse.example.com/_matrix/client/v3/rooms/!iFo6ohthua7Aesab:matrix.org/context/$Cocha3ohqu2oos1nui3uong7huuyaele"}
2024-10-22T17:38:17.889868Z ERROR elementx: [Push/Notification/DefaultNotifiableEventResolver] Unable to resolve event: $Cocha3ohqu2oos1nui3uong7huuyaele.
org.matrix.rustcomponents.sdk.ClientException$Generic: msg=error sending request for url (https://synapse.example.com/_matrix/client/v3/rooms/!iFo6ohthua7Aesab:matrix.org/context/$Cocha3ohqu2oos1nui3uong7huuyaele?limit=0&filter=%7B%22lazy_load_members%22%3Atrue%7D)
	at org.matrix.rustcomponents.sdk.FfiConverterTypeClientError.read(SourceFile:26)
	at org.matrix.rustcomponents.sdk.FfiConverterRustBuffer$DefaultImpls.liftFromRustBuffer(SourceFile:13)
	at org.matrix.rustcomponents.sdk.FfiConverterTypeClientError.liftFromRustBuffer(SourceFile:1)
	at org.matrix.rustcomponents.sdk.FfiConverterRustBuffer$DefaultImpls.lift(SourceFile:6)
	at org.matrix.rustcomponents.sdk.ClientException$ErrorHandler.lift(SourceFile:8)
	at org.matrix.rustcomponents.sdk.Matrix_sdk_ffiKt.access$uniffiCheckCallStatus(SourceFile:123)
	at org.matrix.rustcomponents.sdk.Matrix_sdk_ffiKt.uniffiRustCallAsync(SourceFile:194)
	at org.matrix.rustcomponents.sdk.Matrix_sdk_ffiKt$uniffiRustCallAsync$1.invokeSuspend(Unknown Source:17)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(SourceFile:9)
	at kotlinx.coroutines.DispatchedTask.run(SourceFile:107)
	at androidx.core.app.ActivityRecreator$1.run(SourceFile:47)
	at kotlinx.coroutines.scheduling.TaskImpl.run(SourceFile:3)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(SourceFile:93)
 | 
2024-10-22T17:38:17.894194Z  WARN elementx: [Push/PushHandler] Unable to get a notification data | 

10-22 19:38:27.886  1516  2121 D ActivityManager: freezing 25342 io.element.android.x

Android Developers: Power management restrictions states that an app's network is restricted to a window at a specific interval during doze. On the other hand, Firebase Cloud Messaging has no restrictions for high priority notifications during doze. I am not sure if this is what @MatMaul meant by "when an app is wake up by FCM, it is given special treatment by the OS and can access the network and do stuff in the background for a certain period of time". I may be misunderstanding @MatMaul and/or the Android Developers docs.

Regardless, if I enable unrestricted background usage for Element X, everything works:

This feels wrong, but if FCM has special permissions in Android (even AOSP!?), I guess there isn't much we can do as long as the message content is fetched and decrypted separately from the notification (as it should).

[seankhl]

Sadly this doesn't solve the problem for me. As mentioned above I already tried this: both apps are set to unrestricted and I still don't get notifications.

One thing to note is that even though I've set this and opened Element X multiple times, it still doesn't appear in the "Active apps" list in the bottom circular tile in the Android drop-down menu, which is suspicious to me.

[caspervk]

Element X also does not appear in the "Active apps" list for me - but ntfy does. I would encourage you to check if ntfy correctly receives and dispatches the notification through adb logcat to make sure the issue truly is with Element X. That helped me a lot in the debugging process.

[ThomChroma]

@seankhl after changing the default ntfy server, did you delete the active subscription for Element X then launch Element X again so that it creates a new subscription to the new ntfy server?

[devurandom]

See-also: #3571

[p1gp1g]

The error raised by EAX when it tries to go to the foreground when it can't (so we need to unrestrict it) will be fixed when EAX will be using the next version of UnifiedPush library, and users will use a distributor following the recent spec updates

The library has a release candidate for the new version: 3.0.0-rc2, and the changes can be reviewed here: https://codeberg.org/UnifiedPush/android-connector/pulls/2

Technical details

• Android doesn't allow an application in the background to raise to the foreground, used for foreground services: https://developer.android.com/develop/background-work/services/foreground-services#bg-access-restrictions
• Google services are able to raise to the foreground other application by using a privileged API. They do broadcast intents with the broadcast option setTemporaryAppAllowlist(). They can do that because they are installed as a system application.
• New UnifiedPush spec requires application to expose a service the distributors can bind to to raise the application in the foreground, allowing the application to start foreground service. This service is in the new library: https://codeberg.org/UnifiedPush/android-connector/pulls/2/files#diff-43d1943648cfe635c5cbdf6dcfdbf4f7177778e1
• It of course need a distributor that implement it too

[p1gp1g]

It would be a good solution to also:

• Check permissions before starting a foreground service and falling back to a background service (a try/catch should work too)
• Or see if a workmanager does the job

This is also useful for FCM since they downgrade the high priority messages to normal priority if the app is not surfacing time sensitive content to the user (see https://developer.android.com/develop/background-work/services/foreground-services#bg-access-restrictions)

[K4LCIFER]

My notifications appear to all of a sudden be working now with 0.7.2 (maybe even 0.7.1, but I'm not completely sure on that). I haven't changed any config with Ntfy, or Element X. They're just working.

[Atemu]

Same for me, a few hours ago I suddenly got a bunch of messages. This was approximately 17:00 UTC on Sunday (2024-11-03T17:00:00).

At that time, I was on 0.7.1, so this happened without any modification to the software stack on my end.

[devurandom]

This does not seem universal. When I run Settings > Notifications > Troubleshoot, I still get "https://fcm.distributor.unifiedpush.org/_matrix/push/v1/notify is not a Matrix gateway".

[K4LCIFER]

At that time, I was on 0.7.1, so this happened without any modification to the software stack on my end.

I hesitantly want to say the same. I got all the notifications while it seemed that I was on 0.7.1, but I was in the process of updating to 0.7.2 when I got them, so I'm not 100% sure if the same is the case for me or if something had been changed in the update process.

[K4LCIFER]

This does not seem universal. When I run Settings > Notifications > Troubleshoot, I still get "https://fcm.distributor.unifiedpush.org/_matrix/push/v1/notify is not a Matrix gateway".

This error sounds unique to what this issue is reporting. I could be wrong, but that seems like something different.

[Atemu]

I'd like to clarify that I use the default ntfy back-end. So just install the ntfy app and set it as the push provider, no further config.

[p1gp1g]

This does not seem universal. When I run Settings > Notifications > Troubleshoot, I still get "https://fcm.distributor.unifiedpush.org/_matrix/push/v1/notify is not a Matrix gateway".

You have this issue: #3571

[p1gp1g]

I'd like to clarify that I use the default ntfy back-end. So just install the ntfy app and set it as the push provider, no further config.

1. Unrestrict battery optimization for ntfy and element-x (see Not receiving notifications on the F-Droid version with unified push #3031 (comment))
2. Unregister element from ntfy *
3. Restart element-x

* I suspect a bug where rejected keys are not renewed, they are removed by synapse but I'm not sure EAX re-register the key: https://github.com/element-hq/synapse/blob/c705beebf7e95f25624ec38280192d96bc207626/synapse/push/httppusher.py#L368

[K4LCIFER]

Should this issue be closed since notifications are now being received via unified push? However, I feel that some official explanation for why it's working all of a sudden should be first stated before this issue is closed.

[audishos]

I was not receiving notifications even though the unified push topic was being added to ntfy and the troubleshooter was passing. I was previously running Fluffy chat, kept it installed in case I decided to switch back, but disabled its notifications within the app. This had the unfortunate side-effect of disabling all unified push channels, including the one added by Element X. Re-enabling notification within Fluffy chat resolved it. If you need to disable notifications for Fluffy chat, you can do it from the native android app notification settings without disabling unified push entirely.

This is an edge case, but posting here just in case it helps anyone.

[greenship24]

I installed 0.7.4 while testing a new matrix synapse server with my private ntfy instance and am facing this issue still. I have tried doing unrestricted on the app and ntfy both, clearing the old ntfy subscription, closing and reopening element X, and testing notifications again (all worked before, all worked after.) I upgraded to 0.7.5 through Obtainium and still cannot receive notifications. Tried a full phone restart as a last ditch effort but no dice.

Running CalyxOS (latest as of December 13, 2024) and other apps (including Tusky, regular Element, etc.) use UP via this ntfy server without issue.

[p1gp1g]

If you self host synapse: https://unifiedpush.org/users/troubleshooting/self-hosted-with-matrix/

[greenship24]

If you self host synapse: https://unifiedpush.org/users/troubleshooting/self-hosted-with-matrix/

Well- this solved it for me. I guess I hadn't even thought of this but when you see the blacklist defaults to RFC1918 it makes sense.

Thanks @p1gp1g !

[onetimecontributor]

For those, who are using public ntfy.sh and matrix servers, and get "no push distributors found" as for some reason Element X doesn't register (re-create) default subscription (upon ntfy app cache/data cleanup, restart, reboot, etc), you may try UP's test app

After I've installed it, default subscription re-appeared in ntfy app (with another "test subscription" needed for) and now all notification tests in EXA app are passing again.

[wshanks]

Notifications for messages are working for me on grapheneOS with Element X and ntfy from F-Droid, using matrix.org and ntfy.sh servers. However, notifications are not working for Element calls. Is that a known issue?

[p1gp1g]

Notifications for messages are working for me on grapheneOS with Element X and ntfy from F-Droid, using matrix.org and ntfy.sh servers. However, notifications are not working for Element calls. Is that a known issue?

UI Notifications and push notifications are 2 different things

[wshanks]

Notifications for messages are working for me on grapheneOS with Element X and ntfy from F-Droid, using matrix.org and ntfy.sh servers. However, notifications are not working for Element calls. Is that a known issue?

UI Notifications and push notifications are 2 different things

With Element X installed from Google Play on stock Android, the phone quickly wakes up with a notification when a call is started. Is that not triggered by a push notification? With my de-Googled setup, there is no wake up, though there is for a direct message (so the workaround of asking others to message before calling is not so bad).

[p1gp1g]

Allow Element X to use battery without any restriction then

[wshanks]

Allow Element X to use battery without any restriction then

Thanks for the suggestion but that doesn't help in my case. I found your comments terse and hard to follow. Then I found this comment from you and the surrounding thread, and I think I understand the issue your comments are getting at. From what I gather the call notification that appears in the Android UI is a UI notification, not a push notification, and can only be generated by an app that has not been backgrounded. With battery optimizations, UnifiedPush can not wake the app in order for it to generate this UI notification. With battery optimizations disabled, perhaps it could be possible for Element to poll for calls and issue a foreground UI notification (though it didn't work for me; perhaps it would work if I disabled UnifiedPush completely and Element X went back to polling). From that thread, it sounded like perhaps one day a call could produce a push notification that could lead UnifiedPush to wake Element and generate a call notification, but I am not sure.

[Unambiguous]

I had a similar issue with the notifications as OP. I self-host my own synapse homeserver and ntfy server. Both are available at my local domain local.domain.tld and run as docker containers.

The docker image used: matrixdotorg/synapse:latest

All troubleshooting tests inside the Element applications passed, all settings on the phone were correct and the notifications did not work. I started to dig through the homeserver.log and found the following errors:

Error sending request to  POST https://ntfy.local.domain.tld/_matrix/push/v1/notify: DNSLookupError no results for hostname lookup: ntfy.local.domain.tld

After investigating the DNS resolvers inside the container I found out that the nameservers were hard-coded inside the container. The contents of /etc/resolv.conf was the following:

nameserver 8.8.8.8
nameserver 8.8.4.4

After setting the correct local DNS server on the container and restarting, the DNSLookupError disappeared from the log and a new one appeared:

synapse.http.client - 215 - INFO - sentinel - Blocked 192.168.x.xxy from DNS resolution to ntfy.local.domain.tld

This was resolved by allowing both the IP addresses of the DNS server and the ntfy server in homeserver.yaml:

ip_range_whitelist:
  - '192.168.x.xxz' # ntfy server
  - '192.168.x.xxy' # dns server

Finally after this the notifications have started appearing on the phones. I really don't understand why are those Google nameservers hard-coded in the docker image.

I hope this helps anyone who is still struggling with notifications on a completely local infrastructure.