Version: 0.6

# Post

##### info

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

## Overview​

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.

### Roles​

• Sender: sends the message.

### Interaction​

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

## Messages​

### 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.

#### Structure​

{  "payload": JSON // REQUIRED}
FieldDescriptionRequired
payloadAny valid JSON text.

#### Examples​

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
e.p.msg.iota.post.reject-postpostReceiver rejects a post message for any reason.

## Considerations​

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.