#### Here is my thoughts on this feature. I would really appreciate any comments, concerns or ideas. I have done work making this work as an agent protocol and think option 1 is the most valid strategy. Although I do have some concerns I outlined in the document.
---------------------------------------------------------
##### HackMD link --> https://hackmd.io/@GOCrY5e8TOSM65ME5EhgeQ/HkL9dFBi3/edit
---------------------------------------------------------
### **Option 1 - Integrate with a push notification service and manage push tokens in mediator.**

This will target firebase as the push notification service (fcm). Similar work would be required to use apple push notification (apn). Additional, but similar work would be needed to use one signal or expo services.

***Description:***

**Mobile App:**
* A firebase project would be created for bc wallet and the service would be integrated into the app. This would use the well maintained library `@react-native-firebase/app`. Some setup info here https://rnfirebase.io/. This requires loading config information as environment variables at build time.
* Using `@react-native-firebase/messaging` library. The app would create a background handler for handling notifications when the app is closed. It would create a foreground handler when app is in use. It could ignore the foreground notifications or have a simple toast notification.
* After login the app would get the firebase token and send it to the mediator using the library `@aries-framework/push-notifications`. Would need some logic for dealing with possible token changes on re-installs.

**Mediator Agent:**
* A new plugin would be created to handle the push notification (firebase) protocol. There was some work done as an RFC here https://github.com/hyperledger/aries-rfcs/blob/main/features/0734-push-notifications-fcm/README.md. It would be similar to this but the `@aries-framework/push-notifications` library is a little different. The protocol should match the extension library.
* The mediator agent would save the firebase token in the connection information.
* The plugin would include a service for sending push notifications. It needs to be configured with information from the firebase project and needs a firebase service account which would be loaded as env variables. Here is an example in python https://github.com/firebase/quickstart-python/blob/2c68e7c5020f4dbb072cca4da03dba389fbbe4ec/messaging/messaging.py#L26-L35
* This service could then be triggered from the mediator when messages arive for any connection which has a firebase token.

**Benefits:**
* Only have to configure the plugin for one agent.
* Can "instantly" notify the wallet user about received messages.

**Drawbacks:**
* The mediator doesn't know anything about the message. All it can do it send a notification saying something like `Your wallet received new information - Please open your wallet`. The mobile wallet could then read the messages and route the UI to the correct screen.
* What if the message isn't important? Will it bother the user to get a push notification and open the app?
* Quite a bit of setup.
* Need to create an android and ios app in firebase console. Then need to manage and load the `google-services.json` and `GoogleService-Info.plist` files at build time securely.
* Need to create and manage a firebase service account for the plugin and load the json securely at runtime.

**Possibilities:**
* Could the plugin open another protocol to allow external agents to send push notifications to mobile wallets with detailed information only when specific events happen? This "send" protocol is outlined in `rfcs/features/0734`.
* Could another agent seperate from mediator be created who's sole purpose was managing push tokens and sending push notifications?

### **Option 2 - Wake up app on schedule and check for messages**

***Description:***

The idea for this strategy is to have a background task that checks messages on a schedule and opens a local notification if there is message waiting for the user.

This option is left open without the details fully explored. If it's valid more work will be needed to explore the details.

**Benefits:**
* No need to use a push notification service. Configuration is simpler.
* Can get the decrypted message to add detailed information in the local notification.

**Drawbacks:**
* Authentication
* Is it possible to do this securely without the user providing their passcode?
* Notification will be delayed
* Some use cases may want to notify the user immediately. This wouldn't be possible using this strategy. Background tasks can only be scheduled every 15 mins.
* The app would use more battery. And this would increase with the background process inverval.