status-im
/
specs
mirror of https://github.com/status-im/specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

describe chats concept

This commit is contained in:
Adam Babik 2019-09-02 07:47:54 +02:00
parent 04c92f2f02
commit 8e45502db3
No known key found for this signature in database
GPG Key ID: ED02515A1FC0D1B4
2 changed files with 52 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
status-client-spec.md
View File

@ -16,32 +16,36 @@ This document consists of two parts. The first outlines the specifications that
have to be implemented in order to be a full Status client. The second gives a design rationale and answers some common questions. have to be implemented in order to be a full Status client. The second gives a design rationale and answers some common questions.
## Table of Contents ## Table of Contents
- [Abstract](#abstract) - [Status Client Specification](#status-client-specification)
- [Table of Contents](#table-of-contents) - [Abstract](#abstract)
- [Introduction](#introduction) - [Table of Contents](#table-of-contents)
- [Introduction](#introduction)
- [Protocol layers](#protocol-layers) - [Protocol layers](#protocol-layers)
- [Components](#components) - [Components](#components)
- [P2P Overlay](#p2p-overlay) - [P2P Overlay](#p2p-overlay)
- [Node discovery and roles](#node-discovery-and-roles) - [Node discovery and roles](#node-discovery-and-roles)
- [Bootstrapping](#bootstrapping) - [Bootstrapping](#bootstrapping)
- [Discovery](#discovery) - [Discovery](#discovery)
- [Mobile nodes](#mobile-nodes) - [Mobile nodes](#mobile-nodes)
- [Transport privacy and Whisper usage](#transport-privacy-and-whisper-usage) - [Transport privacy and Whisper usage](#transport-privacy-and-whisper-usage)
- [Secure Transport](#secure-transport) - [Secure Transport](#secure-transport)
- [Data Sync](#data-sync) - [Data Sync](#data-sync)
- [Payloads and clients](#payloads-and-clients) - [Payloads and clients](#payloads-and-clients)
- [Security Considerations](#security-considerations) - [Security Considerations](#security-considerations)
- [Design Rationale](#design-rationale) - [Censorship-resistance](#censorship-resistance)
- [Design Rationale](#design-rationale)
- [P2P Overlay](#p2p-overlay-1) - [P2P Overlay](#p2p-overlay-1)
- [Why devp2p? Why not use libp2p?](#why-devp2p-why-not-use-libp2p) - [Why devp2p? Why not use libp2p?](#why-devp2p-why-not-use-libp2p)
- [What about other RLPx subprotocols like LES, and Swarm?](#what-about-other-rlpx-subprotocols-like-les-and-swarm) - [What about other RLPx subprotocols like LES, and Swarm?](#what-about-other-rlpx-subprotocols-like-les-and-swarm)
- [Why do you use Whisper?](#why-do-you-use-whisper) - [Why do you use Whisper?](#why-do-you-use-whisper)
- [I heard you were moving away from Whisper?](#i-heard-you-were-moving-away-from-whisper) - [I heard you were moving away from Whisper?](#i-heard-you-were-moving-away-from-whisper)
- [Why is PoW for Whisper set so low?](#why-is-pow-for-whisper-set-so-low) - [Why is PoW for Whisper set so low?](#why-is-pow-for-whisper-set-so-low)
- [Why do you not use Discovery v5 for node discovery?](#why-do-you-not-use-discovery-v5-for-node-discovery) - [Why do you not use Discovery v5 for node discovery?](#why-do-you-not-use-discovery-v5-for-node-discovery)
- [I heard something about mailservers being trusted somehow?](#i-heard-something-about-mailservers-being-trusted-somehow) - [I heard something about mailservers being trusted somehow?](#i-heard-something-about-mailservers-being-trusted-somehow)
- [Footnotes](#footnotes) - [Data sync](#data-sync)
- [Acknowledgements](#acknowledgements) - [Why is MVDS not used for public chats?](#why-is-mvds-not-used-for-public-chats)
- [Footnotes](#footnotes)
- [Acknowledgements](#acknowledgements)
## Introduction ## Introduction
@ -148,7 +152,7 @@ Transport Spec](status-secure-transport-spec.md) for more.
On top of secure transport, we have various types of data sync clients and On top of secure transport, we have various types of data sync clients and
payload formats for things like 1:1 chat, group chat and public chat. These have payload formats for things like 1:1 chat, group chat and public chat. These have
various degrees of standardization. Please refer to [Initial Message Payload various degrees of standardization. Please refer to [Initial Message Payload
Specification](x8.md) for more details. Specification](status-payloads-spec.md) for more details.
## Security Considerations ## Security Considerations

38
status-payloads-spec.md
View File

@ -15,19 +15,22 @@ as various clients created using different technologies.
## Table of Contents ## Table of Contents
- [Abstract](#abstract) - [Status Message Payloads Specification](#status-message-payloads-specification)
- [Table of Contents](#table-of-contents) - [Abstract](#abstract)
- [Introduction](#introduction) - [Table of Contents](#table-of-contents)
- [Wrapper](#wrapper) - [Introduction](#introduction)
- [Encoding](#encoding) - [Payload wrapper](#payload-wrapper)
- [Message types](#message-types) - [Encoding](#encoding)
- [Message](#message) - [Message](#message)
- [Payload](#payload) - [Payload](#payload)
- [Content types](#content-types) - [Content types](#content-types)
- [Message types](#message-types-1) - [Message types](#message-types)
- [Clock vs Timestamp and message ordering](#clock-vs-timestamp-and-message-ordering) - [Clock vs Timestamp and message ordering](#clock-vs-timestamp-and-message-ordering)
- [Upgradability](#upgradability) - [Chats](#chats)
- [Security Considerations](#security-considerations) - [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 ## Introduction
@ -128,6 +131,21 @@ The following messages types MUST be supported:
<!-- TODO: Document section on replies --> <!-- TODO: Document section on replies -->
## Chats
Chat is a structure that helps organize messages. It's usually desired to display messages only from a single recipient or a group of recipients at a time and chats help to achieve that.
All incoming messages can be matched against a chat. Below you can find a table that describes how to calculate a chat ID for each message type.
|Message Type|Chat ID Calculation|Direction|Comment|
|------------|-------------------|---------|-------|
|public-group-user-message|chat ID is equal to a public channel name; it should equal `chat-id` from message's `content` field|Incoming/Outgoing||
|user-message|let `P` be a public key of the recipient; `hex-encode(P)` is a chat ID; use it as `chat-id` value in message's `content` field|Outgoing||
|user-message|let `P` be a public key of message's signature; `hex-encode(P)` is a chat ID; discard `chat-id` from message's `content` field|Incoming|if there is no matched chat, it might be the first message from public key `P`; you can discard it or create a new chat; Status official clients create a new chat|
|group-user-message|use `chat-id` from message's `content` field|Incoming/Outgoing|find an existing chat by `chat-id`; if none is found discard the message (TODO: incomplete)|
<!-- TODO: "group-user-message" is not complete. Does it require to explicitly join the group chat? Is there a way to invite someone? Also, if I start a new group chat (or join an existing one), I need to somehow calculate this chatID by myself. How to do it? -->
## Upgradability ## Upgradability
The current protocol format is hardly upgradable without breaking backward compatibility. Because Transit is used in this particular way described above, the only reliable option is to append a new field to the Transit record definition. It will be simply ignored by the old clients. The current protocol format is hardly upgradable without breaking backward compatibility. Because Transit is used in this particular way described above, the only reliable option is to append a new field to the Transit record definition. It will be simply ignored by the old clients.