Define concept for native mobile notifications

[rodvar]

Discussion created out of #8

The notifications concept for Bisq 2 is based on desktop notifications, which obviously is not appropriate to mobile.

We should define the concept how to use mobile notifications and consider privacy-protecting solutions.

I'll put my comments from the Matrix discussion here and comment a bit more on the rationale

We need to define first what notifications are we interested in and consider that we probably want the user to be able to turn them on/off (this is integrated with the OS these days). In my head I've got the idea that we want to include for the MVP any notifications related to ongoing trades only as a must (things like "fancycat" has taken your sell offer!" and a tap takes you to the details) and optionally direct chat messages?

in terms of notification impl, I would just had the service responsible for showing the notifications observing a device storage we have for that purpose, and then any controller/service in the app that wants the user to be notified simply has to use the component that writes to that storage. That would be my approach.
To levarage the notifications system of each platform, we'll need to do some OS setup. KMP alraedy has some libs implemented that make it easier to do this, we'll have to R&D this when the time comes.

re We should define the concept how to use mobile notifications and consider privacy-protecting solutions. , what would be the privacy concerns? Notifications will be based on bisq activity and controlled within the app code.

[HenrikJannsen]

Overview

Assuming the typical use case for notifications is when a new trade message or a private chat message has been sent to an offline mobile user.

The trade message is stored in the P2P network as mailbox message. The only identifier is the key ID (receiverKeyId in ConfidentialMessage). When the receiver goes online they receive all mail box messages and filter for those where the receiverKeyId is equal to one of the key ID of the receiver. Thus avoiding to try to decrypt all mailbox message but only those which are dedicated to the receiver.

As the full node model with clearnet receives all messages as mailbox message due the intrinsic relay functionality, we would need some mechanism to avoid that the mobile user gets notifications when being online. As the mobile user removes those received mailbox messages after having received it and that can be expected to happen in a short time period, we could simply add some delay before sending the notification.

As the notification service has privacy implications it should be deactivated by default and the user gets information about the implications when activating that feature.

Notification services

The service will receive a notification message and the mobile device token. Thus the service will learn about the device owner using a Bisq application (knows that already by installation via Applestore/Playstore) and the timing of those messages (could potentially correlate blockchain data, e.g. peer send Bitcoin and then send the message, thus the 2 events have a time correlation).

Notification message

We could use the notification message without any payload and use it as signal message only, so the user knows something relevant happened to him (not knowing if its a private chat message or a trade message).

If we want to add data, we either increase the privacy implications (the service learns about the payload) or encrypt it but then the mobile OS cannot display the message as it cannot decrypt it, thus having the same effect as the pure signal option.
When the user opens the Bisq app they will receive anyway the data from the network or API requests and will learn about the originating message.

Andoid

We could use Google's Firebase Cloud Messaging (FCM), a user-hosted service, a Bisq-hosted service , a community-hosted service or some 3rd party alternatives.

A user self hosted service would remove the privacy issues though comes with the cost to run such a service. Not many users will do that probably, but if the effort to support that option is not high we should support it.

Using a Bisq-hosted service would mitigate the privacy leaks to Google/3rd party, but comes at the cost of running new infrastructure and securing the trust in it with a bonded role. It is questionable to me if the tradeoff pays off here.

For the thin client model we could add the notification service to the full node serving the client node. Though it is likely better to keep those 2 services as independent applications. A user running the full node on a VPN can also run their self hosted notification service.

Apple

For iOS Apple Push Notification Service (APNs) is used. It seems there are no alternative available.

Bisq notification relay (BNR)

A server application which allows subscriptions of a key ID and device token.
I think the existing Bisq notification relay node could be used as template or maybe even re-used/adjusted.

Privacy implications:

The node learns about the connection of a key ID and the device token.

User could run their own BNR to avoid those implications.

Flow

• Mobile user registers with it's device token and it's key ID
• When the service sees any mailbox message with the registered key ID it looks up the associated device token and send a notification request to the notification service
• Mobile user receives the notification from the notification service (FCM, APN,...).
• User opens Bisq app and receives data from the p2p network or Rest API requests.