Support WebSockets Transport for DID Comm

[FabioPinheiro]

Transport via WebSocket

DID Comm is supposed to be Transport-agnostic
Notes from the official specification

Value brief

The main intended values to implement this feature are:

• efficiency - Websocket is an efficient way to send several messages with no TPC overhead.
• new use cases - by having a two-way channel of communication:
  • Avoid polling and remove the overhead of individual requests.
  • Near real-time communication
  • Multiplexing networking - using one single transport to have multiple conversations (different instance executions of protocols, or even using multiple identities).
  • Network Hub - Creation of a virtual hub or broadcast network between multiple participants
  • Ex: Live Mode in the Message Pickup Protocol

Implementation notes

The path will be https://<mediator>/ws. The creation of a WebSocket starts with the GET request with some headers. But since the GET on the root path, https://<mediator>/ its already used be a mediator’s website. Plus many proxies and libraries probably wouldn't support the distinction between getting the website and trying to create the WebSocket.

The header content-type with application/didcomm-encrypted+json will NOT be necessary since browsers do not support custom headers on WebSockets.

Support new transportation layer WebSockets.
It will work similarly to the HTTP post as defined on the DID Comm specification. So the client creates a WebSocket to be used as a one-way channel, to send messages from the client to the server.
When the message is the return_route flag (with all/thread) the same WebSocket would be used to get the reply as specified on the DID Comm Book - extension return_route.

The infrastructure also needs to be configured for the Proxy to support WebSockets

Is not clean from the specs the best way to support back pressure. In extreme conditions, messages can be lost without the WebSockets break. Another possible scenario, depending on implementation, is that the client is blocked because it's not able to send data via TCP.
To have better control let's have a small buffer with a configurable size controlled by us to store incoming messages while messages are being processed.

We need to keep internal metadata manage open WebSockets:

• Who is on the other side of the WebSockets?
  • Unknown - there is no previous message.
  • Set[DID] - one or more subjects based on the previous encrypted message sent.
• For each DID where was the last message with the flag return_route=all.
• For each Par(DID,thread) where was the last message with the flag return_route=thread.

Bloking

This ticket unblocked the implementation of the Live Mode in the Message Pickup Protocol

[FabioPinheiro]

The infrastructure also needs to be configured for the Proxy to support WebSockets

[FabioPinheiro]

The first step is done (update the HTTP lib) -> #165