Add support for WebSockets

[jakubkoci]

I needed to do the following changes (solved by #231):

• Add return_route parameter to outbound when there is no inbound connection (there is no service with endpoint other than didcomm:transport/queue)
• Add keylist-update-response message and handler, just with naive implementation.
• Extract outboundTransporter as direct dependency in Agent’s constructor.

Next steps on the way to support WebSockets transport I would like to do:

• Extract also inboundTransporter from Agent’s constructor. (I can perhaps do it as part of this PR, but the changes started growing and I wanted to share what I have now.) (solved by refactor: extract inbound transporter from agent constructor #245)
• Take outbound endpoint from DidDoc.
• Add WebSocket transporters.
• Add TransportService to keep info about current transport channels.
• Allow to set more inbound and outbound transporters. (see Add support for multiple transports #268)

Next steps I see we will need to do someday in near future but not necessarily before or right after adding the WebSockets (solved by #231):

• Update download messages functionality to process batch message and to remove sendAndReceiveMessage that is still implemented in the old way relaying on synchronicity of HTTP request-response.

[jakubkoci]

@TimoGlastra @JamesKEbert Is there any specification about how a mediation recipient should make a connection with a mediator? I'm asking mainly about the part about how the recipient is supposed to get the connection invitation, the rest is connection protocol of course.

[TimoGlastra]

Not an exact specification. Couple of routes we could take:

• Add mediator invitation as startup parameter. In ACA-Py you can specify --mediator-invitation to connect and request mediation afterwards
• Use a public did as implicit invitation. E.g. using a did:sov or did:web:example.com to resolve the service endpoint and send a request afterwards.
  • either as startup config { "mediatorDid": "did:sov:xxxxx" }
  • or dynamically after startup
    • create connection with public did
    • request mediation from connection created with public did

I think it would be cool to have the mediator expose a did:web containing the service endpoint (sort of like trinsic: https://trinsic.id/.well-known/did.json, but they don't use it for their mediation endpoint).

So as a starter maybe just use an invitation config parameter? ACA-Py adds the endpoint to the public did sov after startup. So we should be able to connect using just a DID. However to be able to resolve the endpoint from a did we need to do some extra work. Mainly resolving the did from ledger, retrieving the ATTRIB, so we can read the endpoint. Basically constructing a did document from the did:sov as https://dev.uniresolver.io/ does.

[TimoGlastra]

I think it would be cool to have the mediator expose a did:web containing the service endpoint (sort of like trinsic: trinsic.id/.well-known/did.json, but they don't use it for their mediation endpoint).

ACA-Py has a PR open for did:web: hyperledger/aries-cloudagent-python#1143

[JamesKEbert]

Interesting, I hadn't considered using an implicit invitation with a public DID.

As of right now the primary method in ACA-Py AFAIK has been generating a multi-use invitation to kickstart the process. This could be a single-use of course as well, but multi-use has been the most well used.

My thought process for the methods in which you could make the connection and request mediation with the mediator would be:

• A startup parameter (would be quite useful for configuring projects). This could either be:
  • An invitation url/json
  • Or a public DID as an implicit invitation. (this would likely need to be some follow-up work as indicated above)
• Passing an invitation url to the mediation module that then creates the connection and follows up with the mediation request. (would be useful for adding a mediator at runtime -- user scans mediator QR Code, etc)
  • Also could use an implicit invitation as above.
• Requesting mediation from an existing connection (supports some edge cases here, such as if you need to explicitly perform the connect and mediation request steps separately)

So, I think this lines up with @TimoGlastra's thoughts above (let me know if I'm wrong).

[jakubkoci]

Thanks, guys for your ideas. I'm not sure if I understand "use an invitation config parameter" correctly. Would it work for the edge agent running in a mobile app? I like the idea with did:web and .well-know/did.json.

I created a new issue #371 because it's unrelated to WebSockets. We can continue there and I'm closing this one. The rest of the work mentioned in the description of the issue is also being worked on in a separate issue #268.