Get desktop application:
View/edit binary Protocol Buffers messages
Contact synchronisation message.
Used in:
Synchronisation type
Create a Threema contact
Update a Threema contact
Create a Threema contact.
Used in:
Update a Threema contact.
Used in:
Unique conversation identifier.
Used in:
, ,A contact's Threema ID, distribution list ID or group identity to identify the conversation.
Metadata about a device, determined by the device itself.
Random amount of padding, ignored by the receiver
Platform details (smartphone model / browser), e.g. "Firefox 91.0.2" or "iPhone 11 Pro"
App version, e.g. "4.52" (Android) or "4.6.12b2653" (iOS)
User defined device label (e.g. "PC at Work"), may be empty if not set. Recommended to not not exceed 64 grapheme clusters.
Platform
Used in:
Unknown platform
Android
Apple iOS
Desktop application
Web application
Distribution list synchronisation message.
Used in:
Synchronisation type
Create a distribution list
Update a distribution list
Delete a distribution list
Create a distribution list.
Used in:
Delete a distribution list.
Used in:
Unique ID of the distribution list
Update a distribution list.
Used in:
Root message
Random amount of padding, ignored by the receiver
Sender device id
D2D (`ProtocolVersion`) the device used when it sent this message. If `0`, assume V0.1 (`0x0001`).
The enveloped reflected message
Group synchronisation message.
Used in:
Synchronisation type
Create a group
Update a group
Delete a group
Create a group.
Used in:
Delete a group.
Used in:
Unique group identity
Update a group. When receiving this variant: 1. Let `current` be a snapshot of the current group state. 2. Persist the update to the group. 3. Let `member-changes` be an empty list. 4. For each `identity`, `state-change` pair of `member_state_changes`: 1. If `state-change` is `ADDED` and `identity` does not exist in `current.members`, add the tuple `identity`, `state-change` to `member-changes`. 2. If `state-change` is `KICKED` or `LEFT` and `identity` does exist in `current.members`, add the tuple `identity`, `state-change` to `member-changes`. 5. Group `member-changes` by their associated `state-change` and add appropriate status messages to the associated conversation.
Used in:
A map of the member identity string to the member state change.
Used in:
The member has been added
The member has been kicked from the group.
The member left the group.
An incoming message, reflected to other devices. When sending this message: 1. [...] 2. Set `nonce` to the nonce of `e2e.message-with-metadata` (or `e2e.legacy-message`) that contained the `body` in encrypted form. When receiving this message: 1. Add `nonce` to the CSP nonce storage (discard a nonces that already exist in the nonce storage). 2. If a message with the same `message_id` exists within the associated `conversation`, discard the message and abort these steps. 3. [...]
Used in:
,Sender's Threema ID
Unique ID of the enclosed message
Unix-ish timestamp in milliseconds for when the enclosed message has been created. Note: Take this value from the `csp.payload.legacy-message`/`csp.payload.message-with-metadata-box` that enclosed the message.
Enclosed message's type.
The message's body, i.e. the unpadded `csp.e2e.container.padded-data`
Nonce the message was encrypted with by the sender (the shared secret derived from the long-term keys). Optional for now, always required in a future version.
Update one or more existing incoming messages.
Used in:
Updates
Mark the referred message as read. Note: This may only be used when _read receipts_ have been turned off, i.e. as a replacement for reflecting `delivery-receipt` type _read_ (`0x02`).
Used in:
Unix-ish timestamp in milliseconds for when the referred message has been read.
Used in:
Conversation ID of the referred message.
Unique ID of the referred message
Update type
Mark the referred message as read
MDM parameter synchronisation message.
Used in:
Synchronisation type
Update MDM parameters. When receiving this variant, run the _MDM Merge And Apply Steps_.
Used in:
An outgoing message, reflected to other devices. When sending this message: 1. [...] 2. Set `nonces` to the nonces of the associated CSP `e2e.message-with-metadata` (or `e2e.legacy-message`) messages that contained the `body` in encrypted form.¹ When receiving this message: 1. Add all `nonces` to the CSP nonce storage (discarding any nonces that already exist in the nonce storage). 2. If a message with the same `message_id` exists within the associated `conversation`, discard the message and abort these steps. 3. [...] ¹: For contacts and distribution lists, there will be exactly one nonce. For groups, there will be as many nonces as there are group members minus one.
Used in:
,Conversation ID of the enclosed message. Note: If the conversation is of type group, group and group creator id of the enclosed CSP E2E message must match the values of the supplied group identity. Otherwise, the message must be considered invalid.
Unique ID of the enclosed message
Optional thread message ID (the message ID of the last incoming message in the current conversation)
Unix-ish timestamp in milliseconds for when the enclosed message has been created Note: Take this value from the `csp.payload.legacy-message`/`csp.payload.message-with-metadata-box` that enclosed the message.
Enclosed message's type
The message's body, i.e. the unpadded `csp.e2e.container.padded-data`
Nonces the message was encrypted with towards each receiver (the shared secret derived from the long-term keys). Optional for now, always required in a future version.
Update one or more existing outgoing messages.
Used in:
Updates
Mark the referred message as sent (acknowledged by the chat server). Note 1: The timestamp of the `reflect-ack`/`reflected` message determines the timestamp for when the referred message has been sent. Note 2: This indicates that the referred message has been successfully stored in the message queue of the server. It does NOT indicate that the referred message has been delivered to the intended receiver.
Used in:
(message has no fields)
Used in:
Conversation ID of the referred message.
Unique ID of the referred message
Update type
Mark the referred message as sent
D2D protocol versions. Note 1: The most significant byte is the major version and the least significant byte is the minor version. Note 2: Once the D2D protocol is more stable, an unknown major version can be interpreted as incompatible. For now, we only have 0.X versions that define in which way they break compatibility.
The version is unspecified.
V0.1 Devices using this version use the opportunistic (but problematic) group sync mechanism via pure CSP reflection. D2D group sync reflection was totally underspecified but is partially supported on the receiving side.
V0.2 Builds on V0.1 with backwards compatibility to V0.1. Devices using this version use the explicit group sync mechanism via D2D sync reflection. Upon reception, V0.2 devices detecting a reflected message will switch over the version, and: - for V0.1 in combination with a CSP group message, fall back to the backwards compatibility mode and update the group according to the message. - for V0.2+ in combination with a CSP group message, ignore it.
V0.3 Builds on V0.2 but removes the backwards compatibility to V0.1. Upon reception, V0.2 devices detecting a reflected message will switch over the version, and: - for V0.1 in combination with a CSP group message, spit out a warning that the group is going to desync. - for V0.2+ in combination with a CSP group message, ignore it.
Settings synchronisation message.
Used in:
Synchronisation type
Update settings.
Used in:
Data shared across all devices and transmitted during the handshake.
Random amount of padding, ignored by the receiver
Current lowest protocol version that must be supported by all devices
A transaction scope. Used in the d2m transaction messages.
Used in:
User profile synchronisation message.
Used in:
Synchronisation type
Update the user's profile
Used in: