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.

Relationships

• Authentication: can be used to authenticate both parties and establish sender authenticated encryption.

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.
• Receiver: receives 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
}

Field	Description	Required
payload	Any valid JSON text.	✔

Examples

1. Send a single string:

{
  "payload": "Hello, world"
}

2. Send a single number:

{
  "payload": 42
}

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

Code	Message	Description
e.p.msg.iota.post.reject-post	post	Receiver 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.

Related Work

• Aries Hyperledger: https://github.com/hyperledger/aries-rfcs/blob/main/features/0095-basic-message/README.md