# MeshCore Payload Format Reference

## Payload Format

Inside each [MeshCore Packet](./packet_format.md) is a payload, identified by the payload type in the packet header. The types of payloads are:

- Node advertisement.
- Acknowledgment.
- Returned path.
- Request (destination/source hashes + MAC).
- Response to REQ or ANON\_REQ.
- Plain text message.
- Anonymous request.
- Group text message (unverified).
- Group datagram (unverified).
- Multi-part packet
- Control data packet
- Custom packet (raw bytes, custom encryption).

This document defines the structure of each of these payload types.

NOTE: all 16 and 32-bit integer fields are Little Endian.

### Important concepts:

- Node hash: the first byte of the node's public key

## Node advertisement

This kind of payload notifies receivers that a node exists, and gives information about the node

<table id="bkmrk-fieldsize-%28bytes%29des"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>public key</td><td>32</td><td>Ed25519 public key of the node</td></tr><tr><td>timestamp</td><td>4</td><td>unix timestamp of advertisement</td></tr><tr><td>signature</td><td>64</td><td>Ed25519 signature of public key, timestamp, and app data</td></tr><tr><td>appdata</td><td>rest of payload</td><td>optional, see below</td></tr></tbody></table>

Appdata

<table id="bkmrk-fieldsize-%28bytes%29des-1"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>flags</td><td>1</td><td>specifies which of the fields are present, see below</td></tr><tr><td>latitude</td><td>4 (optional)</td><td>decimal latitude multiplied by 1000000, integer</td></tr><tr><td>longitude</td><td>4 (optional)</td><td>decimal longitude multiplied by 1000000, integer</td></tr><tr><td>feature 1</td><td>2 (optional)</td><td>reserved for future use</td></tr><tr><td>feature 2</td><td>2 (optional)</td><td>reserved for future use</td></tr><tr><td>name</td><td>rest of appdata</td><td>name of the node</td></tr></tbody></table>

Appdata Flags

<table id="bkmrk-valuenamedescription"><thead><tr><th>Value</th><th>Name</th><th>Description</th></tr></thead><tbody><tr><td>`0x01`</td><td>is chat node</td><td>advert is for a chat node</td></tr><tr><td>`0x02`</td><td>is repeater</td><td>advert is for a repeater</td></tr><tr><td>`0x03`</td><td>is room server</td><td>advert is for a room server</td></tr><tr><td>`0x04`</td><td>is sensor</td><td>advert is for a sensor server</td></tr><tr><td>`0x10`</td><td>has location</td><td>appdata contains lat/long information</td></tr><tr><td>`0x20`</td><td>has feature 1</td><td>Reserved for future use.</td></tr><tr><td>`0x40`</td><td>has feature 2</td><td>Reserved for future use.</td></tr><tr><td>`0x80`</td><td>has name</td><td>appdata contains a node name</td></tr></tbody></table>

## Acknowledgement

