RFC 0685: Message delivery in Live Mode

[genaris]

As explained in the protocol, when Live mode is enabled and provided there is a persistent connection alive, the mediator must send any message for the recipient immediately.

My question is how the message should be delivered: should the mediator send the encrypted message (as it comes from the sender) through the transport, or shall it embed it into a Delivery message containing this single message? Even if it's not explicitly mentioned, based on previous implementations it seems evident that it should take the first approach.

However, while experimenting with WebSockets, I've seen that there are some situations where it might be important to have an application-level acknowledge (such as the provided by Delivery / Messages Received loop): if connection is closed abruptly by a party, the other end (at least on the application level) will only know about it once its ping/pong mechanism detects it or a lower-layer library/OS informs about it (usually after 30/60 seconds or more). And if it sends a message through the socket during that window, it won't notice about the delivery issue.

To put it in an example, it may happen that a mobile agent loses connectivity and, a few seconds after, a third-party sends a message to it through its mediator, so it forwards the message to the apparently opened WebSocket. However, the message does not arrive at destination and the mediator doesn't notice about that, effectively losing the message and leaving the responsibility of retrying the delivery to the upper-level DIDComm protocol.

By the way, my experience with this issue comes mostly from JavaScript environment, so maybe it's a a problem about a particular implementation, but according to some research I've done it seems to be a common issue with WebSockets, which is of course the typical transport to use in Live mode.

[swcurran]

Another related issue to this that we (BC Gov in concert with others) are working right now on is the horizontal scaling of a mediator, where a dropped connection from a mobile agent (perhaps because they switch networks from wifi to cell) results in a new connection to a new instance of the mediator. This means that in addition to detecting the messages did not get delivered, the messages probably need to go to a queue for delivery by any mediator instance.

[genaris]

Another related issue to this that we (BC Gov in concert with others) are working right now on is the horizontal scaling of a mediator, where a dropped connection from a mobile agent (perhaps because they switch networks from wifi to cell) results in a new connection to a new instance of the mediator. This means that in addition to detecting the messages did not get delivered, the messages probably need to go to a queue for delivery by any mediator instance.

Thanks for posting this @swcurran ! This is also a problem we've faced due to the exact same issue of suddenly dropping WebSocket connection.

Looking at current DIDComm V2 spec I found an interesting clause about rewrapping that could also be a solution for this: upon the reception of a Forward message, the mediator will re-wrap the payload into another Forward message for its mediatee, who will need to unwrap it and send an acknowledge. However, later in ACKs section it discourages the usage of acknowledges in forward messages, so maybe it's not the best idea.

By the way, I also found an interesting issue created by @andrewwhitehead where he makes some very good points about the importance of re-wrapping before forwarding messages. If we enforce using either Forward+Ack or Delivery+Messages-Received in this RFC, we will be covering these concerns.

[rodolfomiranda]

I think that it's still possible to use the message-received message in Live Mode. The Mediator should keep those messages sent in Live Mode in a separate queue until they are marked as delivered. Every time the Live Mode is re-enabled, the mediator should send all messages on that queue.