🔕 Debugging Notifications

Understanding Acter Notifications

Notifications are a particuarly thorny and complicated aspect of the Acter App. The reason for that is that several backend and external services are involved, passing around messages (or not) and we send only very limited data to ensure not leaking anything sensitive.

In particular we are – by default – only sending the event-id, room-id and the target-device (if the user has more than one account on the same device) and the receiving end is then responsible for fetching the actual information, potentially first decrypting and then showing it. For that we rely heavily on the rust matrix sdk notification client. Unfortunately, this is optimized for simplified sliding sync, which we have not yet support for and thus it might not be able to decrypt the information - in particular on iOS (see below).

General Infrastructure:

HomeServer -> Push Service -> external Service -> App

1. A message arrives at the HomeServer via federation or by a different client. The HomeServer checks the message against the users Set of PushRules (see below) and decides whether it is supposed to be forwarded. This is default Matrix-Spec behaviour
2. If it decides there should be a notification, the base details (room-id, push-type (invite or msg) and additional information) will be forwarded to the backend service the App configured. For mobile that is our Sygnal Service, on Desktop it uses our NTFY instance:
3. 1. Sygnal then uses the internal protocol to forward the notification to either Firebase (for Android) or Apple – these services then push the message to the client device if that is online.
   2. If it goes to our NFTY service for desktop, that service keeps a queue of messages for the client to fetch. It is a basic Pub-Sub-Service and messages are only delivered when Acter is online and able to fetch them

Understanding the Matrix PushRules

Yeah, it's complicated. Follows later

Setting up to test Notifications in Acter Dev

1. Make sure that you have the enven setup for the correct NFTY (for desktop) or Sygnal Service (for mobile). If you don't have the fields set, notification setup will just be ignored.
2. [iOS Only] If you are building an iOS version, you need access to the Team's signing keys. Make sure you are part of the Apple Developer Team and have the right account configured in your Xcode.
3. Check in your Acter App Settings that Notifications are activate for your device. Maybe also check your default settings and the notifications settings of the room you are using for testing.
4. Have a secondary account and send a message to the first account. By default all chats have notifications turned on, boosts are sending notifications as well.

That's it. Your next run of Acter is able to receive (Push) Notifications.

Notification Service on iOS simulator

Understanding the Notification Service

iOS has an external service extension that receives notifications if the app is not running. This extensions has various limitations, including run time and resources it can use, as such, this does not run the flutter environment but only a simplified swift version of our SDK.

Running the service on the Emulator

You need an iOS Emulator running. As well as a setup that ensure you are receiving push notifications (see above).

1. Build the SDK for iOS in debug mode
   in / do cargo make --profile release ios-sim
2. Then build the App for the emulator
   in app do flutter build ios --simulator --debug
3. Install the app on the emulator by running
   in app do flutter install ios
4. Start the App in the emulator by opening Acter, ensure that it receives Notifications while open

To make notifications go to the backend service:

1. Stop the App by going to the task manager and flipping it off screen.
2. Trigger another Push Notifications, observe what happens – this time it will go to the background service