From bf6218647f064e4a43420f3b45fa1dea1925078b Mon Sep 17 00:00:00 2001 From: Oskar Thoren Date: Tue, 24 Mar 2020 16:05:35 +0800 Subject: [PATCH 1/2] Move payloads to stable --- README.md | 3 ++- status-payloads-spec.md | 8 +++++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 1e945bc..6f7c333 100644 --- a/README.md +++ b/README.md @@ -27,12 +27,13 @@ The following SIPs are stable and running in production. - [Status Account Specification](status-account-spec.md). What a Status account is and how trust is established. +- [Status Payload Specification](status-payloads-spec.md). What the message payloads look like. + ### Draft The following SIPs are under consideration for standardization. - [Status Client Specification](status-client-spec.md). The main specification for writing a Status client. **Start here** -- [Status Payload Specification](status-payloads-spec.md). What the message payloads look like. ### Raw diff --git a/status-payloads-spec.md b/status-payloads-spec.md index 645423f..dc10e13 100644 --- a/status-payloads-spec.md +++ b/status-payloads-spec.md @@ -1,8 +1,10 @@ # Status Message Payloads Specification -> Version: 0.1 (Draft) +> Version: 0.2 > -> Authors: Adam Babik , Oskar Thorén (alphabetical order) +> Status: Stable +> +> Authors: Adam Babik , Andrea Maria Piana , Oskar Thorén (alphabetical order) ## Abstract @@ -316,6 +318,6 @@ There are two ways to upgrade the protocol without breaking compatibility: ## Security Considerations -TBD. +- ## Design rationale From a7d4b0176b55124f8daa76a6a787f6d301eecc22 Mon Sep 17 00:00:00 2001 From: Corey Petty Date: Wed, 25 Mar 2020 13:38:53 -0400 Subject: [PATCH 2/2] update protobuf spec from file --- status-payloads-spec.md | 40 +++++++++++++++++++++++----------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/status-payloads-spec.md b/status-payloads-spec.md index dc10e13..cd5498f 100644 --- a/status-payloads-spec.md +++ b/status-payloads-spec.md @@ -23,27 +23,28 @@ as various clients created using different technologies. - [Introduction](#introduction) - [Payload wrapper](#payload-wrapper) - [Encoding](#encoding) - - [Types of Messages] (#types-of-messages) + - [Types of messages](#types-of-messages) - [Message](#message) - [Payload](#payload) + - [Payload](#payload-1) - [Content types](#content-types) + - [Sticker content type](#sticker-content-type) - [Message types](#message-types) - [Clock vs Timestamp and message ordering](#clock-vs-timestamp-and-message-ordering) - [Chats](#chats) - - [ContactUpdate](#contact-update) - - [Payload] (#payload) - - [SyncInstallationContact](#sync-installation-contact) - - [Payload](#payload) - - [SyncInstallationPublicChat](#sync-installation-public-chat) - - [Payload](#payload) - - [PairInstallation](#pair-installation) - - [Payload](#payload) - - [MembershipUpdateMessage](#membership-update-message) - - [Payload](#payload) + - [Contact Update](#contact-update) + - [Payload](#payload-2) + - [Contact update](#contact-update-1) + - [SyncInstallationContact](#syncinstallationcontact) + - [Payload](#payload-3) + - [SyncInstallationPublicChat](#syncinstallationpublicchat) + - [Payload](#payload-4) + - [PairInstallation](#pairinstallation) + - [Payload](#payload-5) + - [MembershipUpdateMessage and MembershipUpdateEvent](#membershipupdatemessage-and-membershipupdateevent) - [Upgradability](#upgradability) - [Security Considerations](#security-considerations) - [Design rationale](#design-rationale) - - [Why are you using Transit and Protobuf?](#why-are-you-using-transit-and-protobuf) ## Introduction @@ -63,7 +64,7 @@ message StatusProtocolMessage { `signature` is the bytes of the signed `SHA3-256` of the payload, signed with the key of the author of the message. The signature is needed to validate authorship of the message, so that the message can be relayed to third parties. -If a signature is not present but an author is provided by a layer below, the message is not to be relayed to third parties and its considered plausibly deniable. +If a signature is not present but an author is provided by a layer below, the message is not to be relayed to third parties and it is considered plausibly deniable. ## Encoding @@ -83,7 +84,8 @@ The protobuf description is: message ChatMessage { // Lamport timestamp of the chat message uint64 clock = 1; - // Unix timestamp in milliseconds, not + // Unix timestamps in milliseconds, currently not used as we use whisper as more reliable, but here + // so that we don't rely on it uint64 timestamp = 2; // Text of the message string text = 3; @@ -91,7 +93,10 @@ message ChatMessage { string response_to = 4; // Ens name of the sender string ens_name = 5; - // Local chatID of the message + // Chat id, this field is symmetric for public-chats and private group chats, + // but asymmetric in case of one-to-ones, as the sender will use the chat-id + // of the received, while the receiver will use the chat-id of the sender. + // Probably should be the concatenation of sender-pk & receiver-pk in alphabetical order string chat_id = 6; // The type of message (public/one-to-one/private-group-chat) @@ -109,8 +114,7 @@ message ChatMessage { PUBLIC_GROUP = 2; PRIVATE_GROUP = 3; // Only local - SYSTEM_MESSAGE_PRIVATE_GROUP = 4; - } + SYSTEM_MESSAGE_PRIVATE_GROUP = 4;} enum ContentType { UNKNOWN_CONTENT_TYPE = 0; TEXT_PLAIN = 1; @@ -118,6 +122,8 @@ message ChatMessage { STATUS = 3; EMOJI = 4; TRANSACTION_COMMAND = 5; + // Only local + SYSTEM_MESSAGE_CONTENT_PRIVATE_GROUP = 6; } } ```