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

Apply suggestions from code review 

Co-Authored-By: Dean Eigenmann <dean.eigenmann@icloud.com>
This commit is contained in:
Andrea Maria Piana 2020-01-21 20:12:18 +01:00 committed by GitHub
parent c48c0c32b6
commit 98e91e2ad1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
status-client-spec.md
View File

@ -69,7 +69,7 @@ Implementing a Status clients means implementing the following layers. Additiona
### Protobuf
We use `protobuf` in different layers, the version used is `proto3` unless stated otherwise.
We use [`protobuf`](https://developers.google.com/protocol-buffers/) in different layers, the version used is `proto3` unless stated otherwise.
## Components

2
status-payloads-spec.md
View File

@ -179,7 +179,7 @@ The following messages types MUST be supported:
Messages with a `clock` greater than `120` seconds over the whisper timestamp SHOULD be discarded, in order to avoid malicious users to increase the `clock` of a chat arbitrarily.
Messages with a `clock` less than `120` might indicate an attempt to insert messages in the chat history, this is not distinguishable though from a re-transmit from the `datasync` layer. Client MIGHT mark this messages with a warning to the user, or discard them.
Messages with a `clock` less than `120` might indicate an attempt to insert messages in the chat history, this is not distinguishable though from a re-transmit from the `datasync` layer. A client MAY mark this messages with a warning to the user, or discard them.
`clock` value is used for the message ordering. Due to the used algorithm and distributed nature of the system, we achieve casual ordering which might produce counterintuitive results in some edge cases. For example, when one joins a public chat and sends a message before receiving the exist messages, their message `clock` value might be lower and the message will end up in the past when the historical messages are fetched.