// This file has been generated by structbuf. Do not modify it!
import * as payload from './payload.js';
export {payload};

/**
 * # Device to Mediator Protocol
 *
 * This protocol describes the communication between Threema client and
 * mediator server.
 *
 * As transport protocol, WebSocket is used. Over this WebSocket connection,
 * messages both between the device and the mediator server (D2M) and between
 * the device and the chat server (CSP) are multiplexed.
 *
 * ## General Information
 *
 * **Encryption cipher:** XSalsa20-Poly1305, unless otherwise specified.
 *
 * All strings are UTF-8 encoded.
 *
 * ## Payload Format
 *
 * All messages are wrapped in the [`container`](ref:payload.container).
 *
 * Most payload messages contained within the container are encoded with
 * protobuf, with a few exceptions for messages that are sent very frequently
 * (proxying and reflection) and which use a more compact representation.
 *
 * ## Chat Server Proxying
 *
 * The chat server uses a TCP stream based protocol (chat server protocol /
 * CSP). To be able to proxy this protocol over the message based WebSocket
 * protocol, we need framing. Framed messages from/to the chat server are sent
 * using [`proxy`](ref:payload.proxy) messages wrapped in
 * [`container`](ref:payload.container).
 *
 * ## Size Limitations
 *
 * The device to mediator protocol currently allows for up to 65536 bytes
 * within a single message. To elaborate this down to encrypted device to
 * device messages, the limitations are:
 *
 * - 65536 bytes for a payload container struct,
 * - 65532 bytes for a payload struct, before wrapping it with a container,
 * - 65516 bytes for an encrypted `d2d.Envelope` in a
 *   [`reflected`](ref:payload.reflected) struct.
 * - 65492 bytes for the plain `d2d.Envelope` to be sent within a
 *   [`reflected`](ref:payload.reflected) struct.
 *
 * Note that the header lengths of [`reflect`](ref:payload.reflect) and
 * [`reflected`](ref:payload.reflected) are dynamic, so the maximum size of a
 * `d2d.Envelope` may be reduced further in the future.
 *
 * ## Version Negotiation
 *
 * The server sends along the highest supported protocol version in the
 * `ServerHello` message. The client then chooses a `ClientHello.version` <=
 * `ServerHello.version`.
 *
 * If the server version sent in `ServerHello` is unsupported by the client,
 * the client disconnects with a [close code](ref:index#close-codes) of 4110
 * (Unsupported Protocol Version).
 *
 * If the client version sent in `ClientHello` is unsupported by the server,
 * the server disconnects with a [close code](ref:index#close-codes) of 4110
 * (Unsupported Protocol Version).
 *
 * Otherwise, the version from `ClientHello.version` is used for further
 * communication.
 *
 * ## Close Codes
 *
 * WebSocket Internal Close Codes (1xxx):
 * - `1000`: Normal closure, connection successfully completed
 * - `1001`: Server is shutting down
 * - `1011`: Server terminated the connection due to an internal error
 *
 * Chat Server Close Codes (400x and 410x):
 * - `4000`: Chat server connection closed
 * - `4001`: Chat server connection could not be established
 * - `4009`: Internal error related to chat server connection
 *
 * Mediator Server Close Codes (40[1-9]x and 41[1-9]x):
 * - `4010`: Protocol error
 * - `4011`: Transaction TTL reached
 * - `4012`: Unknown message acked
 * - `4013`: Client idle timeout exceeded
 * - `4110`: Unsupported protocol version
 * - `4111`: Device limit reached
 * - `4112`: Duplicate connection (i.e. the same device reconnected,
 *   terminating the previous connection)
 * - `4113`: Dropped by other device
 * - `4114`: Dropped by server because the reflection queue length limit was
 *   reached
 * - `4115`: Device slot state mismatch
 *
 * Reconnect policy:
 * - `1xxx` and `40xx` do allow for automatic reconnect.
 * - `41xx` does not allow for automatic reconnect and require user interaction
 *   before a reconnect attempt may be made.
 * - Any other close code should result in a warning in the log, but automatic
 *   reconnects are allowed.
 *
 * Important: Whenever a `close-error` message is being received from the Chat
 * Server, the reconnect policy solely depends on the
 * `close-error.can-reconnect` field and the (following) Close Code must be
 * ignored.
 *
 * When automatically reconnecting, linear backoff should be applied. In case
 * the connection fails repeatedly, user interaction should be required to
 * continue reconnecting.
 *
 * ## Security
 *
 * The client must pin the TLS certificate of the server, so that the server
 * can be authenticated. The client authenticates itself during the handshake
 * with the server that it is part of the device group by responding to a
 * challenge.
 *
 * A malicious server can connect arbitrary devices with one another but this
 * would be detected eventually because decrypting reflected messages would
 * fail.
 */
