Ambiguities on pickup protocol

FabioPinheiro commented 1 year ago

On the pickup protocol v3.0

Why is the 'thid' only shown in the example for delivery (Message Delivery type)? Does that mean that is the only place not optional?

Is not clear if messages-received message can exist without the 'thid' field.

Since the "message_id_list is a list of ids of each message received. The id of each message is present in the attachment descriptor of each attached message of a delivery message." and "The id is an opaque value, and the recipient should not infer anything from the value."

The recipient can not assume the 'id' is unique. The way that the protocols are described, the 'id' will only make sense in the reply.

IMO 'thid' should be optional on all message types of this protocol. Which means the execution of the protocol can start anywhere. But for that, the recipient needs to assume the attachment's 'id' is unique to the mediator.

In the Delivery Request, we have: If no messages are available to be sent, a status message MUST be sent immediately.

IMO we should just remove this line. Why are we changing the behavior in this condition (assuming that by immediately you mean instead) Sending a status doesn't bring any extra value. For the recipient is the same have a status saying that you have zero messages or have a delivery with zero messages. But for the developer implementing a state machine is more complicated.

FabioPinheiro commented 1 year ago

@rodolfomiranda I'm asking you. Since you are the one that initially wrote the protocol and implemented the Mediator.

cc @antonbaliasnikov @goncalo-frade-iohk

goncalo-frade-iohk commented 1 year ago

We had quite a bit of discussions around this and would be good to probably add more context to the Protocol. In my opinion the messages-received should not have thid. Since they are not a response to a delivery. I mentioned this use case:

If you send 10 delivery-requests all with different routing-did you will receive 10 delivery messages all with different messages as attachments.

As I see the recipient implementation can be batch all attachment.id received from all the previous delivery messages and return a single messages-received message to the mediator with all the attachments ids.

genaris commented 1 year ago

We had quite a bit of discussions around this and would be good to probably add more context to the Protocol. In my opinion the messages-received should not have thid. Since they are not a response to a delivery.

I agree on this. Even though it could be a good use-case something like: Delivery Request -> Message Delivery -> Messages Received -> Status, I don't see too much value on making the state machine more complicated. We will be more interested on the message_ids than the thread they belong to.

I also agree with @FabioPinheiro regarding using an empty delivery message as response for delivery-request when no messages are available. I guess this comes from a legacy Aries implementation where it was easier to handle it this way, but seems to me more consistent to respond all requests with the same type of message. I would actually also remove the need of responding with a status to a messages-received.

An additional thing I would like to point out here is the possibility of sending Delivery messages without thid when the protocol is working in Live Mode. This is a discussion we opened some time ago in https://github.com/hyperledger/aries-rfcs/issues/760. The protocol does not specify how messages received when Live Mode should be forwarded. One can assume that they must be wrapped in forward messages, but I see some benefits on using delivery to send them:

Mediator can buffer messages and send them in a batch instead of forwarding them individually. This can be useful in to do a better management of transport channel
Mediator can set the IDs for the messages and wait until the recipient sends the corresponding messages-received containing the message_ids before removing them from the queue

mepeltier commented 1 year ago

Regarding the empty delivery message vs. status, I had a thought that's been simmering since our call yesterday. As @TelegramSam mentioned, the status response to messages-received is intended to be unfiltered, even though delivery-requests can be filtered by recipient_did. If we keep that expectation for the possible status response to a delivery-request, there is a potential distinction between an empty delivery message and a status message. If the delivery-request filters messages, and no messages exist for that recipient_did, then an unfiltered status might report that messages exist on the queue for other recipient_dids. An empty delivery message wouldn't do that, unless I'm missing something.

genaris commented 1 year ago

Regarding the empty delivery message vs. status, I had a thought that's been simmering since our call yesterday. As @TelegramSam mentioned, the status response to messages-received is intended to be unfiltered, even though delivery-requests can be filtered by recipient_did. If we keep that expectation for the possible status response to a delivery-request, there is a potential distinction between an empty delivery message and a status message. If the delivery-request filters messages, and no messages exist for that recipient_did, then an unfiltered status might report that messages exist on the queue for other recipient_dids. An empty delivery message wouldn't do that, unless I'm missing something.

In such case, I think this should be clarified in the spec. From reading Message Reference section, I would think the status message sent as a response of delivery-request would have the same recipient_dids filter.

TelegramSam commented 1 year ago

In such case, I think this should be clarified in the spec. From reading Message Reference section, I would think the status message sent as a response of delivery-request would have the same recipient_dids filter.

This is a much better answer than I gave in the meeting yesterday.

decentralized-identity / didcomm.org

Ambiguities on pickup protocol #87