Apps needs in terms of notifications

[rodvar]

Foreground

This is working out of the box. Ideally a different UI instead of showing the user a system notification, but for MVP we are ok like this.

Background

typical example is the user switch to another app (e.g. he received a notification from other app and clicked on it putting our app in background, or he received a phone call)

This is also working out of the box as long as the OS doesn't kill the app

App gets Killed

Either the user kills it or the OS does it for performance reasons, this is an scenario that needs to be consider in mobile.

For this scenario, we need to leave a service on that will continue to receive ongoing trades (either user offers that might receive a taker or trades that are open that involve the user) updates so that it can generate a notification that the user can click to return to the app. When the user returns to the app it should work normally as it would doing a fresh cold start.

Node

For the Node we only need Android Support, which has a specific component to tackle this case called "Foreground Service". If could manage to leave the bisq services that update the open trades on (linked to this foreground service currently called NotificationServiceController in the apps) that should do it because any updates that occur, the service will generate a system notification for the user to come back to the app and continue the trade

xClients

For the clients, the service that runs in the background even when the app gets killed would need to maintain WS comms with the bisq2 node and do the same thing stated above.

[rodvar]

@HenrikJannsen as per your request, see the above linked with #172 .

Let me know if you need any clarifications please

[HenrikJannsen]

When app is in foreground I guess its weird to get a system notification. Better to add some UI layer as we have in Bisq 2 with the notification badges or banner.

For iOS the suggested notification solution would not work as there is nothing like a ForegroundService available, right?

Moving all domain services into a ForegroundService might make the ForegroundService the main app. How would the interaction between the ForegroundService and the UI app work?

It seems Android made the ForegroundService more restrictive over time. As far I read our use case would not really match the intended use of ForegroundService. Also the user can stop it (from Android 10 on).
I think it would lead to battery drain if the node app is running basically as ForegroundService and users might get disappointed if they are not aware and not actively managing it. We should keep the non-technical newbies as our core target user group, and for them I guess it would be not a good UX if they find they phone battery drained after the started to use Bisq.

I am not sure if we need to support the case where the app got terminated. Bisq users also need to get back to their app when they have active trades open.

For the clients the backend node would send the notification as we do in Bisq 1 (sending it to a relay node). I guess we can re-use that relay infrastructure without much effort. The backend node can be expected to run constantly.

I would suggest:

• App in foreground: In-app notification layer/ UX element for active app notifications
• App in background: Use system notifications
• Node app terminated: Don't do anything. Maybe we need to communicate it to the user that if the app is not alive that they do not get notifications as there is no server involved which could send that.
• Client app terminated: Back-end node send notification via Bisq1 relay node (hides location of back-end node to notification services).

For the case that the back-end node send the notification we need to figure out how to let the back-end node know that the app is terminated. But I guess that should be easy as the websocket connection fails in that case.

For the terminated node app case, there might be another solution which would require more investigation if its feasible, but I want to share the rough idea:

We could run a foreground service but not as Bisq 2 domain services, but as a lightweight REST api client which polls in a certain interval from some Bisq 2 infrastructure node (like the oracle node or a new dedicated one) for mailbox messages. When starting the foreground the node app passes its key IDs which are used in the mailbox messages to identify which message is addressed to us. If any mailbox message arrives which has a matching key ID, the foreground service sends a system notification waking up the Bisq app. It does not know about the content as that would require the decryption key and the code base to de-serialize the protobuf message, but it knows that some message arrived for that user. Actually it would not require the mailbox message at all but only the key ID, so the REST API service could extract the key IDs of all mailbox messages send those as reply to the requester.

Such a service could alternatively run as a headless node, either by the user or as a Bisq service where mobile users could register for notifications, but that would have privacy issues as that node would learn about the correlation of the mobile users device ID and the key ID and with the frequency of the messages the activity level of that user.

[rodvar]

Thanks @HenrikJannsen . First of all I would like to get you on board with this -> To have a first class trading experience we need to have something that tells the user when a trade needs attention even if for whatever reason the app is not alive.

Think of any messaging app, or even trading apps, what would users say if this is not the case?

