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

22
status-client-spec.md
View File

@ -16,11 +16,12 @@ 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.
## Table of Contents
- [Abstract](#abstract)
- [Table of Contents](#table-of-contents)
- [Introduction](#introduction)
- [Status Client Specification](#status-client-specification)
- [Abstract](#abstract)
- [Table of Contents](#table-of-contents)
- [Introduction](#introduction)
- [Protocol layers](#protocol-layers)
- [Components](#components)
- [Components](#components)
- [P2P Overlay](#p2p-overlay)
- [Node discovery and roles](#node-discovery-and-roles)
- [Bootstrapping](#bootstrapping)
@ -30,8 +31,9 @@ have to be implemented in order to be a full Status client. The second gives a d
- [Secure Transport](#secure-transport)
- [Data Sync](#data-sync)
- [Payloads and clients](#payloads-and-clients)
- [Security Considerations](#security-considerations)
- [Design Rationale](#design-rationale)
- [Security Considerations](#security-considerations)
- [Censorship-resistance](#censorship-resistance)
- [Design Rationale](#design-rationale)
- [P2P Overlay](#p2p-overlay-1)
- [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)
@ -40,8 +42,10 @@ have to be implemented in order to be a full Status client. The second gives a d
- [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)
- [I heard something about mailservers being trusted somehow?](#i-heard-something-about-mailservers-being-trusted-somehow)
- [Footnotes](#footnotes)
- [Acknowledgements](#acknowledgements)
- [Data sync](#data-sync)
- [Why is MVDS not used for public chats?](#why-is-mvds-not-used-for-public-chats)
- [Footnotes](#footnotes)
- [Acknowledgements](#acknowledgements)
## 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
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
Specification](x8.md) for more details.
Specification](status-payloads-spec.md) for more details.
## Security Considerations

38
status-payloads-spec.md
View File

@ -15,19 +15,22 @@ as various clients created using different technologies.
## Table of Contents
- [Abstract](#abstract)
- [Table of Contents](#table-of-contents)
- [Introduction](#introduction)
- [Wrapper](#wrapper)
- [Encoding](#encoding)
- [Message types](#message-types)
- [Message](#message)
- [Status Message Payloads Specification](#status-message-payloads-specification)
- [Abstract](#abstract)
- [Table of Contents](#table-of-contents)
- [Introduction](#introduction)
- [Payload wrapper](#payload-wrapper)
- [Encoding](#encoding)
- [Message](#message)
- [Payload](#payload)
- [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)
- [Upgradability](#upgradability)
- [Security Considerations](#security-considerations)
- [Chats](#chats)
- [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
@ -128,6 +131,21 @@ The following messages types MUST be supported:
<!-- 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
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.