{ "componentChunkName": "component---src-templates-protocol-protocol-tsx", "path": "/messagepickup/4.0/", "result": {"data":{"markdownRemark":{"html":"

Summary

\n

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.

\n

Motivation

\n

This protocol is needed to facilitate retrieval of messages from a mediator in an explicit manner. Additionally, this protocol provides behavior for initiating live delivery of messages, which is crucial for good user experience for agents operating on mobile devices.

\n

Motivation for v4 of this protocol primarily stems from ambiguity in the pickup v2 protocol and messagepickup v3 protocol as to whether delivery and messages-received messages must be used while using live mode.

\n

Version Change Log

\n

4.0

\n\n

Roles

\n

There are two roles in this protocol:

\n\n

Requirements

\n

Return Route

\n

The return_route extension must be supported by both agents (recipient and mediator).\nThe common use of this protocol is for the reply messages from the mediator to be synchronous, utilizing the same connection channel for the reply. In order to have this synchronous behavior the recipient should specify return_route header to all.\nThis header must be set each time the communication channel is established: once per established websocket, and every message for an HTTP POST.

\n

DIDComm V1 Requirements

\n

When using this protocol with DIDComm V1, recipient_did MUST be a did:key reference.

\n

Basic Walkthrough

\n

This protocol consists of three different message requests from the recipient that should be replied to by the mediator:

\n
    \n
  1. Status Request -> Status
    2. \n
  2. Delivery Request -> Message Delivery -> Message Received
    3. \n
  3. Live Mode -> Status or Problem Report -> Message Delivery -> Message Received
    4. \n
\n

States

\n

This protocol follows the request-response message exchange pattern, and only requires the simple state of waiting for a response or to produce a response.

\n

Additionally, the return_route header extension must be set to all in all request submitted by the recipient.

\n

Basic Walkthrough

\n

The status-request message is sent by the recipient to the mediator to query how many messages are pending.

\n

The status message is the response to status-request to communicate the state of the message queue.

\n

The delivery-request message is sent by the recipient to request delivery of pending messages.

\n

The delivery message is the response to the delivery-request to send queued messages back to the recipient.

\n

The messages-received message is sent by the recipient to confirm receipt of delivered messages, prompting the mediator to clear messages from the queue.

\n

The live-delivery-change message is used to set the state of live_delivery.

\n

When Live Mode is enabled, messages that arrive when an existing connection exists are delivered over the connection immediately, via a delivery message, rather than being pushed to the queue. See Live Mode below for more details.

\n

Security

\n

This protocol expects messages to be encrypted during transmission, and repudiable.

\n

Message Reference

\n

Status Request

\n

Sent by the recipient to the mediator to request a status message.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/status-request

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/status-request\",\n    \"recipient_did\": \"<did:key for messages>\",\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/status-request\",\n    \"body\" : {\n        \"recipient_did\": \"<did for messages>\"\n    },\n    \"return_route\": \"all\"\n}\n
\n

recipient_did is optional. When specified, the mediator MUST only return status related to that recipient did. This allows the recipient to discover if any messages are in the queue that were sent to a specific DID. If using DIDComm v1, recipient_did MUST be a did:key reference.

\n

Status

\n

Status details about waiting messages.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/status

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/status\",\n    \"~thread\": {\n        \"thid\": \"<message id of status-request message>\"\n    },\n    \"recipient_did\": \"<did:key for messages>\",\n    \"message_count\": 7,\n    \"newest_received_time\": 1739420343823,\n    \"oldest_received_time\": 1739420343823,\n    \"total_bytes\": 8096,\n    \"live_delivery\": false\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"thid\": \"<message id of status-request message>\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/status\",\n    \"body\": {\n        \"recipient_did\": \"<did for messages>\",\n        \"message_count\": 7,\n        \"newest_received_time\": 1739420343823,\n        \"oldest_received_time\": 1739420343823,\n        \"total_bytes\": 8096,\n        \"live_delivery\": false\n    }\n}\n
\n

message_count is the only REQUIRED attribute. The others MAY be present if offered by the mediator.

\n

newest_received_time and oldest_received_time are expressed in UTC Epoch Milliseconds (Milliseconds since 1970-01-01T00:00:00Z) as an integer.

\n

total_bytes represents the total size of all messages.

\n

If a recipient_did was specified in the status-request message, the matching value MUST be specified in the recipient_did attribute of the status message.

\n

live_delivery state is also indicated in the status message.

\n

Note: due to the potential for confusing what the actual state of the message queue is, a status message MUST NOT be put on the pending message queue and MUST only be sent when the recipient is actively connected (HTTP request awaiting response, WebSocket, etc.).

\n

Delivery Request

\n

A request from the recipient to the mediator to have pending messages delivered.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/delivery-request

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/delivery-request\",\n    \"message_count_limit\": 10,\n    \"recipient_did\": \"<did:key for messages>\",\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/delivery-request\",\n    \"body\": {\n        \"message_count_limit\": 10,\n        \"recipient_did\": \"<did for messages>\"\n    },\n    \"return_route\": \"all\"\n}\n
\n

message_count_limit is a REQUIRED attribute, and after receipt of this message, the mediator SHOULD deliver up to the limit indicated.

\n

recipient_did is optional. When specified, the mediator MUST only return messages sent to that recipient did.

\n

If no messages are available to be sent, a delivery message with an empty attachments array MUST be sent immediately.

\n

Delivered messages MUST NOT be deleted until delivery is acknowledged by a messages-received message.

\n

Message Delivery

\n

Batch of messages delivered to the recipient as attachments.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/delivery

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/delivery\",\n    \"~thread\": {\n        \"thid\": \"<message id of delivery-request message>\"\n    },\n    \"recipient_did\": \"<did:key for messages>\",\n    \"~attach\": [{\n        \"@id\": \"<id of message>\",\n        \"data\": {\n            \"base64\": \"<message>\"\n        }\n    }]\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"thid\": \"<message id of delivery-request message>\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/delivery\",\n    \"body\": {\n        \"recipient_did\": \"<did for messages>\"\n    },\n    \"attachments\": [{\n        \"id\": \"<id of message>\",\n        \"data\": {\n            \"base64\": \"<message>\"\n        }\n    }]\n}\n
\n

Messages delivered from the queue MUST be delivered in a delivery message as attachments. If the delivery message is in response to a delivery-request message that specifies a message_count_limit, the number of attached messages MUST NOT exceed the message_count_limit specified in the delivery-request.\nThe id of each attachment is used to confirm receipt.\nThe id is an opaque value, and the recipient SHOULD NOT deduce any information from it, except that it is unique to the mediator. The recipient can use the ids in the message_id_list field of messages-received.

\n

If there are no messages in the queue for the delivery-request, the delivery message MUST contain an empty array of attachments.

\n

The ONLY valid type of attachment for this message is a DIDComm v1 or v2 Message in encrypted form.

\n

thid -- an optional field if the delivery message is in response to a singular delivery-request messsage.

\n

The recipient_did attribute is only included when responding to a delivery-request message that indicates a recipient_did.

\n

Messages Received

\n

After receiving messages, the recipient MUST send an acknowledge message indiciating which messages are safe to clear from the queue.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/messages-received

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/messages-received\",\n    \"message_id_list\": [\"123\",\"456\"]\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/messages-received\",\n    \"body\": {\n        \"message_id_list\": [\"123\",\"456\"]\n    }\n}\n
\n

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.

\n

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.

\n

Multiple Recipients

\n

If a message arrives at a mediator addressed to multiple recipients, the message MUST be queued for each recipient independently. If one of the addressed recipients retrieves a message and indicates it has been received, that message MUST still be held and then removed by the other addressed recipients.

\n

Live Mode

\n

Live Mode is the practice of delivering newly arriving messages directly to a connected recipient. It is disabled by default and only activated by the recipient. Messages that arrive when Live Mode is off MUST be stored in the queue for retrieval as described above. If Live Mode is active, and the connection is broken, a new inbound connection starts with Live Mode disabled.

\n

Messages already in the queue are not affected by Live Mode; they MUST still be requested with delivery-request messages.

\n

Live Mode MUST only be enabled when a persistent transport is used, such as WebSockets.

\n

If Live Mode is active, messages still MUST be delivered via a delivery message and the recipient MUST send an acknowledgement message messages-received. If a message is not acknowledged, the message MUST be added to the queue for later pickup.

\n

Recipients have three modes of possible operation for message delivery with various abilities and level of development complexity:

\n
    \n
  1. Never activate Live Mode. Poll for new messages with a status_request message, and retrieve them when available.
    2. \n
  2. Retrieve all messages from queue, and then activate Live Mode. This simplifies message processing logic in the recipient.
    3. \n
  3. Activate Live Mode immediately upon connecting to the mediator. Retrieve messages from the queue as possible. When receiving a message delivered live, the queue may be queried for any waiting messages delivered to the same did for processing.
    4. \n
\n

Live Mode Change

\n

Live Mode is changed with a live-delivery-change message.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/live-delivery-change

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/live-delivery-change\",\n    \"live_delivery\": true\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/live-delivery-change\",\n    \"body\": {\n        \"live_delivery\": true\n    }\n}\n
\n

Upon receiving the live_delivery_change message, the mediator MUST respond with a status message.

\n

If sent with live_delivery set to true on a connection incapable of live delivery, a problem_report SHOULD be sent as follows:

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/problem-report\",\n    \"~thread\": {\n        \"pthid\": \"<the value is the thid of the thread in which the problem occurred>\"\n    },\n    \"description\": {\n        \"code\": \"e.m.live-mode-not-supported\",\n        \"en\": \"Connection does not support Live Delivery\"\n    }\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/problem-report\",\n    \"pthid\": \"<the value is the thid of the thread in which the problem occurred>\",\n    \"body\": {\n        \"code\": \"e.m.live-mode-not-supported\",\n        \"comment\": \"Connection does not support Live Delivery\"\n    }\n}\n
\n

L10n

\n

No localization is required.

\n

Implementations

\n\n\n\n\n\n\n\n
Name / LinkImplementation Notes
\n

Endnotes

\n

Future Considerations

\n

The style of wrapping messages in a delivery message incurs an additional roughly 33% increased message size due to wrapping of the message. This size bloating is outweighed by the benefit of having explicit and guaranteed delivery of messages. This issue may be resolved in future versions of DIDComm.

\n

Should there be a strategy for a mediator to indicate support for Live Mode via discover features?

","frontmatter":{"title":"Message Pickup","tags":[],"license":"MIT","publisher":"JamesKEbert","status":"Production","piuri":"https://didcomm.org/message-pickup/4.0","summary":"A protocol to facilitate an agent picking up messages held at a mediator.","authors":[{"name":"Sam Curren","email":"telegramsam@gmail.com"},{"name":"James Ebert","email":"james@jamesebert.dev"}]},"fields":{"modifiedDate":"Wed Jul 22 2026 15:46:37 GMT+0000 (Coordinated Universal Time)","avatar":"https://avatars.githubusercontent.com/u/30242284?v=4&s=48","version":"4.0"}}},"pageContext":{"matchPath":"messagepickup/4.0/*","id":"f19d4ac6-1bbe-5471-88b2-52e3440211dd","html":"

Summary

\n

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.

\n

Motivation

\n

This protocol is needed to facilitate retrieval of messages from a mediator in an explicit manner. Additionally, this protocol provides behavior for initiating live delivery of messages, which is crucial for good user experience for agents operating on mobile devices.

\n

Motivation for v4 of this protocol primarily stems from ambiguity in the pickup v2 protocol and messagepickup v3 protocol as to whether delivery and messages-received messages must be used while using live mode.

\n

Version Change Log

\n

4.0

\n\n

Roles

\n

There are two roles in this protocol:

\n\n

Requirements

\n

Return Route

\n

The return_route extension must be supported by both agents (recipient and mediator).\nThe common use of this protocol is for the reply messages from the mediator to be synchronous, utilizing the same connection channel for the reply. In order to have this synchronous behavior the recipient should specify return_route header to all.\nThis header must be set each time the communication channel is established: once per established websocket, and every message for an HTTP POST.

\n

DIDComm V1 Requirements

\n

When using this protocol with DIDComm V1, recipient_did MUST be a did:key reference.

\n

Basic Walkthrough

\n

This protocol consists of three different message requests from the recipient that should be replied to by the mediator:

\n
    \n
  1. Status Request -> Status
    2. \n
  2. Delivery Request -> Message Delivery -> Message Received
    3. \n
  3. Live Mode -> Status or Problem Report -> Message Delivery -> Message Received
    4. \n
\n

States

\n

This protocol follows the request-response message exchange pattern, and only requires the simple state of waiting for a response or to produce a response.

\n

Additionally, the return_route header extension must be set to all in all request submitted by the recipient.

\n

Basic Walkthrough

\n

The status-request message is sent by the recipient to the mediator to query how many messages are pending.

\n

The status message is the response to status-request to communicate the state of the message queue.

\n

The delivery-request message is sent by the recipient to request delivery of pending messages.

\n

The delivery message is the response to the delivery-request to send queued messages back to the recipient.

\n

The messages-received message is sent by the recipient to confirm receipt of delivered messages, prompting the mediator to clear messages from the queue.

\n

The live-delivery-change message is used to set the state of live_delivery.

\n

When Live Mode is enabled, messages that arrive when an existing connection exists are delivered over the connection immediately, via a delivery message, rather than being pushed to the queue. See Live Mode below for more details.

\n

Security

\n

This protocol expects messages to be encrypted during transmission, and repudiable.

\n

Message Reference

\n

Status Request

\n

Sent by the recipient to the mediator to request a status message.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/status-request

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/status-request\",\n    \"recipient_did\": \"<did:key for messages>\",\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/status-request\",\n    \"body\" : {\n        \"recipient_did\": \"<did for messages>\"\n    },\n    \"return_route\": \"all\"\n}\n
\n

recipient_did is optional. When specified, the mediator MUST only return status related to that recipient did. This allows the recipient to discover if any messages are in the queue that were sent to a specific DID. If using DIDComm v1, recipient_did MUST be a did:key reference.

\n

Status

\n

Status details about waiting messages.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/status

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/status\",\n    \"~thread\": {\n        \"thid\": \"<message id of status-request message>\"\n    },\n    \"recipient_did\": \"<did:key for messages>\",\n    \"message_count\": 7,\n    \"newest_received_time\": 1739420343823,\n    \"oldest_received_time\": 1739420343823,\n    \"total_bytes\": 8096,\n    \"live_delivery\": false\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"thid\": \"<message id of status-request message>\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/status\",\n    \"body\": {\n        \"recipient_did\": \"<did for messages>\",\n        \"message_count\": 7,\n        \"newest_received_time\": 1739420343823,\n        \"oldest_received_time\": 1739420343823,\n        \"total_bytes\": 8096,\n        \"live_delivery\": false\n    }\n}\n
\n

message_count is the only REQUIRED attribute. The others MAY be present if offered by the mediator.

\n

newest_received_time and oldest_received_time are expressed in UTC Epoch Milliseconds (Milliseconds since 1970-01-01T00:00:00Z) as an integer.

\n

total_bytes represents the total size of all messages.

\n

If a recipient_did was specified in the status-request message, the matching value MUST be specified in the recipient_did attribute of the status message.

\n

live_delivery state is also indicated in the status message.

\n

Note: due to the potential for confusing what the actual state of the message queue is, a status message MUST NOT be put on the pending message queue and MUST only be sent when the recipient is actively connected (HTTP request awaiting response, WebSocket, etc.).

\n

Delivery Request

\n

A request from the recipient to the mediator to have pending messages delivered.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/delivery-request

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/delivery-request\",\n    \"message_count_limit\": 10,\n    \"recipient_did\": \"<did:key for messages>\",\n    \"~transport\": {\n        \"return_route\": \"all\"\n    }\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/delivery-request\",\n    \"body\": {\n        \"message_count_limit\": 10,\n        \"recipient_did\": \"<did for messages>\"\n    },\n    \"return_route\": \"all\"\n}\n
\n

message_count_limit is a REQUIRED attribute, and after receipt of this message, the mediator SHOULD deliver up to the limit indicated.

\n

recipient_did is optional. When specified, the mediator MUST only return messages sent to that recipient did.

\n

If no messages are available to be sent, a delivery message with an empty attachments array MUST be sent immediately.

\n

Delivered messages MUST NOT be deleted until delivery is acknowledged by a messages-received message.

\n

Message Delivery

\n

Batch of messages delivered to the recipient as attachments.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/delivery

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/delivery\",\n    \"~thread\": {\n        \"thid\": \"<message id of delivery-request message>\"\n    },\n    \"recipient_did\": \"<did:key for messages>\",\n    \"~attach\": [{\n        \"@id\": \"<id of message>\",\n        \"data\": {\n            \"base64\": \"<message>\"\n        }\n    }]\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"thid\": \"<message id of delivery-request message>\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/delivery\",\n    \"body\": {\n        \"recipient_did\": \"<did for messages>\"\n    },\n    \"attachments\": [{\n        \"id\": \"<id of message>\",\n        \"data\": {\n            \"base64\": \"<message>\"\n        }\n    }]\n}\n
\n

Messages delivered from the queue MUST be delivered in a delivery message as attachments. If the delivery message is in response to a delivery-request message that specifies a message_count_limit, the number of attached messages MUST NOT exceed the message_count_limit specified in the delivery-request.\nThe id of each attachment is used to confirm receipt.\nThe id is an opaque value, and the recipient SHOULD NOT deduce any information from it, except that it is unique to the mediator. The recipient can use the ids in the message_id_list field of messages-received.

\n

If there are no messages in the queue for the delivery-request, the delivery message MUST contain an empty array of attachments.

\n

The ONLY valid type of attachment for this message is a DIDComm v1 or v2 Message in encrypted form.

\n

thid -- an optional field if the delivery message is in response to a singular delivery-request messsage.

\n

The recipient_did attribute is only included when responding to a delivery-request message that indicates a recipient_did.

\n

Messages Received

\n

After receiving messages, the recipient MUST send an acknowledge message indiciating which messages are safe to clear from the queue.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/messages-received

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/messages-received\",\n    \"message_id_list\": [\"123\",\"456\"]\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/messages-received\",\n    \"body\": {\n        \"message_id_list\": [\"123\",\"456\"]\n    }\n}\n
\n

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.

\n

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.

\n

Multiple Recipients

\n

If a message arrives at a mediator addressed to multiple recipients, the message MUST be queued for each recipient independently. If one of the addressed recipients retrieves a message and indicates it has been received, that message MUST still be held and then removed by the other addressed recipients.

\n

Live Mode

\n

Live Mode is the practice of delivering newly arriving messages directly to a connected recipient. It is disabled by default and only activated by the recipient. Messages that arrive when Live Mode is off MUST be stored in the queue for retrieval as described above. If Live Mode is active, and the connection is broken, a new inbound connection starts with Live Mode disabled.

\n

Messages already in the queue are not affected by Live Mode; they MUST still be requested with delivery-request messages.

\n

Live Mode MUST only be enabled when a persistent transport is used, such as WebSockets.

\n

If Live Mode is active, messages still MUST be delivered via a delivery message and the recipient MUST send an acknowledgement message messages-received. If a message is not acknowledged, the message MUST be added to the queue for later pickup.

\n

Recipients have three modes of possible operation for message delivery with various abilities and level of development complexity:

\n
    \n
  1. Never activate Live Mode. Poll for new messages with a status_request message, and retrieve them when available.
    2. \n
  2. Retrieve all messages from queue, and then activate Live Mode. This simplifies message processing logic in the recipient.
    3. \n
  3. Activate Live Mode immediately upon connecting to the mediator. Retrieve messages from the queue as possible. When receiving a message delivered live, the queue may be queried for any waiting messages delivered to the same did for processing.
    4. \n
\n

Live Mode Change

\n

Live Mode is changed with a live-delivery-change message.

\n

Message Type URI: https://didcomm.org/message-pickup/4.0/live-delivery-change

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/live-delivery-change\",\n    \"live_delivery\": true\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/live-delivery-change\",\n    \"body\": {\n        \"live_delivery\": true\n    }\n}\n
\n

Upon receiving the live_delivery_change message, the mediator MUST respond with a status message.

\n

If sent with live_delivery set to true on a connection incapable of live delivery, a problem_report SHOULD be sent as follows:

\n

DIDComm v1 example:

\n
{\n    \"@id\": \"123456780\",\n    \"@type\": \"https://didcomm.org/message-pickup/4.0/problem-report\",\n    \"~thread\": {\n        \"pthid\": \"<the value is the thid of the thread in which the problem occurred>\"\n    },\n    \"description\": {\n        \"code\": \"e.m.live-mode-not-supported\",\n        \"en\": \"Connection does not support Live Delivery\"\n    }\n}\n
\n

DIDComm v2 example:

\n
{\n    \"id\": \"123456780\",\n    \"type\": \"https://didcomm.org/message-pickup/4.0/problem-report\",\n    \"pthid\": \"<the value is the thid of the thread in which the problem occurred>\",\n    \"body\": {\n        \"code\": \"e.m.live-mode-not-supported\",\n        \"comment\": \"Connection does not support Live Delivery\"\n    }\n}\n
\n

L10n

\n

No localization is required.

\n

Implementations

\n\n\n\n\n\n\n\n
Name / LinkImplementation Notes
\n

Endnotes

\n

Future Considerations

\n

The style of wrapping messages in a delivery message incurs an additional roughly 33% increased message size due to wrapping of the message. This size bloating is outweighed by the benefit of having explicit and guaranteed delivery of messages. This issue may be resolved in future versions of DIDComm.

\n

Should there be a strategy for a mediator to indicate support for Live Mode via discover features?

"}}, "staticQueryHashes": ["3000541721","3766577012"], "matchPath": "messagepickup/4.0/*"}