vacp2p/rfc.vac.dev
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc.vac.dev.git synced 2026-01-09 22:27:59 -05:00
Code Issues Packages Projects Releases Wiki Activity

chore: MD content updates (#7)

Browse Source 
* chore: MD content updates

* fix: comparison symbol parsing by groups

* chore: MD content updates
This commit is contained in:
Filip Pajic
2024-05-13 11:59:40 +02:00
committed by GitHub
parent 802fdfe62b
commit 40a3a4604d
55 changed files with 941 additions and 550 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
status/24/curation.md
View File

@@ -3,10 +3,10 @@ title: 24/STATUS-CURATION
name: Status Community Directory Curation Voting using Waku v2
status: draft
description: A voting protocol for SNT holders to submit votes to a smart contract. Voting is immutable, which helps avoid sabotage from malicious peers.
editor: Szymon Szlachtowicz \<szymon.s@ethworks.io\>
editor: Szymon Szlachtowicz &lt;szymon.s@ethworks.io&gt;
---
- Status: draft
- Editor: Szymon Szlachtowicz \<szymon.s@ethworks.io\>
- Editor: Szymon Szlachtowicz &lt;szymon.s@ethworks.io&gt;
## Abstract
This specification is a voting protocol for peers to submit votes to a smart contract. Voting is immutable,

4
status/28/featuring.md
View File

@@ -3,10 +3,10 @@ title: 28/STATUS-FEATURING
name: Status community featuring using waku v2
status: draft
description: To gain new members, current SNT holders can vote to feature an active Status community to the larger Status audience.
editor: Szymon Szlachtowicz \<szymon.s@ethworks.io\>
editor: Szymon Szlachtowicz &lt;szymon.s@ethworks.io&gt;
---
- Status: draft
- Editor: Szymon Szlachtowicz \<szymon.s@ethworks.io\>
- Editor: Szymon Szlachtowicz &lt;szymon.s@ethworks.io&gt;
## Abstract
This specification describes a voting method to feature different active Status Communities.

21
status/55/1to1-chat.md
View File

@@ -4,18 +4,23 @@ name: Status 1-to-1 Chat
status: draft
category: Standards Track
description: A chat protocol to send public and private messages to a single recipient by the Status app.
editor: Aaryamann Challani \<aaryamann@status.im\>
editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
contributors:
- Andrea Piana \<andreap@status.im\>
- Pedro Pombeiro \<pedro@status.im\>
- Corey Petty \<corey@status.im\>
- Oskar Thorén \<oskarth@titanproxy.com\>
- Dean Eigenmann \<dean@status.im\>
- Andrea Piana &lt;andreap@status.im&gt;
- Pedro Pombeiro &lt;pedro@status.im&gt;
- Corey Petty &lt;corey@status.im&gt;
- Oskar Thorén &lt;oskarth@titanproxy.com&gt;
- Dean Eigenmann &lt;dean@status.im&gt;
---
- Status: draft
- Category: Standards Track
- Editor: Aaryamann Challani \<aaryamann@status.im\>
- Contributors::
- Editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
- Contributors:
- Andrea Piana &lt;andreap@status.im&gt;
- Pedro Pombeiro &lt;pedro@status.im&gt;
- Corey Petty &lt;corey@status.im&gt;
- Oskar Thorén &lt;oskarth@titanproxy.com&gt;
- Dean Eigenmann &lt;dean@status.im&gt;
## Abstract

31
status/56/communities.md
View File

@@ -4,14 +4,15 @@ name: Status Communities that run over Waku v2
status: draft
category: Standards Track
description: Status Communities allow multiple users to communicate in a discussion space. This is a key feature of the Status application.
editor: Aaryamann Challani \<aaryamann@status.im\>
editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
contributors:
- Andrea Piana \<andreap@status.im\>
- Andrea Piana &lt;andreap@status.im&gt;
---
- Status: draft
- Category: Standards Track
- Editor: Aaryamann Challani \<aaryamann@status.im\>
- Contributors::
- Editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
- Contributors:
- Andrea Piana &lt;andreap@status.im&gt;
## Abstract
@@ -126,7 +127,7 @@ message ChatIdentity {
// ens_name is the valid ENS name associated with the chat key
string ens_name = 2;
// images is a string indexed mapping of images associated with an identity
map\<string, IdentityImage\> images = 3;
map<string, IdentityImage> images = 3;
// display name is the user set identity
string display_name = 4;
// description is the user set description
@@ -185,7 +186,7 @@ message CommunityAdminSettings {
message CommunityChat {
// A map of members in the community to their roles in a chat
map\<string,CommunityMember\> members = 1;
map<string,CommunityMember> members = 1;
// The permissions of the chat
CommunityPermissions permissions = 2;
// The metadata of the chat
@@ -268,17 +269,17 @@ message CommunityDescription {
// The Lamport timestamp of the message
uint64 clock = 1;
// A mapping of members in the community to their roles
map\<string,CommunityMember\> members = 2;
map<string,CommunityMember> members = 2;
// The permissions of the Community
CommunityPermissions permissions = 3;
// The metadata of the Community
ChatIdentity identity = 5;
// A mapping of chats to their details
map\<string,CommunityChat\> chats = 6;
map<string,CommunityChat> chats = 6;
// A list of banned members
repeated string ban_list = 7;
// A mapping of categories to their details
map\<string,CommunityCategory\> categories = 8;
map<string,CommunityCategory> categories = 8;
// The admin settings of the Community
CommunityAdminSettings admin_settings = 10;
// If the community is encrypted
@@ -303,12 +304,12 @@ The content topic MUST be the first four bytes of the keccak-256 hash of the com
hash = hex(keccak256(encodeToHex(compressedPublicKey)))
topicLen = 4
if len(hash) \< topicLen {
if len(hash) < topicLen {
topicLen = len(hash)
}
var topic [4]byte
for i = 0; i \< topicLen; i++ {
for i = 0; i < topicLen; i++ {
topic[i] = hash[i]
}
@@ -327,11 +328,11 @@ The content topic that Community channels/chats use MUST be the hex-encoded kecc
hash = hex(keccak256(encodeToHex(compressedPublicKey + chatId)))
topicLen = 4
if len(hash) \< topicLen {
if len(hash) < topicLen {
topicLen = len(hash)
}
var topic [4]byte
for i = 0; i \< topicLen; i++ {
for i = 0; i < topicLen; i++ {
topic[i] = hash[i]
}
@@ -348,11 +349,11 @@ The content topic MUST be the hex-encoded keccak-256 hash of the public key of t
hash = hex(keccak256(encodeToHex(publicKey)))
topicLen = 4
if len(hash) \< topicLen {
if len(hash) < topicLen {
topicLen = len(hash)
}
var topic [4]byte
for i = 0; i \< topicLen; i++ {
for i = 0; i < topicLen; i++ {
topic[i] = hash[i]
}

17
status/61/community-history-service.md
View File

@@ -4,17 +4,18 @@ name: Status Community History Service
status: draft
category: Standards Track
description: Explains how new members of a Status community can request historical messages from archive nodes.
editor: r4bbit \<r4bbit@status.im\>
editor: r4bbit &lt;r4bbit@status.im&gt;
contributors:
- Sanaz Taheri \<sanaz@status.im\>
- John Lea \<john@status.im\>
- Sanaz Taheri &lt;sanaz@status.im&gt;
- John Lea &lt;john@status.im&gt;
---
- Status: draft
- Category: Standards Track
- Editor: r4bbit \<r4bbit@status.im\>
- Contributors::
- Sanaz Taheri \<sanaz@status.im\>
- John Lea \<john@status.im\>
- Editor: r4bbit &lt;r4bbit@status.im&gt;
- Contributors:
- Sanaz Taheri &lt;sanaz@status.im&gt;
- John Lea &lt;john@status.im&gt;
## Abstract
@@ -188,7 +189,7 @@ message WakuMessageArchiveIndexMetadata {
}
message WakuMessageArchiveIndex {
map\<string, WakuMessageArchiveIndexMetadata\> archives = 1
map<string, WakuMessageArchiveIndexMetadata> archives = 1
}
```

46
status/62/payloads.md
View File

@@ -2,16 +2,20 @@
title: 62/STATUS-Payloads
name: Status Message Payloads
status: draft
editor: r4bbit \<r4bbit@status.im\>
editor: r4bbit &lt;r4bbit@status.im&gt;
contributors:
- Adam Babik \<adam@status.im\>
- Andrea Maria Piana \<andreap@status.im\>
- Oskar Thoren \<oskarth@titanproxy.com\>
- Samuel Hawksby-Robinson \<samuel@status.im\>
- Adam Babik &lt;adam@status.im&gt;
- Andrea Maria Piana &lt;andreap@status.im&gt;
- Oskar Thoren &lt;oskarth@titanproxy.com&gt;
- Samuel Hawksby-Robinson &lt;samuel@status.im&gt;
---
- Status: draft
- Editor: r4bbit \<r4bbit@status.im\>
- Contributors::
- Editor: r4bbit &lt;r4bbit@status.im&gt;
- Contributors:
- Adam Babik &lt;adam@status.im&gt;
- Andrea Maria Piana &lt;andreap@status.im&gt;
- Oskar Thoren &lt;oskarth@titanproxy.com&gt;
- Samuel Hawksby-Robinson &lt;samuel@status.im&gt;
## Abstract
@@ -285,11 +289,9 @@ message DiscordMessageAttachment {
A node requires message types to decide how to encrypt a particular message and what metadata needs to be attached when passing a message to the transport layer.
For more on this, see [10/WAKU2](../../waku/standards/core/10/waku2).
<!-- TODO: This reference is a bit odd, considering the layer payloads should interact with is Secure Transport, and not Whisper/Waku. This requires more detail -->
The following messages types MUST be supported:
* `ONE_TO_ONE` is a message to the public group
* `PUBLIC_GROUP` is a private message
@@ -317,7 +319,7 @@ This is where the basic algorithm of Lamport timestamp would fall short as it's
The status client therefore makes a "bid", speculating that it will beat the current chat-timestamp, s.t. the status client's Lamport timestamp format is: `clock = `max({timestamp}, chat_clock + 1)`
This will satisfy the Lamport requirement, namely: a -\> b then T(a) \< T(b)
This will satisfy the Lamport requirement, namely: a -> b then T(a) < T(b)
`timestamp` MUST be Unix time calculated, when the node creates the message, in milliseconds.
This field SHOULD not be relied upon for message ordering.
@@ -600,7 +602,7 @@ message SyncPairInstallation {
message ChatIdentity {
uint64 clock = 1;
string ens_name = 2;
map\<string, IdentityImage\> images = 3;
map&lt;string, IdentityImage&gt; images = 3;
string display_name = 4;
string description = 5;
string color = 6;
@@ -619,12 +621,12 @@ message ChatIdentity {
| ----- | ---- | ---- | ---- |
| 1 | clock | `uint64` | Clock value of the message |
| 2| ens_name | `string` | A valid ENS associated with the chat key |
| 3 | images | `map\<string, IdentityImage\>` | Image data associated with the chat key |
| 3 | images | `map<string, IdentityImage>` | Image data associated with the chat key |
| 4 | display_name | `string` | The self-assigned display_name of the chat key |
| 5 | description | `string` | The description of the chat |
| 6 | color | `string` | The color of the chat |
| 7 | emoji | `string` | The emoji of the chat |
| 8 | social_links | `array\<SocialLink\>` | A list of links to social platforms |
| 8 | social_links | `array<SocialLink>` | A list of links to social platforms |
| 9 | first_message_timestamp | `uint32` | First known message timestamp in seconds |
### CommunityDescription
@@ -635,19 +637,19 @@ message ChatIdentity {
```protobuf
message CommunityDescription {
uint64 clock = 1;
map\<string,CommunityMember\> members = 2;
map&lt;string,CommunityMember&gt; members = 2;
CommunityPermissions permissions = 3;
ChatIdentity identity = 5;
map\<string,CommunityChat\> chats = 6;
map&lt;string,CommunityChat&gt; chats = 6;
repeated string ban_list = 7;
map\<string,CommunityCategory\> categories = 8;
map&lt;string,CommunityCategory&gt; categories = 8;
uint64 archive_magnetlink_clock = 9;
CommunityAdminSettings admin_settings = 10;
string intro_message = 11;
string outro_message = 12;
bool encrypted = 13;
repeated string tags = 14;
map\<string, CommunityTokenPermission\> token_permissions = 15;
map&lt;string, CommunityTokenPermission&gt; token_permissions = 15;
repeated CommunityTokenMetadata community_tokens_metadata = 16;
uint64 active_members_count = 17;
}
@@ -686,13 +688,13 @@ message CommunityPermissions {
| Field | Name | Type | Description |
| ----- | ---- | ---- | ---- |
| 1 | clock | `uint64` | Clock value of the message |
| 2| members | `map\<string, CommunityMember\>` | The members of the community |
| 2| members | `map<string, CommunityMember>` | The members of the community |
| 3 | permissions | `CommunityPermissions` | Image data associated with the chat key |
| 4 | display_name | `string` | The self-assigned display_name of the chat key |
| 5 | description | `string` | The description of the chat |
| 6 | color | `string` | The color of the chat |
| 7 | emoji | `string` | The emoji of the chat |
| 8 | social_links | `array\<SocialLink\>` | A list of links to social platforms |
| 8 | social_links | `array<SocialLink>` | A list of links to social platforms |
| 9 | first_message_timestamp | `uint32` | First known message timestamp in seconds |
### CommunityRequestToJoin
@@ -728,7 +730,7 @@ message RevealedAccount {
| 3 | chat_id | `string` | The id of the chat to request access to |
| 4 | community_id | `bytes` | The public key of the community |
| 5 | display_name | `string` | The display name of the usre sending the request |
| 6 | revealed_accounts | `array\<RevealedAccount\>` | A list of accounts to reveal to the control node |
| 6 | revealed_accounts | `array<RevealedAccount>` | A list of accounts to reveal to the control node |
### PinMessage
@@ -789,7 +791,7 @@ message EditMessage {
| 5 | grant | `bytes` | A grant for a community edit messages |
| 6 | message_type | `MessageType` | The type of message |
| 7 | content_type | `ChatMessage.ContentType` | The updated content type of the message |
| 8 | unfurled_links | `array\<UnfurledLink\>` | Updated link metadata |
| 8 | unfurled_links | `array<UnfurledLink>` | Updated link metadata |
### DeleteMessage
@@ -1042,7 +1044,7 @@ message CommunityEditSharedAddresses {
| ----- | ---- | ---- | ---- |
| 1 | clock | `uint64` | Clock value of the message |
| 2 | community_id | `bytes` | The id of the community |
| 3 | revealed_accounts | `array\<RevealedAccount\>` | A list of revealed accounts |
| 3 | revealed_accounts | `array&lt;RevealedAccount&gt;` | A list of revealed accounts |
## Upgradability

31
status/63/keycard-usage.md
View File

@@ -4,15 +4,16 @@ name: Status Keycard Usage
status: draft
category: Standards Track
description: Describes how an application can use the Status Keycard to create, store and transact with different account addresses.
editor: Aaryamann Challani \<aaryamann@status.im\>
editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
contributors:
- Jimmy Debe \<jimmy@status.im\>
- Jimmy Debe &lt;jimmy@status.im&gt;
---
- Status: draft
- Category: Standards Track
- Editor: Aaryamann Challani \<aaryamann@status.im\>
- Contributors::
- Jimmy Debe \<jimmy@status.im\>
- Editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
- Contributors:
- Jimmy Debe &lt;jimmy@status.im&gt;
## Terminology
@@ -74,7 +75,7 @@ To fetch if the keycard is ready to be used by the application.
The requester MAY add a `pairing` field to filter through the generated keys
```json
{
"pairing": \<shared_secret\>/\<pairing_index\>/\<256_bit_salt\> OR null
"pairing": <shared_secret>/<pairing_index>/<256_bit_salt> OR null
}
```
@@ -118,7 +119,7 @@ To establish a secure communication channel described [here](https://keycard.tec
#### Response wire format
```json
"\<shared_secret\>/\<pairing_index\>/\<256_bit_salt\>"
"<shared_secret>/<pairing_index>/<256_bit_salt>"
```
### 4. Generate a new set of keys (`/generate-and-load-keys`)
@@ -130,7 +131,7 @@ To generate a new set of keys and load them onto the keycard.
```json
{
"mnemonic": 12_word_mnemonic,
"pairing": \<shared_secret\>/\<pairing_index\>/\<256_bit_salt\>,
"pairing": <shared_secret>/<pairing_index>/<256_bit_salt>,
"pin": 6_digit_pin
}
```
@@ -162,7 +163,7 @@ To fetch the keys that are currently loaded on the keycard.
```json
{
"pairing": \<shared_secret\>/\<pairing_index\>/\<256_bit_salt\>,
"pairing": <shared_secret>/<pairing_index>/<256_bit_salt>,
"pin": 6_digit_pin
}
```
@@ -195,7 +196,7 @@ To sign a transaction using the keycard, passing in the pairing information and
```json
{
"hash": 64_byte_hash_of_the_transaction,
"pairing": \<shared_secret\>/\<pairing_index\>/\<256_bit_salt\>,
"pairing": <shared_secret>/<pairing_index>/<256_bit_salt>,
"pin": 6_digit_pin,
"path": bip32_path_to_the_key
}
@@ -204,7 +205,7 @@ To sign a transaction using the keycard, passing in the pairing information and
#### Response wire format
```json
\<256_bit_signature\>
<256_bit_signature>
```
### 7. Export a key (`/export-key`)
@@ -215,7 +216,7 @@ To export a key from the keycard, passing in the pairing information and the pat
```json
{
"pairing": \<shared_secret\>/\<pairing_index\>/\<256_bit_salt\>,
"pairing": <shared_secret>/<pairing_index>/<256_bit_salt>,
"pin": 6_digit_pin,
"path": bip32_path_to_the_key
}
@@ -224,7 +225,7 @@ To export a key from the keycard, passing in the pairing information and the pat
#### Response wire format
```json
\<256_bit_public_key\>
<256_bit_public_key>
```
### 8. Verify a pin (`/verify-pin`)
@@ -262,7 +263,7 @@ To change the pin of the keycard.
{
"new-pin": 6_digit_new_pin,
"current-pin": 6_digit_new_pin,
"pairing": \<shared_secret\>/\<pairing_index\>/\<256_bit_salt\>
"pairing": <shared_secret>/<pairing_index>/<256_bit_salt>
}
```
@@ -290,7 +291,7 @@ If the Keycard is blocked due to too many incorrect pin attempts, it can be unbl
{
"puk": 12_digit_recovery_code,
"new-pin": 6_digit_new_pin,
"pairing": \<shared_secret\>/\<pairing_index\>/\<256_bit_salt\>
"pairing": <shared_secret>/<pairing_index>/<256_bit_salt>
}
```

15
status/65/account-address.md
View File

@@ -4,16 +4,19 @@ name: Status Account Address
status: draft
category: Standards Track
description: Details of what a Status account address is and how account addresses are created and used.
editor: Aaryamann Challani \<aaryamann@status.im\>
editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
contributors:
- Corey Petty \<corey@status.im\>
- Oskar Thorén \<oskarth@titanproxy.com\>
- Samuel Hawksby-Robinson \<samuel@status.im\>
- Corey Petty &lt;corey@status.im&gt;
- Oskar Thorén &lt;oskarth@titanproxy.com&gt;
- Samuel Hawksby-Robinson &lt;samuel@status.im&gt;
---
- Status: draft
- Category: Standards Track
- Editor: Aaryamann Challani \<aaryamann@status.im\>
- Contributors::
- Editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
- Contributors:
- Corey Petty &lt;corey@status.im&gt;
- Oskar Thorén &lt;oskarth@titanproxy.com&gt;
- Samuel Hawksby-Robinson &lt;samuel@status.im&gt;
## Abstract

97
status/71/push-notification-server.md
View File

@@ -4,15 +4,16 @@ name: Push Notification Server
status: draft
category: Standards Track
description: A set of methods to allow Status clients to use push notification services in mobile environments.
editor: Jimmy Debe \<jimmy@status.im\>
editor: Jimmy Debe &lt;jimmy@status.im&gt;
contributors:
- Andrea Maria Piana \<andreap@status.im\>
- Andrea Maria Piana &lt;andreap@status.im&gt;
---
- Status: draft
- Category: Standards Track
- Editor: Jimmy Debe \<jimmy@status.im\>
- Contributors::
- Andrea Maria Piana \<andreap@status.im\>
- Editor: Jimmy Debe &lt;jimmy@status.im&gt;
- Contributors:
- Andrea Maria Piana &lt;andreap@status.im&gt;
## Abstract
A push notification server implementation for IOS devices and Android devices.
@@ -156,8 +157,8 @@ A client SHOULD listen for a response sent on the [partitioned topic](../../waku
If success is true the client has registered successfully.
If `success` is `false`:
\> If `MALFORMED_MESSAGE` is returned, the request SHOULD NOT be retried without ensuring that it is correctly formed.
\> If `INTERNAL_ERROR` is returned, the request MAY be retried, but the client MUST backoff exponentially.
&gt; If `MALFORMED_MESSAGE` is returned, the request SHOULD NOT be retried without ensuring that it is correctly formed.
&gt; If `INTERNAL_ERROR` is returned, the request MAY be retried, but the client MUST backoff exponentially.
#### Handle Errors:
- If the message can’t be decrypted, the message MUST be discarded.
@@ -186,7 +187,7 @@ A node that handles receiving and sending push notifications for clients.
### Query Topic:
On successful registration the server MUST be listening to the topic derived from:
\> `0x` + HexEncode(Shake256(CompressedClientPublicKey))
&gt; `0x` + HexEncode(Shake256(CompressedClientPublicKey))
Using the topic derivation algorithm described here and listen for client queries.
@@ -195,7 +196,7 @@ A client MUST authorize a push notification server to send them push notificatio
This is done by building a grant which is specific to a given client-server pair.
When receiving a grant, the server MUST validate that the signature matches the registering client.
The grant is built as:\<br /\>
The grant is built as:&lt;br /&gt;
`Signature(Keccak256(CompressedPublicKeyOfClient . CompressedPublicKeyOfServer . AccessToken), PrivateKeyOfClient)`
#### Unregistering with a Server:
@@ -424,22 +425,22 @@ MUST not be encrypted using the [secure transport](../../waku/standards/applica
### Protobuf Description
#### PushNotificationRegistration:
`token_type`: the type of token. Currently supported is `APN_TOKEN` for Apple Push.\<br /\>
`device_token`: the actual push notification token sent by `Firebase` or `APN` and `FIREBASE_TOKEN` for firebase.\<br /\>
`installation_id`: the `installation_id` of the device.\<br /\>
`access_token`: the access token that will be given to clients to send push notifications.\<br /\>
`enabled`: whether the device wants to be sent push notifications.\<br /\>
`token_type`: the type of token. Currently supported is `APN_TOKEN` for Apple Push.&lt;br /&gt;
`device_token`: the actual push notification token sent by `Firebase` or `APN` and `FIREBASE_TOKEN` for firebase.&lt;br /&gt;
`installation_id`: the `installation_id` of the device.&lt;br /&gt;
`access_token`: the access token that will be given to clients to send push notifications.&lt;br /&gt;
`enabled`: whether the device wants to be sent push notifications.&lt;br /&gt;
`version`: a monotonically increasing number identifying the current `PushNotificationRegistration`.
Any time anything is changed in the record it MUST be increased by the client, otherwise the request will not be accepted.\<br /\>
Any time anything is changed in the record it MUST be increased by the client, otherwise the request will not be accepted.&lt;br /&gt;
`allowed_key_list`: a list of `access_token` encrypted with the AES key generated by Diffie–Hellman between the publisher and the
allowed contact.\<br /\>
`blocked_chat_list`: a list of `SHA2-256` hashes of chat ids. Any chat id in this list will not trigger a notification.\<br /\>
`unregister`: whether the account should be unregistered.\<br /\>
`grant`: the grant for this specific server.\<br /\>
`allow_from_contacts_only`: whether the client only wants push notifications from contacts.\<br /\>
`apn_topic`: the APN topic for the push notification.\<br /\>
`block_mentions`: whether the client does not want to be notified on mentions.\<br /\>
`allowed_mentions_chat_list`: a list of SHA2-256 hashes of chat ids where we want to receive mentions.\<br /\>
allowed contact.&lt;br /&gt;
`blocked_chat_list`: a list of `SHA2-256` hashes of chat ids. Any chat id in this list will not trigger a notification.&lt;br /&gt;
`unregister`: whether the account should be unregistered.&lt;br /&gt;
`grant`: the grant for this specific server.&lt;br /&gt;
`allow_from_contacts_only`: whether the client only wants push notifications from contacts.&lt;br /&gt;
`apn_topic`: the APN topic for the push notification.&lt;br /&gt;
`block_mentions`: whether the client does not want to be notified on mentions.&lt;br /&gt;
`allowed_mentions_chat_list`: a list of SHA2-256 hashes of chat ids where we want to receive mentions.&lt;br /&gt;
DATA DISCLOSED
- Type of device owned by a given user.
@@ -453,10 +454,10 @@ DATA DISCLOSED
- The number of contacts a client has, in case `allowed_key_list` is set.
#### PushNotificationRegistrationResponse:
`success`: whether the registration was successful\<br /\>
`error`: the error type, if any\<br /\>
`request_id`: the `SHAKE-256` hash of the `signature` of the request\<br /\>
`preferences`: the server stored preferences in case of an error\<br /\>
`success`: whether the registration was successful&lt;br /&gt;
`error`: the error type, if any&lt;br /&gt;
`request_id`: the `SHAKE-256` hash of the `signature` of the request&lt;br /&gt;
`preferences`: the server stored preferences in case of an error&lt;br /&gt;
#### ContactCodeAdvertisement:
`push_notification_info`: the information for each device advertised
@@ -471,26 +472,26 @@ DATA DISCLOSED
- The hash of the public keys the client is interested in
#### PushNotificationQueryInfo:
`access_token`: the access token used to send a push notification\<br /\>
`installation_id`: the `installation_id` of the device associated with the `access_token`\<br /\>
`public_key`: the `SHAKE-256` of the public key associated with this `access_token` and `installation_id`.\<br /\>
`allowed_key_list`: a list of encrypted access tokens to be returned to the client in case there’s any filtering on public keys in place.\<br /\>
`grant`: the grant used to register with this server.\<br /\>
`version`: the version of the registration on the server.\<br /\>
`server_public_key`: the compressed public key of the server.\<br /\>
`access_token`: the access token used to send a push notification&lt;br /&gt;
`installation_id`: the `installation_id` of the device associated with the `access_token`&lt;br /&gt;
`public_key`: the `SHAKE-256` of the public key associated with this `access_token` and `installation_id`.&lt;br /&gt;
`allowed_key_list`: a list of encrypted access tokens to be returned to the client in case there’s any filtering on public keys in place.&lt;br /&gt;
`grant`: the grant used to register with this server.&lt;br /&gt;
`version`: the version of the registration on the server.&lt;br /&gt;
`server_public_key`: the compressed public key of the server.&lt;br /&gt;
#### PushNotificationQueryResponse:
`info`: a list of `PushNotificationQueryInfo`.\<br /\>
`message_id`: the message id of the `PushNotificationQueryInfo` the server is replying to.\<br /\>
`success`: whether the query was successful.\<br /\>
`info`: a list of `PushNotificationQueryInfo`.&lt;br /&gt;
`message_id`: the message id of the `PushNotificationQueryInfo` the server is replying to.&lt;br /&gt;
`success`: whether the query was successful.&lt;br /&gt;
#### PushNotification:
`access_token`: the access token used to send a push notification.\<br /\>
`chat_id`: the `SHAKE-256` of the `chat_id`.\<br /\>
`public_key`: the `SHAKE-256` of the compressed public key of the receiving client.\<br /\>
`installation_id`: the `installation_id` of the receiving client.\<br /\>
`message`: the encrypted message that is being notified on.\<br /\>
`type`: the type of the push notification, either `MESSAGE` or `MENTION`\<br /\>
`access_token`: the access token used to send a push notification.&lt;br /&gt;
`chat_id`: the `SHAKE-256` of the `chat_id`.&lt;br /&gt;
`public_key`: the `SHAKE-256` of the compressed public key of the receiving client.&lt;br /&gt;
`installation_id`: the `installation_id` of the receiving client.&lt;br /&gt;
`message`: the encrypted message that is being notified on.&lt;br /&gt;
`type`: the type of the push notification, either `MESSAGE` or `MENTION`&lt;br /&gt;
`author`: the `SHAKE-256` of the public key of the sender
Data disclosed
@@ -503,20 +504,20 @@ Data disclosed
- The type of notification
#### PushNotificationRequest:
`requests`: a list of PushNotification\<br /\>
`requests`: a list of PushNotification&lt;br /&gt;
`message_id`: the [Status message id](../62/payloads)
Data disclosed
- The status `message_id` for which the notification is for
#### PushNotificationResponse:
`message_id`: the `message_id` being notified on.\<br /\>
`message_id`: the `message_id` being notified on.&lt;br /&gt;
`reports`: a list of `PushNotificationReport`
#### PushNotificationReport:
`success`: whether the push notification was successful.\<br /\>
`error`: the type of the error in case of failure.\<br /\>
`public_key`: the public key of the user being notified.\<br /\>
`success`: whether the push notification was successful.&lt;br /&gt;
`error`: the type of the error in case of failure.&lt;br /&gt;
`public_key`: the public key of the user being notified.&lt;br /&gt;
`installation_id`: the `installation_id` of the user being notified.
### Anonymous Mode

41
status/raw/simple-scaling.md
View File

@@ -5,14 +5,15 @@ name: Status Simple Scaling
status: raw
category: Informational
description: Describes how to scale Status Communities and Status 1-to-1 chats using Waku v2 protocol and components.
editor: Daniel Kaiser \<danielkaiser@status.im\>
editor: Daniel Kaiser &lt;danielkaiser@status.im&gt;
contributors:
- Alvaro Revuelta \<alrevuelta@status.im\>
- Alvaro Revuelta &lt;alrevuelta@status.im&gt;
---
- Status: raw
- Category: Informational
- Editor: Daniel Kaiser \<danielkaiser@status.im\>
- Contributors::
- Editor: Daniel Kaiser &lt;danielkaiser@status.im&gt;
- Contributors:
- Alvaro Revuelta &lt;alrevuelta@status.im&gt;
## Abstract
@@ -21,7 +22,7 @@ This document describes how to scale [56/STATUS-COMMUNITIES](../56/communities)
using Waku v2 protocol and components.
It also adds a few new aspects, where more sophisticated components are not yet researched and evaluated.
\> *Note:* (Parts of) this RFC will be deprecated in the future as we continue research to scale specific components
&gt; *Note:* (Parts of) this RFC will be deprecated in the future as we continue research to scale specific components
in a way that aligns better with our principles of decentralization and protecting anonymity.
This document informs about scaling at the current stage of research and shows it is practically possible.
Practical feasibility is also a core goal for us.
@@ -44,7 +45,7 @@ This document focuses on the second scaling dimension.
With the scaling solutions discussed in this document,
each content topics can have a large set of active users, but still has to fit in a single pubsub mesh.
\> *Note:* While it is possible to use the same content topic name on several shards,
&gt; *Note:* While it is possible to use the same content topic name on several shards,
each node that is interested in this content topic has to be subscribed to all respective shards, which does not scale.
Splitting content topics in a more sophisticated and efficient way will be part of a future document.
@@ -75,7 +76,7 @@ The 1024 shards within the main Status shard cluster are allocated as follows.
Shard indices are mapped to pubsub topic names as follows (specified in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding)).
`/waku/2/rs/\<cluster_id\>/\<shard_number\>`
`/waku/2/rs/<cluster_id>/<shard_number>`
an example for the shard with index `18` in the Status shard cluster:
@@ -114,17 +115,17 @@ message CommunityDescription {
// The Lamport timestamp of the message
uint64 clock = 1;
// A mapping of members in the community to their roles
map\<string,CommunityMember\> members = 2;
map<string,CommunityMember> members = 2;
// The permissions of the Community
CommunityPermissions permissions = 3;
// The metadata of the Community
ChatIdentity identity = 5;
// A mapping of chats to their details
map\<string,CommunityChat\> chats = 6;
map<string,CommunityChat> chats = 6;
// A list of banned members
repeated string ban_list = 7;
// A mapping of categories to their details
map\<string,CommunityCategory\> categories = 8;
map<string,CommunityCategory> categories = 8;
// The admin settings of the Community
CommunityAdminSettings admin_settings = 10;
// If the community is encrypted
@@ -136,12 +137,12 @@ message CommunityDescription {
}
```
\> *Note*: Currently, Status app has allocated shared cluster `16` in [52/WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc).
&gt; *Note*: Currently, Status app has allocated shared cluster `16` in [52/WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc).
Status app could allocate more shard clusters, for instance to establish a test net.
We could add the shard cluster index to the community description as well.
The recommendation for now is to keep it as a configuration option of the Status app.
\> *Note*: Once this RFC moves forward, the new community description protobuf fields should be mentioned in [56/STATUS-COMMUNITIES](../56/communities).
&gt; *Note*: Once this RFC moves forward, the new community description protobuf fields should be mentioned in [56/STATUS-COMMUNITIES](../56/communities).
Status communities can be mapped to shards in two ways: static, and owner-based.
@@ -154,7 +155,7 @@ The Status CC community uses index `16` (not to confuse with shard cluster index
#### Owner Mapping
\> *Note*: This way of mapping will be specified post-MVP.
&gt; *Note*: This way of mapping will be specified post-MVP.
Community owners can choose to map their communities to any shard within the index range `128 - 767`.
@@ -206,7 +207,7 @@ Recommendations on choosing this subset will be added in a future version of thi
Desktop clients can choose to only use filter and lightpush.
\> *Note*: Discussion: I'd suggest to set this as the default for the MVP.
&gt; *Note*: Discussion: I'd suggest to set this as the default for the MVP.
The load on infrastructure nodes would not be higher, because they have to receive and relay each message anyways.
This comes as a trade-off to anonymity and decentralization,
but can significantly improve scaling.
@@ -250,7 +251,7 @@ Large communities MAY choose to mainly rely on infrastructure nodes for *all* me
Desktop clients of such communities should use light protocols as the default.
Strong Desktop clients MAY opt in to support the relay network.
\> *Note*: This is not planned for the MVP.
&gt; *Note*: This is not planned for the MVP.
## Light Protocols
@@ -275,7 +276,7 @@ Nodes can request history messages via the [13/WAKU2-STORE](../../waku/standards
The store service is not limited to a Status fleet.
Anybody can run a Waku Archive node in the Status shards.
\> *Note*: There is no specification for discovering archive nodes associated with specific shards yet.
&gt; *Note*: There is no specification for discovering archive nodes associated with specific shards yet.
Nodes expect archive nodes to store all messages, regardless of shard association.
The recommendation for the allocation of archive nodes to shards is similar to the
@@ -293,7 +294,7 @@ To make nodes behind restrictive NATs discoverable,
this document suggests using [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README).
Nodes can check whether they are behind a restrictive NAT using the [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README).
\> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding), or [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5):
&gt; *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding), or [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5):
Nodes behind restrictive NATs SHOULD not announce their publicly unreachable address via [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5) discovery.
It is RECOMMENDED that nodes that are part of the relay network also act as rendezvous points.
@@ -332,11 +333,11 @@ REGISTER{my-app, {QmA, AddrA}}
The app name, `my-app` contains the encoding of a single shard in string form:
```
"rs/"| to_string(\<2-byte shard cluster index\>) | "/" | to_string(\<2-byte shard index\>)
"rs/"| to_string(<2-byte shard cluster index>) | "/" | to_string(<2-byte shard index>)
```
The string conversion SHOULD remove leading zeros.
\> *Note:* Since the [ns](https://github.com/libp2p/specs/blob/master/rendezvous/README##protobuf) field is of type string,
&gt; *Note:* Since the [ns](https://github.com/libp2p/specs/blob/master/rendezvous/README##protobuf) field is of type string,
a more efficient byte encoding is not utilized.
Registering shard 2 in the Status shard cluster (with shard cluster index 16, see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc),
@@ -404,7 +405,7 @@ For simplicity, there is just one key per topic. Since this approach has clear p
Requirements on the gossipsub validator:
* Relay nodes should use the existing gossipsub validators that allow to `Accept` or `Reject` messages, according to the following criteria:
* If `timestamp` is not set (equals to 0) then `Reject` the message.
* If the `timestamp` is `abs(current_timestamp-timestamp) \> MessageWindowInSec` then `Reject` the message.
* If the `timestamp` is `abs(current_timestamp-timestamp) > MessageWindowInSec` then `Reject` the message.
* If `meta` is empty, `Reject` the message.
* If `meta` exists but its size is different than 64 bytes, `Reject` the message.
* If `meta` does not successfully verifies according to the ECDSA signature verification algorithm using `public-key-topic` and `app-message-hash`, then `Reject` the message.

9
status/raw/status-waku-usage.md
View File

@@ -4,15 +4,16 @@ name: Status Waku2 Usage
status: raw
category: Best Current Practice
description: Defines how the Status application uses the Waku protocols.
editor: Aaryamann Challani \<aaryamann@status.im\>
editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
contributors:
- Jimmy Debe \<jimmy@status.im\>
- Jimmy Debe &lt;jimmy@status.im&gt;
---
- Status: raw
- Category: Best Current Practice
- Editor: Aaryamann Challani \<aaryamann@status.im\>
- Contributors::
- Editor: Aaryamann Challani &lt;aaryamann@status.im&gt;
- Contributors:
- Jimmy Debe &lt;jimmy@status.im&gt;
## Abstract