An acknowledgement that a message was received. Note that for returned path messages, an acknowledgement can be sent in the "extra" payload (see [Returned Path](#returned-path)) instead of as a separate ackowledgement packet. CLI commands do not cause acknowledgement responses, neither discrete nor extra.

<table id="bkmrk-fieldsize-%28bytes%29des-2"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>checksum</td><td>4</td><td>CRC checksum of message timestamp, text, and sender pubkey</td></tr></tbody></table>

## Returned path, request, response, and plain text message

Returned path, request, response, and plain text messages are all formatted in the same way. See the subsection for more details about the ciphertext's associated plaintext representation.

<table id="bkmrk-fieldsize-%28bytes%29des-3"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>destination hash</td><td>1</td><td>first byte of destination node public key</td></tr><tr><td>source hash</td><td>1</td><td>first byte of source node public key</td></tr><tr><td>cipher MAC</td><td>2</td><td>MAC for encrypted data in next field</td></tr><tr><td>ciphertext</td><td>rest of payload</td><td>encrypted message, see subsections below for details</td></tr></tbody></table>

### Returned path

Returned path messages provide a description of the route a packet took from the original author. Receivers will send returned path messages to the author of the original message.

<table id="bkmrk-fieldsize-%28bytes%29des-4"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>path length</td><td>1</td><td>length of next field</td></tr><tr><td>path</td><td>see above</td><td>a list of node hashes (one byte each)</td></tr><tr><td>extra type</td><td>1</td><td>extra, bundled payload type, eg., acknowledgement or response. Same values as in [Packet Format](./packet_format.md)</td></tr><tr><td>extra</td><td>rest of data</td><td>extra, bundled payload content, follows same format as main content defined by this document</td></tr></tbody></table>

### Request

<table id="bkmrk-fieldsize-%28bytes%29des-5"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>timestamp</td><td>4</td><td>sender time (unix timestamp)</td></tr><tr><td>request data</td><td>rest of payload</td><td>application-defined request payload body</td></tr></tbody></table>

For the common chat/server helpers in `BaseChatMesh`, the current request type values are:

<table id="bkmrk-valuenamedescription-1"><thead><tr><th>Value</th><th>Name</th><th>Description</th></tr></thead><tbody><tr><td>`0x01`</td><td>get stats</td><td>get stats of repeater or room server</td></tr><tr><td>`0x02`</td><td>keepalive</td><td>keep-alive request used for maintained connections</td></tr></tbody></table>

#### Get stats

Gets information about the node, possibly including the following:

- Battery level (millivolts)
- Current transmit queue length
- Current free queue length
- Last RSSI value
- Number of received packets
- Number of sent packets
- Total airtime (seconds)
- Total uptime (seconds)
- Number of packets sent as flood
- Number of packets sent directly
- Number of packets received as flood
- Number of packets received directly
- Error flags
- Last SNR value
- Number of direct route duplicates
- Number of flood route duplicates
- Number posted (?)
- Number of post pushes (?)

#### Get telemetry data

Not defined in `BaseChatMesh`. Sensor- and application-specific request payloads may be implemented by higher-level firmware.

#### Get Telemetry

Not defined in `BaseChatMesh`.

#### Get Min/Max/Ave (Sensor nodes)

Not defined in `BaseChatMesh`.

#### Get Access List

Not defined in `BaseChatMesh`.

#### Get Neighors

Not defined in `BaseChatMesh`.

#### Get Owner Info

Not defined in `BaseChatMesh`.

### Response

<table id="bkmrk-fieldsize-%28bytes%29des-6"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>content</td><td>rest of payload</td><td>application-defined response body</td></tr></tbody></table>

Response contents are opaque application data. There is no single generic response envelope beyond the encrypted payload wrapper shown above.

### Plain text message

<table id="bkmrk-fieldsize-%28bytes%29des-7"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>timestamp</td><td>4</td><td>send time (unix timestamp)</td></tr><tr><td>txt\_type + attempt</td><td>1</td><td>upper six bits are txt\_type (see below), lower two bits are attempt number (0..3)</td></tr><tr><td>message</td><td>rest of payload</td><td>the message content, see next table</td></tr></tbody></table>

txt\_type

<table id="bkmrk-valuedescriptionmess"><thead><tr><th>Value</th><th>Description</th><th>Message content</th></tr></thead><tbody><tr><td>`0x00`</td><td>plain text message</td><td>the plain text of the message</td></tr><tr><td>`0x01`</td><td>CLI command</td><td>the command text of the message</td></tr><tr><td>`0x02`</td><td>signed plain text message</td><td>first four bytes is sender pubkey prefix, followed by plain text message</td></tr></tbody></table>

## Anonymous request

<table id="bkmrk-fieldsize-%28bytes%29des-8"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>destination hash</td><td>1</td><td>first byte of destination node public key</td></tr><tr><td>public key</td><td>32</td><td>sender's Ed25519 public key</td></tr><tr><td>cipher MAC</td><td>2</td><td>MAC for encrypted data in next field</td></tr><tr><td>ciphertext</td><td>rest of payload</td><td>encrypted message, see below for details</td></tr></tbody></table>

### Room server login

<table id="bkmrk-fieldsize-%28bytes%29des-9"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>timestamp</td><td>4</td><td>sender time (unix timestamp)</td></tr><tr><td>sync timestamp</td><td>4</td><td>sender's "sync messages SINCE x" timestamp</td></tr><tr><td>password</td><td>rest of message</td><td>password for room</td></tr></tbody></table>

### Repeater/Sensor login

<table id="bkmrk-fieldsize-%28bytes%29des-10"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>timestamp</td><td>4</td><td>sender time (unix timestamp)</td></tr><tr><td>password</td><td>rest of message</td><td>password for repeater/sensor</td></tr></tbody></table>

### Repeater - Regions request

<table id="bkmrk-fieldsize-%28bytes%29des-11"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>timestamp</td><td>4</td><td>sender time (unix timestamp)</td></tr><tr><td>req type</td><td>1</td><td>0x01 (request sub type)</td></tr><tr><td>reply path len</td><td>1</td><td>path len for reply</td></tr><tr><td>reply path</td><td>(variable)</td><td>reply path</td></tr></tbody></table>

### Repeater - Owner info request

<table id="bkmrk-fieldsize-%28bytes%29des-12"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>timestamp</td><td>4</td><td>sender time (unix timestamp)</td></tr><tr><td>req type</td><td>1</td><td>0x02 (request sub type)</td></tr><tr><td>reply path len</td><td>1</td><td>path len for reply</td></tr><tr><td>reply path</td><td>(variable)</td><td>reply path</td></tr></tbody></table>

### Repeater - Clock and status request

<table id="bkmrk-fieldsize-%28bytes%29des-13"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>timestamp</td><td>4</td><td>sender time (unix timestamp)</td></tr><tr><td>req type</td><td>1</td><td>0x03 (request sub type)</td></tr><tr><td>reply path len</td><td>1</td><td>path len for reply</td></tr><tr><td>reply path</td><td>(variable)</td><td>reply path</td></tr></tbody></table>

## Group text message

<table id="bkmrk-fieldsize-%28bytes%29des-14"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>channel hash</td><td>1</td><td>first byte of SHA256 of channel's shared key</td></tr><tr><td>cipher MAC</td><td>2</td><td>MAC for encrypted data in next field</td></tr><tr><td>ciphertext</td><td>rest of payload</td><td>encrypted message, see below for details</td></tr></tbody></table>

The plaintext contained in the ciphertext matches the format described in [plain text message](#plain-text-message). Specifically, it consists of a four byte timestamp, a flags byte, and the message. The flags byte will generally be `0x00` because it is a "plain text message". The message will be of the form `: ` (eg., `user123: I'm on my way`).

## Group datagram

<table id="bkmrk-fieldsize-%28bytes%29des-15"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>channel hash</td><td>1</td><td>first byte of SHA256 of channel's shared key</td></tr><tr><td>cipher MAC</td><td>2</td><td>MAC for encrypted data in next field</td></tr><tr><td>ciphertext</td><td>rest of payload</td><td>encrypted data, see below for details</td></tr></tbody></table>

The data contained in the ciphertext uses the format below:

<table id="bkmrk-fieldsize-%28bytes%29des-16"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>data type</td><td>2</td><td>Identifier for type of data. (See number\_allocations.md)</td></tr><tr><td>data len</td><td>1</td><td>byte length of data</td></tr><tr><td>data</td><td>rest of payload</td><td>(depends on data type)</td></tr></tbody></table>

## Control data

<table id="bkmrk-fieldsize-%28bytes%29des-17"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>flags</td><td>1</td><td>upper 4 bits is sub\_type</td></tr><tr><td>data</td><td>rest of payload</td><td>typically unencrypted data</td></tr></tbody></table>

### DISCOVER\_REQ (sub\_type)

<table id="bkmrk-fieldsize-%28bytes%29des-18"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>flags</td><td>1</td><td>0x8 (upper 4 bits), prefix\_only (lowest bit)</td></tr><tr><td>type\_filter</td><td>1</td><td>bit for each ADV\_TYPE\_\*</td></tr><tr><td>tag</td><td>4</td><td>randomly generate by sender</td></tr><tr><td>since</td><td>4</td><td>(optional) epoch timestamp (0 by default)</td></tr></tbody></table>

### DISCOVER\_RESP (sub\_type)

<table id="bkmrk-fieldsize-%28bytes%29des-19"><thead><tr><th>Field</th><th>Size (bytes)</th><th>Description</th></tr></thead><tbody><tr><td>flags</td><td>1</td><td>0x9 (upper 4 bits), node\_type (lower 4)</td></tr><tr><td>snr</td><td>1</td><td>signed, SNR\*4</td></tr><tr><td>tag</td><td>4</td><td>reflected back from DISCOVER\_REQ</td></tr><tr><td>pubkey</td><td>8 or 32</td><td>node's ID (or prefix)</td></tr></tbody></table>

## Custom packet

Custom packets have no defined format.