Now, with that in mind, I understand from your explanation that apparently (at least for the node) we would need to move all the services into the foreground service? That's definitely not ideal.. can you have a look at the current implementation I put in place for foreground service in mobile?

That implementation also works for the "kill app" sceneario if you comment out the onDestroying() implementation and the applicationService.deactivate() of the MainPresenter. This means, in the bug report, you would see the expected result.
The problem is that the app interaction ceases to work. So if we manage to fix that bug we might get there. Have a play with it its actually as per android official docs the most energy-efficient approach. Obviously if we need to move all the domain services there it can get tricky...

Finally, your latest idea sounds like a really good one. We can explore that one too.

[HenrikJannsen]

Think of any messaging app, or even trading apps, what would users say if this is not the case?

All those are centralized server based apps where such features are no no-brainer. For a fully decentralized UX like the node mode, its challenging. But as mentioned there might be some options what we can do.

There will be a trade off between convenience to get notifications and battery drain in case we would run the app basically as Foreground service. I would also expect major integration challenges to interact between UI process and Foreground service.

...can you have a look at the current implementation I put in place for foreground service in mobile?

We need to receive the p2p network messages, so for that we need the network service running as Foreground service. But that will be not enough as only the relevant domain services like TradeService would listen and process the relevant messages, thus it will pull in all core domain services with its dependencies.

So if we manage to fix that bug we might get there

This bug is not related to our challenges here. It is simply an open bug at the integration. Some domain service handling is missing...

as per android official docs the most energy-efficient approach.

When I asked ChatGPT about restrictions for Foreground services, it did not list concrete hard restrictions, but clearly stated that it is intended for limited resource consumption like GPS location update, etc. Music players might have a bit higher CPU consumption but I assume mobile CPUs have lot of optimization for that major use case and even if not, users who have their music running for hours are more aware that this will drain their battery, than a user who started Bisq, then put it into background or killed the UI app, but the Foreground service will keep running and after certain time the user gets frustrated that their battery is empty. I, as user would consider that as a bug and would de-install such an app, and would write negative reviews. I would not be surprises also if Google gets more strict and we would get problems with deployment as they might interpret that as abusive usage of the feature.

Finally, your latest idea sounds like a really good one. We can explore that one too.

I think that would be a very limited resource usage (compliant with the intention of Foreground services) and if the user reject permission for that it would not be fatal to the app (which would be another problem to the above scenario with putting the domain services in the Foreground service.

[rodvar]

@HenrikJannsen yes, for the node having a foreground service running everything is a no-go, it will drain the battery.

I'm thinking we could use something like the WorkManager scheduling period open trade verifications when there are open trades for the user. Turns out it can reliable run even if the app has been killed. The only case it won't work is if the user goes to the app settings and force-kill it which is very unlikely. And this would also work for iOS

I'll try to put together a quick version of this..

[rodvar]

@HenrikJannsen I think there is a way to do this using chain worker requests and the scheduling for WorkerManager (and there is a similar approach for iOS using . It would work something like this

Node

1. The app maintains a worker schedule of configurable frequency (default every 5 min?) that checks trades status only when the app is not in foreground in a chain fashion
2. When that worker schedule triggers it will run :
   i. a worker that ensures all needed services to check trades are on
   ii. a worker that checks trades status and notifies the user (using our push notification system) that there are trades that require his attention
   iii. a worker that does the cleanup if any (ideally we shutdown everything in a wake up -> check -> shutdown way)

Bisq Connect

Same as the above but one worker that does the WS interaction should be enough.

I'm validating if its still reliable now.

[HenrikJannsen]

For Node, from where the service should get the required data?

[rodvar]

In the implementation that was merged, is currently doing getting it from tradesServiceFacade.openTradeItem

would that still work in the approach above?

[HenrikJannsen]

So that only works as long Bisq core code is running, then the Bisq service can trigger the notification itself, no?

[rodvar]

It could as long as it considers all the stuff done in the OpenTradeService and the NotificationServiceController (or uses it)

Just posting here our chats on matrix - we might go with this first implementation for the MVP and iterate to improve it on later releases.