feat: added support for DRPC protocol

[wadeking98]

Usage:

Send DRPC request and wait for response:

const listenResponse = await aliceAgentmodules.drpc.sendRequest(connectionRecord.id, {
  jsonrpc:'2.0', 
  method:'hello', 
  id:1
})
const response = await listenResponse()

After the listener sends the response, the sender will receive a curried function that will resolve to the response

Listen for DRPC request and send response:

const { request, sendResponse } = await faberAgent.modules.drpc.recvRequest()
await sendResponse({
  jsonrpc:'2.0', 
  result:'Hello', 
  id:1
})

DRPC notification

to send a DRPC notification simply set the id to be null
the response will then be an empty object

DRPC batch requests

DRPC supports sending multiple request objects over a single connection

const batchListen = await aliceAgent.modules.drpc.sendRequest(aliceConnection.id, [
  { jsonrpc: '2.0', method: 'hello', id: 1 },
  { jsonrpc: '2.0', method: 'add', params: [2, 3, 7], id: 2 },
  { jsonrpc: '2.0', method: 'parseFoo', params: { foo: 'bar' }, id: 3 },
  { jsonrpc: '2.0', method: 'error', id: 4 },
])
const batchResponse = await batchListen()

the response will be an array of DRPC responses

[amanji]

I may have interpreted the RFC differently, or maybe this is how it's intended to work in credo-ts, but in ACA-Py the agent doesn't directly handle the JSON-RPC object (i.e. it doesn't handle the RPC method execution) it simply forwards that through to a controller. The controller is responsible for handling the JSON-RPC accordingly and formulating a response that the agent will convey back.

I'm quoting this line from the Key Concepts of RFC 0804:

... The interpretation of the request, how to carry out the request, the content of the response, and the interpretation of the response, are all up to the business logic (controllers) of the participating agents...

Perhaps ACA-Py's implementation is more simplistic though, the agent simply handles the DRPC Request and Response messages and ensures it is valid in accordance with the JSON-RPC specification and the Aries DRPC Protocol.

[wadeking98]

The interpretation of the request, how to carry out the request, the content of the response, and the interpretation of the response, are all up to the business logic (controllers)

I think it might be stretching the RFC a little bit, but I think it's still within the bounds of the RFC and it provides a nicer interface for the controller from my perspective.

From one perspective the agent is kind of doing the RPC interpretation because the handler function is being executed by the agent... but from another perspective it's the controller that's handling RPC execution since it's the controller's function that's being passed into the agent and used as the RPC handler.

It seems to me it could be argued either way based on semantics, but ultimately its the business logic that defines the handler and so its the business logic that decides "how the request is interpreted", "how to carry out the request", etc. even though the agent is the one executing the handler.

[wadeking98]

Also the methodHandler approach provides some encapsulation which will make the business logic on the controller simpler. I'm open to forwarding all DRPC messages to the controller, but I think this approach makes things a bit tidier IMHO

[amanji]

The mechanism may still work with registering method handlers in the agent as you've implemented, so from that perspective it's just a different approach, not necessarily incorrect.

I'm just considering whether users would expect similar mechanics when encountering protocol implementations across the different frameworks, especially as described in the RFC. Ultimately, so long as the business logic can be handled or passed from outside the agent and will not constrain complex use cases, the protocol still works. Perhaps the wording in the RFC needs to be less prescriptive.

I don't think I have enough experience to give a definitive answer, or whether it matters to the community, so I would lean on them to weigh in. These are just my thoughts at a first glance.

Either way, I look forward to giving this a spin when's it's merged.

[amanji]

Also I didn't mean to post my first message three times 😅

[wadeking98]

Maybe we could get @swcurran 's opinion on this?

[genaris]

Thanks @wadeking98 ! I'm pretty excited about this new protocol and having it supported in Credo.

I've left a good amount of comments in the code but in general I think it will be important to put all this stuff in a separate module instead of adding it to core. It will need a bit of overhead but should not be hard if you take action-menu or question-answer as a base.

Other than that, I think the API is quite simple and I find interesting that you manage everything within the framework. It can be also a good idea to leave the possibility of handling methods from the controller side (e.g. a config setting that does not automatically respond according to the registered method handlers) but of course that can be left for a further PR in case is proven to be useful in real-world usage.

BTW I don't know what others think but I think 'DRPC' in class names should be changed to 'Dprc' to be more aligned with our coding style (e.g. classes with Did* or OpenId4Vc*

[wadeking98]

@genaris @TimoGlastra The validate CI Stage is failing after updating the module README for some reason but other than that it's ready for re-review

[TimoGlastra]

Did you run yarn format locally?

[wadeking98]

Did you run yarn format locally?

That did the trick, should be all ready now

[wadeking98]

@TimoGlastra @genaris would you mind doing a quick re-review when you have a second?

[berendsliedrecht]

Minor notes, mainly for consistency.

[genaris]

I have a few more comments but overall looks great!