mirror of https://github.com/status-im/specs.git
adds check, fixes links (#124)
This commit is contained in:
Dean Eigenmann
GitHub
parent
2b0604077d
commit
c22a9e8d5e
|
|
@ -1,6 +1,7 @@
|
|||
{
|
||||
"presets": ["lint-recommended", "lint-consistent"],
|
||||
"plugins": {
|
||||
"validate-links": {"repository": false},
|
||||
"remark-lint": {
|
||||
"unordered-list-marker-style": "consistent",
|
||||
"list-item-bullet-indent": true,
|
||||
|
|
@ -12,13 +13,15 @@
|
|||
"heading-increment": false,
|
||||
"no-multiple-toplevel-headings": true,
|
||||
"no-consecutive-blank-lines": false,
|
||||
"maximum-line-length": 9000,
|
||||
"maximum-heading-length": 300,
|
||||
"no-heading-punctuation": false,
|
||||
"no-duplicate-headings": false,
|
||||
"emphasis-marker": "*",
|
||||
"no-tabs": true,
|
||||
"blockquote-indentation": false,
|
||||
"strong-marker": "*"
|
||||
"strong-marker": "*",
|
||||
"heading-style": "atx"
|
||||
}
|
||||
},
|
||||
"settings": {
|
||||
|
|
|
|||
|
|
@ -12,7 +12,6 @@ title: 3/WHISPER-USAGE
|
|||
>
|
||||
> Authors: Adam Babik <adam@status.im>, Andrea Maria Piana <andreap@status.im>, Corey Petty <corey@status.im>, Oskar Thorén <oskar@status.im> (alphabetical order)
|
||||
|
||||
- [Status Whisper Usage Specification](#status-whisper-usage-specification)
|
||||
- [Abstract](#abstract)
|
||||
- [Reason](#reason)
|
||||
- [Terminology](#terminology)
|
||||
|
|
@ -29,7 +28,7 @@ title: 3/WHISPER-USAGE
|
|||
- [Message confirmations](#message-confirmations)
|
||||
- [Whisper V6 extensions](#whisper-v6-extensions)
|
||||
- [Request historic messages](#request-historic-messages)
|
||||
- [shhext_requestMessages](#shhextrequestmessages)
|
||||
- [shhext_requestMessages](#shhext_requestmessages)
|
||||
- [Changelog](#changelog)
|
||||
|
||||
## Abstract
|
||||
|
|
|
|||
|
|
@ -23,7 +23,6 @@ as various clients created using different technologies.
|
|||
|
||||
## Table of Contents
|
||||
|
||||
- [Status Message Payloads Specification](#status-message-payloads-specification)
|
||||
- [Abstract](#abstract)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Introduction](#introduction)
|
||||
|
|
@ -339,7 +338,7 @@ message PairInstallation {
|
|||
### MembershipUpdateMessage and MembershipUpdateEvent
|
||||
|
||||
`MembershipUpdateEvent` is a message used to propagate information about group membership changes in a group chat.
|
||||
The details are in the [Group chats specs](status-group-chats-spec.md)
|
||||
The details are in the [Group chats specs](./7-group-chat.md)
|
||||
|
||||
## Upgradability
|
||||
|
||||
|
|
|
|||
|
|
@ -20,13 +20,13 @@ title: 7/GROUP-CHAT
|
|||
- [Chat ID](#chat-id)
|
||||
- [Signature](#signature)
|
||||
- [Group membership event](#group-membership-event)
|
||||
- [chat-created](#chat-created)
|
||||
- [name-changed](#name-changed)
|
||||
- [members-added](#members-added)
|
||||
- [members-joined](#members-joined)
|
||||
- [admins-added](#admins-added)
|
||||
- [members-removed](#members-removed)
|
||||
- [admin-removed](#admin-removed)
|
||||
- [chat-created](#chat_created)
|
||||
- [name-changed](#name_changed)
|
||||
- [members-added](#members_added)
|
||||
- [members-joined](#member_joined)
|
||||
- [admins-added](#admins_added)
|
||||
- [members-removed](#member_removed)
|
||||
- [admin-removed](#admin_removed)
|
||||
|
||||
|
||||
## Abstract
|
||||
|
|
@ -83,7 +83,7 @@ message MembershipUpdateEvent {
|
|||
| ----- | ---- | ---- | ---- |
|
||||
| 1 | chat-id | `string` | The chat id of the chat where the change is to take place |
|
||||
| 2 | events | See details | A list of events that describe the membership changes, in their encoded protobuf form |
|
||||
| 3 | message | `ChatMessage` | An optional message, described in [Message](#message) |
|
||||
| 3 | message | `ChatMessage` | An optional message, described in [Message](./6-payloads.md#message) |
|
||||
|
||||
`MembershipUpdateEvent`:
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ title: 9/3RD-PARTY-USAGE
|
|||
|
||||
## Table of Contents
|
||||
|
||||
1. [Abstract](Abstract)
|
||||
1. [Abstract](#abstract)
|
||||
2. [Definitions](#definitions)
|
||||
3. [Why 3rd party API can be a problem?](#why-3rd-party-api-can-be-a-problem)
|
||||
4. [3rd party APIs used by Status](#3rd-party-apis-used-by-current-status-app)
|
||||
|
|
@ -31,6 +31,7 @@ title: 9/3RD-PARTY-USAGE
|
|||
7. [Copyright](#copyright)
|
||||
|
||||
## Abstract
|
||||
|
||||
In this specification, we discuss 3rd party APIs that Status relies on. These APIs provide various capabilities such as:
|
||||
- communicate with the Ethereum network
|
||||
- allow users to see address and transaction details on external website
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ To install a sticker pack, we need to fetch all sticker packs which are availabl
|
|||
Call `packCount()` on the sticker market contract, will return number of sticker pack registered as `uint256`.
|
||||
|
||||
#### 2. Get sticker pack by id
|
||||
ID's are represented as `uint256` and are incremental from `0` to total number of sticker packs in contract, which we received on previous step. To get a sticker pack we should call `getPackData(sticker-pack-id)`, the return type is `["bytes4[]" "address" "bool" "uint256" "uint256" "bytes"]` which represents the following fields: `[category owner mintable timestamp price contenthash]`. Price is the SNT value in wei set by sticker pack owner. The contenthash is the IPFS address described in the [submit description](#submit-a-sticker-pack) above. Other fields specification could be found in [Sticker Market spec](https://github.com/status-im/sticker-market/blob/651e88e5f38c690e57ecaad47f46b9641b8b1e27/docs/specification.md)
|
||||
ID's are represented as `uint256` and are incremental from `0` to total number of sticker packs in contract, which we received on previous step. To get a sticker pack we should call `getPackData(sticker-pack-id)`, the return type is `["bytes4[]" "address" "bool" "uint256" "uint256" "bytes"]` which represents the following fields: `[category owner mintable timestamp price contenthash]`. Price is the SNT value in wei set by sticker pack owner. The contenthash is the IPFS address described in the [submit description](#submit-a-sticker) above. Other fields specification could be found in [Sticker Market spec](https://github.com/status-im/sticker-market/blob/651e88e5f38c690e57ecaad47f46b9641b8b1e27/docs/specification.md)
|
||||
|
||||
##### 3. Get owned sticker packs
|
||||
The current Status app fetches owned sticker packs during the open of any sticker view (a screen which shows a sticker pack or the list of sticker packs).
|
||||
|
|
|
|||
|
|
@ -25,7 +25,6 @@ have to be implemented in order to be a full Status client. The second gives a d
|
|||
|
||||
## Table of Contents
|
||||
|
||||
- [Status Client Specification](#status-client-specification)
|
||||
- [Abstract](#abstract)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Introduction](#introduction)
|
||||
|
|
@ -62,6 +61,8 @@ have to be implemented in order to be a full Status client. The second gives a d
|
|||
- [Censorship resistance](#censorship-resistance)
|
||||
- [Acknowledgments](#acknowledgments)
|
||||
|
||||
## Introduction
|
||||
|
||||
### Protocol layers
|
||||
|
||||
Implementing a Status clients largely means implementing the following layers. Additionally, there are separate specifications for things like key management and account lifecycle.
|
||||
|
|
@ -124,18 +125,18 @@ Status maintains a list of production fleet bootstrap nodes in the following loc
|
|||
|
||||
**Hong Kong:**
|
||||
|
||||
- `enode://6e6554fb3034b211398fcd0f0082cbb6bd13619e1a7e76ba66e1809aaa0c5f1ac53c9ae79cf2fd4a7bacb10d12010899b370c75fed19b991d9c0cdd02891abad@47.75.99.169:443`
|
||||
- `enode://23d0740b11919358625d79d4cac7d50a34d79e9c69e16831c5c70573757a1f5d7d884510bc595d7ee4da3c1508adf87bbc9e9260d804ef03f8c1e37f2fb2fc69@47.52.106.107:443`
|
||||
- `enode://6e6554fb3034b211398fcd0f0082cbb6bd13619e1a7e76ba66e1809aaa0c5f1ac53c9ae79cf2fd4a7bacb10d12010899b370c75fed19b991d9c0cdd02891abad@47.75.99.169:443`
|
||||
- `enode://23d0740b11919358625d79d4cac7d50a34d79e9c69e16831c5c70573757a1f5d7d884510bc595d7ee4da3c1508adf87bbc9e9260d804ef03f8c1e37f2fb2fc69@47.52.106.107:443`
|
||||
|
||||
**Amsterdam:**
|
||||
|
||||
- `enode://436cc6f674928fdc9a9f7990f2944002b685d1c37f025c1be425185b5b1f0900feaf1ccc2a6130268f9901be4a7d252f37302c8335a2c1a62736e9232691cc3a@178.128.138.128:443`
|
||||
- `enode://5395aab7833f1ecb671b59bf0521cf20224fe8162fc3d2675de4ee4d5636a75ec32d13268fc184df8d1ddfa803943906882da62a4df42d4fccf6d17808156a87@178.128.140.188:443`
|
||||
- `enode://436cc6f674928fdc9a9f7990f2944002b685d1c37f025c1be425185b5b1f0900feaf1ccc2a6130268f9901be4a7d252f37302c8335a2c1a62736e9232691cc3a@178.128.138.128:443`
|
||||
- `enode://5395aab7833f1ecb671b59bf0521cf20224fe8162fc3d2675de4ee4d5636a75ec32d13268fc184df8d1ddfa803943906882da62a4df42d4fccf6d17808156a87@178.128.140.188:443`
|
||||
|
||||
**Central US:**
|
||||
|
||||
- `enode://32ff6d88760b0947a3dee54ceff4d8d7f0b4c023c6dad34568615fcae89e26cc2753f28f12485a4116c977be937a72665116596265aa0736b53d46b27446296a@34.70.75.208:443`
|
||||
- `enode://5405c509df683c962e7c9470b251bb679dd6978f82d5b469f1f6c64d11d50fbd5dd9f7801c6ad51f3b20a5f6c7ffe248cc9ab223f8bcbaeaf14bb1c0ef295fd0@35.223.215.156:443`
|
||||
- `enode://32ff6d88760b0947a3dee54ceff4d8d7f0b4c023c6dad34568615fcae89e26cc2753f28f12485a4116c977be937a72665116596265aa0736b53d46b27446296a@34.70.75.208:443`
|
||||
- `enode://5405c509df683c962e7c9470b251bb679dd6978f82d5b469f1f6c64d11d50fbd5dd9f7801c6ad51f3b20a5f6c7ffe248cc9ab223f8bcbaeaf14bb1c0ef295fd0@35.223.215.156:443`
|
||||
|
||||
These bootstrap nodes MAY change and we can't guarantee that it will stay this way forever
|
||||
and at some point we might be forced to change them.
|
||||
|
|
@ -274,10 +275,10 @@ computer.
|
|||
Whisper is not currently under active development, and it has several drawbacks.
|
||||
Among others:
|
||||
|
||||
- It is very wasteful bandwidth-wise and it doesn't appear to be scalable
|
||||
- Proof of work is a poor spam protection mechanism for heterogeneous devices
|
||||
- The privacy guarantees provided are not rigorous
|
||||
- There's no incentives to run a node
|
||||
- It is very wasteful bandwidth-wise and it doesn't appear to be scalable
|
||||
- Proof of work is a poor spam protection mechanism for heterogeneous devices
|
||||
- The privacy guarantees provided are not rigorous
|
||||
- There's no incentives to run a node
|
||||
|
||||
Finding a more suitable transport privacy is an ongoing research effort,
|
||||
together with [Vac](https://vac.dev/vac-overview) and other teams in the space.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,6 @@ In this specification we explain what Status account is, and how trust is establ
|
|||
- [X3DH Prekey bundles](#x3dh-prekey-bundles)
|
||||
- [Optional Account additions](#optional-account-additions)
|
||||
- [ENS Username](#ens-username)
|
||||
- [User Profile Picture](#user-profile-picture)
|
||||
- [Trust establishment](#trust-establishment)
|
||||
- [Terms Glossary](#terms-glossary)
|
||||
- [Contact Discovery](#contact-discovery)
|
||||
|
|
@ -37,7 +36,6 @@ In this specification we explain what Status account is, and how trust is establ
|
|||
- [Initial Key Exchange](#initial-key-exchange)
|
||||
- [Contact Request](#contact-request)
|
||||
- [Bundles](#bundles)
|
||||
- [QR code](#qr-code)
|
||||
- [Contact Verification](#contact-verification)
|
||||
- [Identicon](#identicon)
|
||||
- [3 word pseudonym / whisper key fingerprint](#3-word-pseudonym--whisper-key-fingerprint)
|
||||
|
|
|
|||
|
|
@ -12,7 +12,6 @@ title: 3/WHISPER-USAGE
|
|||
>
|
||||
> Authors: Adam Babik <adam@status.im>, Corey Petty <corey@status.im>, Oskar Thorén <oskar@status.im> (alphabetical order)
|
||||
|
||||
- [Status Whisper Usage Specification](#status-whisper-usage-specification)
|
||||
- [Abstract](#abstract)
|
||||
- [Reason](#reason)
|
||||
- [Terminology](#terminology)
|
||||
|
|
@ -24,14 +23,12 @@ title: 3/WHISPER-USAGE
|
|||
- [Contact code topic](#contact-code-topic)
|
||||
- [Partitioned topic](#partitioned-topic)
|
||||
- [Public chats](#public-chats)
|
||||
- [Generic discovery topic](#generic-discovery-topic)
|
||||
- [One-to-one topic](#one-to-one-topic)
|
||||
- [Group chat topic](#group-chat-topic)
|
||||
- [Message encryption](#message-encryption)
|
||||
- [Message confirmations](#message-confirmations)
|
||||
- [Whisper V6 extensions](#whisper-v6-extensions)
|
||||
- [Request historic messages](#request-historic-messages)
|
||||
- [shhext_requestMessages](#shhextrequestmessages)
|
||||
- [shhext_requestMessages](#shhext_requestmessages)
|
||||
|
||||
## Abstract
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,6 @@ title: 4/WHISPER-MAILSERVER
|
|||
>
|
||||
> Authors: Adam Babik <adam@status.im>, Oskar Thorén <oskar@status.im> (alphabetical order)
|
||||
|
||||
- [Status Whisper Mailserver Specification](#status-whisper-mailserver-specification)
|
||||
- [Abstract](#abstract)
|
||||
- [Mailserver](#mailserver)
|
||||
- [Archiving messages](#archiving-messages)
|
||||
|
|
|
|||
|
|
@ -49,11 +49,6 @@ It builds on the [X3DH](https://signal.org/docs/specifications/x3dh/) and [Doubl
|
|||
- [Sending messages to a paired group](#sending-messages-to-a-paired-group)
|
||||
- [Account recovery](#account-recovery)
|
||||
- [Partitioned devices](#partitioned-devices)
|
||||
- [Trust establishment](#trust-establishment)
|
||||
- [Contact request](#contact-request)
|
||||
- [Expired session](#expired-session)
|
||||
- [Stale devices](#stale-devices)
|
||||
|
||||
|
||||
## Introduction
|
||||
|
||||
|
|
@ -80,13 +75,13 @@ Types used in this specification are defined using [Protobuf](https://developers
|
|||
|
||||
### Transport Layer
|
||||
|
||||
[Whisper](./status-whisper-usage-spec.md) serves as the transport layer for the Status chat protocol.
|
||||
[Whisper](./3-whisper-usage.md) serves as the transport layer for the Status chat protocol.
|
||||
|
||||
### User flow for 1-to-1 communications
|
||||
|
||||
#### Account generation
|
||||
|
||||
See [Account specification](./status-account-spec.md)
|
||||
See [Account specification](./2-account.md)
|
||||
|
||||
#### Account recovery
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,6 @@ as various clients created using different technologies.
|
|||
|
||||
## Table of Contents
|
||||
|
||||
- [Status Message Payloads Specification](#status-message-payloads-specification)
|
||||
- [Abstract](#abstract)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Introduction](#introduction)
|
||||
|
|
@ -319,7 +318,7 @@ message PairInstallation {
|
|||
### MembershipUpdateMessage and MembershipUpdateEvent
|
||||
|
||||
`MembershipUpdateEvent` is a message used to propagate information about group membership changes in a group chat.
|
||||
The details are in the [Group chats specs](status-group-chats-spec.md)
|
||||
The details are in the [Group chats specs](./../draft/7-group-chat.md)
|
||||
|
||||
## Upgradability
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,6 @@ title: 8/EIPS
|
|||
In this specification, we describe how Status relates with EIPs.
|
||||
|
||||
## Table of Contents
|
||||
- [Status EIPs standards ](#status-client-specification)
|
||||
- [Abstract](#abstract)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Introduction](#introduction)
|
||||
|
|
|
|||
|
|
@ -3,7 +3,8 @@
|
|||
"dependencies": {
|
||||
"remark-cli": "^6.0.1",
|
||||
"remark-lint": "^6.0.2",
|
||||
"remark-preset-lint-recommended": "^3.0.2"
|
||||
"remark-preset-lint-recommended": "^3.0.2",
|
||||
"remark-validate-links": "^10.0.0"
|
||||
},
|
||||
"scripts": {
|
||||
"lint": "remark ."
|
||||
|
|
|
|||
Loading…
Reference in New Issue