feat: Firebase Push Notifications Support

[al-rosenthal]

What's Changed

• .env.example updated with new firebase fields
• agent checks for and initializes firebase-admin
• Logic added for sending push notifications to device token from StorageMessageQueue.ts

[TimoGlastra]

Thanks for this! I think the custom patches and events are not needed and we should look at ways to work around them.

We can discuss it tomorrow at the Credo WG call in more detail

[TimoGlastra]

We shouldn't rely on patches to add features. Especially not now this is a OWF project.

Can we make sure the needed changes are made to Credo instead of patching? However we've not had the need for these patches, so i'm not sure if this is needed. We have an AgentMessageProcessedEvent, and probably better is to use the queue to know whether a message was processed.

@genaris any thoughts on how to approach this?

[sairanjit]

We can directly add the logic of sending the push notifications here https://github.com/openwallet-foundation/didcomm-mediator-credo/blob/main/src/storage/StorageMessageQueue.ts#L96

[genaris]

In general I don't like the approach of adding this custom messageType to Forward messages: it's not part of DIDComm spec, it needs custom sender agents to work, and of course (more importantly) it gives the mediator more information that it needs to know about recipient messages. I understand the reasons behind it (send Push notifications only when we receive meaningful messages), but it will be hard to convince me to add this into Credo's standard DIDComm module 😃.

I do think there are more appropriate ways of handling push notifications, although they require more work on the client side and they don't work as good as they would in a native mobile app. That being said, I think we can still find a way to allow this behaviour in Credo DIDComm module, probably by allowing middlewares for outbound messages in such a way we let users to modify/add fields to outgoing messages before they are sent to the transport.

In regards to the specific work in this PR, I agree that this behaviour could be achieved by hooking into AgentMessageProcessedEvent. This event will be triggered after processForwardMessage finishes, so it should work without the need of creating a new event.

[al-rosenthal]

Thanks for looking at this guys! I unfortunately wasn't able to make it to the meeting this morning but I'm looking forward to catching up with the video once it's uploaded.

In my testing, AgentMessageProcessedEvent never has the connection ID that I need to fetch the device token for the push notification, the connection object in the payload is always null. I might be trying to hook into it incorrectly, here is my example code:

  agent.events.on(AgentEventTypes.AgentMessageProcessed, async (event: AgentMessageProcessedEvent) => {
    agent.config.logger.info(`PN: Agent Message Processed: ${event.payload.connection?.id ?? 'no connetion id'}`)
    // send push notification
  })

the event is triggering but it is consistently logging 'no connection id'. I tried this with messages, credential offers and proof requests, but no connection id is present.

I'm happy to remove the patch, I do like the idea of adding it to the StorageMessageQueue as @sairanjit suggests, what do you guys think?