Webhooks for mediation protocol

[genaris]

When running an ACA-Py instance specifying a webhook-url, I can get all the webhooks related to all steps in connection (/topic/connections) and basic messaging protocols (/topic/basicmessaging) among other things. However, that is not the case for operations related to mediation, where I need to poll through the admin API to look for updates on them.

For a controller it can be of interest to receive notifications about mediation requests, and then, depending on the business logic, use admin API to grant or deny such requests. And the same could apply for the reception of these responses from a mediator, without the need to poll for mediation request status.

If this feature is already present, is there a particular configuration to enable it?

[dbluhm]

This feature is not yet present but should be a relatively simple addition. I definitely agree that this would be useful if not an outright requirement -- it was on our (Indicio/SICPA) to-do list but it got bumped down the list for the time being. I'd be happy to do a bit of coaching through a PR if you (or anyone else who could use this feature) has the drive to implement it.

[genaris]

Thanks, Daniel! Sure, this is something that we'll definitely need, so I think I can manage to work on that soon.

[airoasis]

@genaris Hi. Have you started to implement this feature already?

[TimoGlastra]

This is somewhat related to this issue, so posting here

We want to use ACA-Py as a mediator for mobile agents, and with it we also want to notify users of undelivered messages through push notifications. The idea is to add a custom DIDComm message to notify ACA-Py of device information required for push notifications (as implemented in .NET).

We'll need to be able to notify the controller of received forward messages, so the controller can in turn ping the push notification service. However I'd like to include in the forward webhook event, whether the message could be delivered directly (so we don't send push notifications for already processed messages).

@dbluhm Do you think this would be straightforward to add in ACA-Py? Seems like it may be hard to do with where this information is produced (in the transport layer)

We could just dismiss the notification on the mobile side, however I'm interested if we could handle it on the server side.

[dbluhm]

Yeah, I think this would be tricky at the moment. We would need feedback from the responder send methods which itself is probably going to be tricky due to the number of layers that get called between the responder and actually attempting to post a message.

Then again... One thing we recently added was making the inbound transport manager accessible to handlers. There might have to be some clever (read potentially ugly lol) code to get the timings right but we might be able to detect whether the message was pushed onto the undelivered queue or not. Or, perhaps it would make more sense for an event to be emitted somewhere in the transport mechanism...

I think emitting an event as you describe is extremely valuable and probably a near outright requirement for acting as a mediator for mobile agents. I'll do a bit more digging and see if any more straightforward solutions come to light.

[JamesKEbert]

It's worth mentioning that @TelegramSam and I have had some discussions as to how to potentially approach push notifications. We had been looking at utilizing Firebase as a mechanism for enabling push notifications. This would give us the capability of allowing push notifications to be an option for public mediators/open source mediators (such as Indicio's public mediator). So essentially enabling any mediation recipient who wants to receive push notifications with mediation can--without having to necessarily register that specific app.
We also wanted to do this in a way that was pluggable or modular--so potentially as a plugin in ACA-Py and a module in AFJ/Bifold. That way it helps provide a methodology of doing push notifications, but don't lock in the mechanisms of doing so.

[TimoGlastra]

We should have a call about this. We're currently working on a plugin for ACA-Py to do this but need to use Azure Notification Hub. Maybe we can come up with a general ACA-Py plugin that could be used independent of the notification service being used

[masojus]

Please include me in that call. Thanks.

[genaris]

Please include me in that call. Thanks.

I'm also interested! Actually I think it is something that needs to be part of an Aries RFC in the mid-term, as it will become more and more needed as new projects involving mobile agents are in development.

[mat-work]

This is somewhat related to this issue, so posting here

We want to use ACA-Py as a mediator for mobile agents, and with it we also want to notify users of undelivered messages through push notifications. The idea is to add a custom DIDComm message to notify ACA-Py of device information required for push notifications (as implemented in .NET).

We'll need to be able to notify the controller of received forward messages, so the controller can in turn ping the push notification service. However I'd like to include in the forward webhook event, whether the message could be delivered directly (so we don't send push notifications for already processed messages).

@dbluhm Do you think this would be straightforward to add in ACA-Py? Seems like it may be hard to do with where this information is produced (in the transport layer)

We could just dismiss the notification on the mobile side, however I'm interested if we could handle it on the server side.

Good initiative.

Please take into consideration that the device information, like push token, can change over time for some different reasons (e.g.: App update, re-installation, app restore, etc.) therefore it would be useful if the endpoint also supports modification/update of existing mobile information.
Not 100% sure, but I believe that the .Net framework does not support updating the record.

UPDATE on the .Net framework issue: hyperledger-archives/aries-framework-dotnet#181

[swcurran]

Closing this issue as I think the ACA-Py part of this is dealt with. If not, please reopen, or add a newer issue that is updated to current state.