Skip to main content
Version: 0.6



The IOTA DIDComm Specification is in the RFC phase and may undergo changes. Suggestions are welcome at GitHub #464.

  • Version: 0.1
  • Status: IN-PROGRESS
  • Last Updated: 2021-10-29


Allows the sending of a single message with arbitrary data. Multiple post messages MAY be chained together in the same DIDComm thread to achieve bi-directional communication.


Example Use-Cases

  • Instant messaging between two parties, where the text payload is displayed in a chat.
  • IoT devices transmit sensor data to be aggregated in a central hub for processing.


  • Sender: sends the message.
  • Receiver: receives the message.



For guidance on diagrams see the corresponding section in the overview.


1. post

  • Type: iota/post/0.1/post
  • Role: sender

The sender transmits a JSON payload to the receiver. This MAY take advantage of sender authenticated encryption or be a signed DIDComm message or both.


"payload": JSON // REQUIRED
payloadAny valid JSON text.


  1. Send a single string:
"payload": "Hello, world"
  1. Send a single number:
"payload": 42
  1. Send a JSON object:
"payload": {
"status_code": 100,
"status": "Okay",

Problem Reports

The following problem-report codes may be raised in the course of this protocol and are expected to be recognised and handled in addition to any general problem-reports. Implementers may also introduce their own application-specific problem-reports.

For guidance on problem-reports and a list of general codes see problem reports.

CodeMessageDescription rejects a post message for any reason.


Since the payload JSON structure is unrestricted, a sender cannot make assumptions about receivers being able to understand the payload in any meaningful way unless both parties have a shared implementation or pre-negotiate the payload structure.

If complex and repeatable behaviour between parties is needed, implementors SHOULD define their own protocols with well-defined messages and interactions rather than using generic post messages.