Update POST /identifiers/name/exchanges endpoint to report recp field in POST body

[pfeairheller]

The POST body for this endpoint currently looks like this (due to the addition of the top level rp field):

{
   exn: {
      a: {
         ...,
         i: "RECIPIENT"
      },
      rp: "RECIPIENT",
      ...
   },
   recp: ["RECIPIENT"]
}    

This endpoint should be updated to use the field inside the exn and thus removing the body field recp.

Also, address the question from @lenkan WebOfTrust/signify-ts#267 (comment)

[Arsh-Sandhu]

@pfeairheller isn't the recp field in body required to set the multisig member AID when sending an exn message asking multisig members to join an operation?

[pfeairheller]

@pfeairheller isn't the recp field in body required to set the multisig member AID when sending an exn message asking multisig members to join an operation?

The code should be switched to use the ri field in the exn message instead.

[iFergal]

The only issue here with multi-sig is for each participant you will need to make a Signify <-> KERIA call instead of just 1.

@pfeairheller Does ri need to be defined for messages between multi-sig members, and match the local identifier of each recipient? If ri is different for each member - so different exns are being sent - it breaks one of the signify tests for /multisig/rpy notifications appearing.

[lenkan]

@iFergal do you have a link to which test is breaking at which assertion due to that?

[iFergal]

@lenkan I'd like to find time to dig into it but it might be because the SAIDs are different. https://github.com/WebOfTrust/signify-ts/actions/runs/10580083902/job/29314065407

 FAIL  examples/integration-scripts/multisig-vlei-issuance.test.ts (43.885 s)
  ✕ multisig-vlei-issuance (42765 ms)

  ● multisig-vlei-issuance

    No notifications with route /multisig/rpy

      492 |
      493 |         if (!notes.length) {
    > 494 |             throw new Error(`No notifications with route ${route}`);
          |                   ^
      495 |         }
      496 |
      497 |         return notes;

      at utils/test-util.ts:494:19
      at async retry (utils/retry.ts:34:28)
      at async waitAndMarkNotification (utils/test-util.ts:468:19)
      at async Object.run (multisig-vlei-issuance.test.ts:458:9)

[iFergal]

Based on todays dev call - some reliance in KERIA for the SAID of the messages to multisig members to be the same, so the rp field should be the multisig identifier instead of individual member identifiers. This for me is good so there's just 1 Signify <-> KERIA call.

However @pfeairheller I just realised in this case we cannot get rid of the recp body field. Perhaps we can close this issue?

[lenkan]

@iFergal You mean that the recp field needs to stay to include the multisig participant AIDs explicitly? What happens if you just send it to the multisig AID?

For example, when you create an ipex grant and send it to a multisig aid, all the participants would get it. So I was wondering if that same logic would apply here for the multisig exn messages.

[iFergal]

@lenkan I think you are talking about for example, issuer sends grant to multisig identifier. In this case, it sends it to all the authorised endpoints in the OOBI that was resolved by the issuer. That may or may not be all the member agents.

That's a bit different than explicitly sending it to the local group members from another member (in which case you know all of the agents) but maybe we could leverage that.

An alternative that might be cleaner and still satisfy this issue is if in KERIA we check if rp is a local group hab and then auto send it to the participant endpoints, irrespective of the endpoint auth on the larger multisig OOBI.

[lenkan]

@iFergal Right. Yeah, I knew it was different scenario, but I thought maybe the implementation was similar. But I didn't think of the part that it probably depends on when the AID was resolved by an OOBI.

An alternative that might be cleaner and still satisfy this issue is if in KERIA we check if rp is a local group hab and then auto send it to the participant endpoints, irrespective of the endpoint auth on the larger multisig OOBI.

Nice. From the point of view of a user of the API, this sounds clean to me.