Proposal for Message Pickup v4 #110
Conversation
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
| publisher: JamesKEbert | ||
| license: MIT | ||
| piuri: https://didcomm.org/message-pickup/4.0 | ||
| status: Production |
There was a problem hiding this comment.
I feel we might need a somewhat more sophisticated process to advance didcomm protocols.
Because protocols are immediately versioned 1.0 (or another major version) it means every slight change that needs to happen baed on implementation experience is a new version.
Would make sense IMO if protocols would stay in "draft" mode for a few months (e.g. 0.1 or 1.0-draft) where breaking changes can be made.
This way we don't end up with a lot of pickup protocols versions each slightly different than the previous one
We need some playtime with a protocol before it's "locked"
There was a problem hiding this comment.
I do tend to agree. I'd opt for introducing RFCs on a 0.1 version, as it makes a lot of sense to update from 0.1 to 1.0 once the RFC is finalized. Theoretically I think the RFC flow found in the Aries RFCs could also handle this via the status changes (PROPOSED -> DEMONSTRATED -> ACCEPTED -> ADOPTED -> RETIRED) wherein theoretically breaking changes could be made prior to moving it to ACCEPTED. I don't think that's worked in practice though.
On a related note, I find it troubling that we made new major versions of protocols that only supported DIDComm v2, as it essentially made any adjustments/fixes to protocols on DIDComm v1 impossible that required breaking changes (it's really odd to make a v2 for DIDComm v1, v3 for DIDComm v2, and then a v4 for DIDComm v1). I think it might be wise to have protocols have dual support (as proposed in this RFC or as seen in https://didcomm.org/media-sharing/1.0/), or have a mechanism in the protocol URI to indicate which DIDComm version is in use.
In this instance though, Pickup v2 was introduced in early 2022 and was implemented in AFJ/Credo in mid-2022 and similar timing for support in ACA-Py. So, given that it's been around for that long (and used in production/deployments for that long), I think in this instance it seems likely appropriate to me to have a new version. And Pickup v3 is basically just a reskin of pickup v2 but for DIDComm v2.
There was a problem hiding this comment.
We actually discussed this a good amount on one of the recent DIDComm UG calls--we agreed that starting a protocol at a 0.1 would be wise, but there were less immediate solutions available for subsequent versions (like in this case with v3->v4). One option discussed was adopting semver more closely, as it allows for something along the lines of 4.0.0-draft or 4.0.0-draft.2, etc. This would be ideal, but is a very major breaking change for protocol handler implementations.
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
|
As discussed in the DIDComm UG calls, I've updated the RFC with a changelog and made the adjustment to the behavior of handling a |
| --- | ||
|
|
||
| ## Summary | ||
| A protocol to facilitate a _Recipient_ agent picking up messages held at a _Mediator_. This protocol is likely to be used in tandem with the [cooridinate-mediation protocol](https://didcomm.org/coordinate-mediation/3.0/). |
There was a problem hiding this comment.
| A protocol to facilitate a _Recipient_ agent picking up messages held at a _Mediator_. This protocol is likely to be used in tandem with the [cooridinate-mediation protocol](https://didcomm.org/coordinate-mediation/3.0/). | |
| A protocol to facilitate a _Recipient_ agent picking up messages held at a _Mediator_. This protocol is likely to be used in tandem with the [Coordinate Mediation protocol](https://didcomm.org/coordinate-mediation/3.0/). |
| ## Roles | ||
| There are two roles in this protocol: | ||
|
|
||
| - `mediator`: The agent that has messages waiting for pickup by the `recipient`. |
There was a problem hiding this comment.
I guess there is a specific reason for it, but I don't see why the 'message holder' role has been renamed to 'mediator' in v2. Is Message Pickup protocol now only supported for a mediator/mediatee relationship? If that's the case, only the forwarded messages are supposed to be queued and packed in this protocol, or this applies also for any message sent from mediator to mediatee (e.g. keylist update response)?
Some time ago I had an use case where mobile agents without mediator would get credentials from an issuer: when connecting through regular HTTP, we were using Message Pickup in polling mode to check for credential issuance and other messages until the flow was finished. Do you think this is not an intended usage for this protocol?
There was a problem hiding this comment.
Some time ago I had an use case where mobile agents without mediator would get credentials from an issuer: when connecting through regular HTTP, we were using Message Pickup in polling mode to check for credential issuance and other messages until the flow was finished. Do you think this is not an intended usage for this protocol?
My current answer is that I think I would consider that to be outside the scope/intentions of this protocol. Given the already fairly involved nature of this protocol, my initial response is that I'd rather have a separate protocol dedicated to that particular use case so it can be more specific in its definitions and clarifications (especially given the troublesome, hard to troubleshoot issues observed with mobile message pickup over the years).
Also some context there according to my memory -- Pickup v2 was a completely fresh draft of the protocol that did not draw heavily from the v1 version (it was more based off of the implicit mechanisms being used with ACA-Py), but we thought it would be ideal to replace the initial version.
|
|
||
| `message_count` is the only **REQUIRED** attribute. The others **MAY** be present if offered by the `mediator`. | ||
|
|
||
| `longest_waited_seconds` is in seconds, and is the longest delay of any message in the queue. |
There was a problem hiding this comment.
Can you clarify a bit what does this attribute mean in this context?
There was a problem hiding this comment.
I think this is how long the oldest message has been waiting for delivery, but I do think it could use some clarification. @dbluhm do you know if this is supposed to mean something different than I described (since you've done significant amounts of implementation of these protocols)?
There was a problem hiding this comment.
Honestly speaking, I don't think I've ever implemented this portion. But yeah, I think it is the "age" in seconds of the oldest message on the queue.
| } | ||
| ``` | ||
|
|
||
| Messages delivered from the queue **MUST** be delivered in a batch delivery message as attachments, with a batch size specified by the `limit` provided in the `delivery-request` message. |
There was a problem hiding this comment.
If the message is not a response to delivery-request, how can the sender determine the batch size?
There was a problem hiding this comment.
Good catch, I'll add some clarifying terminology on this statement so that it only applies when in response to a delivery-request
There was a problem hiding this comment.
Feel free to critique the wording adjustments I made here in my last commit 👍
| } | ||
| ``` | ||
|
|
||
| `limit` is a **REQUIRED** attribute, and after receipt of this message, the `mediator` **SHOULD** deliver up to the limit indicated. |
There was a problem hiding this comment.
Since there is some message exchange overhead for every loop (delivery-request -> delivery -> messages-received -> status), I think it is important to keep loop number as minimal as possible. Is actually a limit by message number the best approach, or should we consider also the transport capabilities of the recipient (i.e. maximum single message size)?
A recipient would likely want to receive all messages at once, as long as they fit into a single message. So I'm wondering that we can combine this specified limit with the max_receive_bytes constraint, in such a way that the mediator should consider both when constructing each delivery message.
I think this could work nicely unless a certain queued message exceeds recipient's capabilities: in such case, the message would be stuck in the queue indefinitely. Shall the mediator reject any inbound message for a recipient if it exceeds its reported max_receive_bytes value?
There was a problem hiding this comment.
A recipient would likely want to receive all messages at once, as long as they fit into a single message. So I'm wondering that we can combine this specified limit with the max_receive_bytes constraint, in such a way that the mediator should consider both when constructing each delivery message.
My only concern here is regarding additional processing power/resources required on the mediator side to determine the number of messages attachable. Is the max_receive_bytes considered by the raw message size, or after packing for delivery (inside a delivery wrapper, and then inside a forward wrapper)?
I think this could work nicely unless a certain queued message exceeds recipient's capabilities: in such case, the message would be stuck in the queue indefinitely. Shall the mediator reject any inbound message for a recipient if it exceeds its reported max_receive_bytes value?
Perhaps that should actually be covered in the Mediation Coordination protocol? Since it sounds like it should be set up once and forgotten. But I do agree having some mechanism for indicating what is too large of a message is probably ideal.
|
|
||
| `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. | ||
|
|
||
| Upon receipt of this message, the `mediator` knows which messages have been received, and can remove them from the collection of queued messages with confidence. |
There was a problem hiding this comment.
I noticed in this section that it does not say anything about an updated status message sent as response for this message. This was explicitly mentioned in previous versions, so I'm wondering if this update intends to reflect that no further response is expected, or if it's just to not be too redundant (in Basic Walkthrough it is already stated it is a response)
There was a problem hiding this comment.
Good catch -- that should definitely go in the changelog
I believe this is motivated by the same complexity / ambiguity as to why we removed a status message as a followup to a delivery-request when no messages are queued for delivery, as it is unclear as to if it should be filtered by recipient_did or not (and actually can't be).
For example, in the following flow: status-request (restricted by recipient_did) -> status -> delivery -> messages-received -> status (NOT restricted by recipient_did, as there's no way to know that we were doing messages-received in regards to a filtered flow)
This may give the incorrect view that a given recipient_did has additional messages awaiting for pickup, but in reality they are for a different recipient_did.
If I'm missing something here, please say so
Signed-off-by: James Ebert <jamesebert.k@gmail.com>
|
Just double checking, is there any update on this? |
This is a proposal for message-pickup v4, motivated primarily by ambiguity when in live mode as to whether messages must still be delivered via
deliveryandmessages-received. It was determined that clarifying that they are required would be considered a breaking change -- #105.This is also an issue in DIDComm v1, which uses pickup v2, so this protocol introduces examples for both DIDComm v1 and DIDComm v2.
This also attempts to address minor inconsistencies or issues identified.
Open questions:
Should a- emptydelivery-requestthat has 0 queued messages return astatusmessage or an emptydeliverymessage? I lean towards yes as it reduces complexity (if astatusmessage is sent in response to adelivery-requestdue to an empty queue, and thedelivery-requesthad a filterrecipient_didspecified, does thestatusalso contain that?)deliverymessage was the consensus during DIDComm UG discussionSee related issues:
#105
hyperledger/aries-rfcs#760
#87