mirror of
https://github.com/vacp2p/rfc.vac.dev.git
synced 2025-02-22 04:18:27 +00:00
chore: MD content updates (#7)
* chore: MD content updates * fix: comparison symbol parsing by groups * chore: MD content updates
This commit is contained in:
Filip Pajic
GitHub
parent
802fdfe62b
commit
40a3a4604d
@ -14,7 +14,7 @@ function enhanceMarkdownWithBulletPointsCorrected(input) {
|
||||
inFrontMatter = !inFrontMatter
|
||||
if (!inFrontMatter && contributorsLines.length) {
|
||||
// We're exiting frontmatter; time to add contributors
|
||||
extractedFields.push(`contributors\n${contributorsLines.join('\n')}`)
|
||||
extractedFields.push(`contributors\n${contributorsLines.join('\n')}\n`)
|
||||
contributorsLines = [] // Reset for safety
|
||||
}
|
||||
return line // Keep the frontmatter delimiters
|
||||
@ -80,11 +80,34 @@ function parseSlugFromFrontmatter(content) {
|
||||
return 1 // Return null if not found
|
||||
}
|
||||
|
||||
// Escape < and > with < and >, respectively
|
||||
// Be cautious with this replacement; adjust as needed based on your context
|
||||
function escapeHtmlTagSymbols(content) {
|
||||
// Escape < and > with < and >, respectively
|
||||
// Be cautious with this replacement; adjust as needed based on your context
|
||||
content = content.replace(/(?<!`)<(?!.*?`)/g, '<')
|
||||
content = content.replace(/(?<!`)>(?!.*?`)/g, '>')
|
||||
function replaceComparisonSymbol(text, symbol) {
|
||||
// Regex to match everything, but we'll handle what to replace in the callback
|
||||
let regex = /(```[\s\S]+?```|`[^`]*`)|(<)/g;
|
||||
let replacementString = "<";
|
||||
|
||||
if (symbol === ">") {
|
||||
regex = /(```[\s\S]+?```|`[^`]*`)|(>)/g;
|
||||
replacementString = ">";
|
||||
}
|
||||
|
||||
return text.replace(regex, function(match, code, lessThan) {
|
||||
if (code) {
|
||||
// It's a code segment, return it unchanged
|
||||
return code;
|
||||
} else if (lessThan) {
|
||||
// It's a '<' outside of code blocks, replace with '<'
|
||||
return replacementString;
|
||||
}
|
||||
// Default return (though practically unused in this setup)
|
||||
return match;
|
||||
});
|
||||
}
|
||||
|
||||
content = replaceComparisonSymbol(content, "<")
|
||||
content = replaceComparisonSymbol(content, ">")
|
||||
|
||||
return content;
|
||||
}
|
||||
|
||||
@ -3,18 +3,20 @@ title: 38/CONSENSUS-CLARO
|
||||
name: Claro Consensus Protocol
|
||||
status: raw
|
||||
category: Standards Track
|
||||
editor: Corey Petty \<corey@status.im\>
|
||||
editor: Corey Petty <corey@status.im>
|
||||
created: 01-JUL-2022
|
||||
revised: \<2022-08-26 Fri 13:11Z\>
|
||||
uri: \<https://rdf.logos.co/protocol/Claro/1/0/0#\<2022-08-26%20Fri$2013:11Z\>
|
||||
revised: <2022-08-26 Fri 13:11Z>
|
||||
uri: <https://rdf.logos.co/protocol/Claro/1/0/0#<2022-08-26%20Fri$2013:11Z>
|
||||
contributors:
|
||||
- Álvaro Castro-Castilla
|
||||
- Mark Evenson
|
||||
---
|
||||
- Status: raw
|
||||
- Category: Standards Track
|
||||
- Editor: Corey Petty \<corey@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Corey Petty <corey@status.im>
|
||||
- Contributors:
|
||||
- Álvaro Castro-Castilla
|
||||
- Mark Evenson
|
||||
|
||||
|
||||
## Abstract
|
||||
@ -132,7 +134,7 @@ The node has a semantics and serialization of the proposal, of which
|
||||
it sets an initial opinion:
|
||||
|
||||
opinion
|
||||
\<-- initial opinion on truth of the proposal
|
||||
<-- initial opinion on truth of the proposal
|
||||
as one of: {NO, NONE, YES}
|
||||
|
||||
The proposal proceeds in asynchronous rounds, in which each node
|
||||
@ -154,35 +156,35 @@ The node initializes the following integer ratios as constants:
|
||||
|
||||
#
|
||||
confidence_threshold
|
||||
\<-- 1
|
||||
<-- 1
|
||||
|
||||
# constant look ahead for number of rounds we expect to finalize a
|
||||
# decision. Could be set dependent on number of nodes
|
||||
# visible in the current gossip graph.
|
||||
look_ahead
|
||||
\<-- 19
|
||||
<-- 19
|
||||
|
||||
# the confidence weighting parameter (aka alpha_1)
|
||||
certainty
|
||||
\<-- 4 / 5
|
||||
<-- 4 / 5
|
||||
doubt ;; the lack of confidence weighting parameter (aka alpha_2)
|
||||
\<-- 2 / 5
|
||||
<-- 2 / 5
|
||||
|
||||
k_multiplier ;; neighbor threshold multiplier
|
||||
\<-- 2
|
||||
<-- 2
|
||||
|
||||
;;; maximal threshold multiplier, i.e. we will never exceed
|
||||
;;; questioning k_initial * k_multiplier ^ max_k_multiplier_power peers
|
||||
max_k_multiplier_power
|
||||
\<-- 4
|
||||
<-- 4
|
||||
|
||||
;;; Initial number of nodes queried in a round
|
||||
k_initial
|
||||
\<-- 7
|
||||
<-- 7
|
||||
|
||||
;;; maximum query rounds before termination
|
||||
max_rounds ;; placeholder for simulation work, no justification yet
|
||||
\<-- 100
|
||||
<-- 100
|
||||
```
|
||||
|
||||
The following variables are needed to keep the state of Claro:
|
||||
@ -190,17 +192,17 @@ The following variables are needed to keep the state of Claro:
|
||||
```
|
||||
;; current number of nodes to attempt to query in a round
|
||||
k
|
||||
\<-- k_original
|
||||
<-- k_original
|
||||
|
||||
;; total number of votes examined over all rounds
|
||||
total_votes
|
||||
\<-- 0
|
||||
<-- 0
|
||||
;; total number of YES (i.e. positive) votes for the truth of the proposal
|
||||
total_positive
|
||||
\<-- 0
|
||||
<-- 0
|
||||
;; the current query round, an integer starting from zero
|
||||
round
|
||||
\<-- 0
|
||||
<-- 0
|
||||
```
|
||||
|
||||
|
||||
@ -252,9 +254,9 @@ When the query finishes, the node now initializes the following two
|
||||
values:
|
||||
|
||||
new_votes
|
||||
\<-- |total vote replies received in this round to the current query|
|
||||
<-- |total vote replies received in this round to the current query|
|
||||
positive_votes
|
||||
\<-- |YES votes received from the query|
|
||||
<-- |YES votes received from the query|
|
||||
|
||||
### Phase Two: Computation
|
||||
When the query returns, three ratios are used later on to compute the
|
||||
@ -291,15 +293,15 @@ in the query round through the following algorithm:
|
||||
total_positive
|
||||
+== positive_votes
|
||||
confidence
|
||||
\<-- total_votes / (total_votes + look_ahead)
|
||||
<-- total_votes / (total_votes + look_ahead)
|
||||
total_evidence
|
||||
\<-- total_positive / total_votes
|
||||
<-- total_positive / total_votes
|
||||
new_evidence
|
||||
\<-- positive_votes / new_votes
|
||||
<-- positive_votes / new_votes
|
||||
evidence
|
||||
\<-- new_evidence * ( 1 - confidence ) + total_evidence * confidence
|
||||
<-- new_evidence * ( 1 - confidence ) + total_evidence * confidence
|
||||
alpha
|
||||
\<-- doubt * ( 1 - confidence ) + certainty * confidence
|
||||
<-- doubt * ( 1 - confidence ) + certainty * confidence
|
||||
|
||||
### Phase Three: Computation
|
||||
In order to eliminate the need for a step function (a conditional in
|
||||
@ -352,13 +354,13 @@ examining the relationship between the evidence accumulated for a
|
||||
proposal with the confidence encoded in the `alpha` parameter:
|
||||
|
||||
IF
|
||||
evidence \> alpha
|
||||
evidence > alpha
|
||||
THEN
|
||||
opinion \<-- YES
|
||||
opinion <-- YES
|
||||
ELSE IF
|
||||
evidence \< 1 - alpha
|
||||
evidence < 1 - alpha
|
||||
THEN
|
||||
opinion \<-- NO
|
||||
opinion <-- NO
|
||||
|
||||
If the opinion of the node is `NONE` after evaluating the relation
|
||||
between `evidence` and `alpha`, adjust the number of uniform randomly
|
||||
@ -369,9 +371,9 @@ up to the limit of `k_max_multiplier_power` query size increases.
|
||||
WHEN
|
||||
opinion is NONE
|
||||
AND
|
||||
k \< k_original * k_multiplier ^ max_k_multiplier_power
|
||||
k < k_original * k_multiplier ^ max_k_multiplier_power
|
||||
THEN
|
||||
k \<-- k * k_multiplier
|
||||
k <-- k * k_multiplier
|
||||
|
||||
### Decision
|
||||
The next step is a simple one: change our opinion if the threshold
|
||||
@ -384,9 +386,9 @@ directly related to the number of total votes received.
|
||||
Decision
|
||||
$$
|
||||
\begin{array}{cl}
|
||||
evidence \> \alpha & \implies \text{opinion YES} \newline
|
||||
evidence \< 1 - \alpha & \implies \text{opinion NO} \newline
|
||||
if\ \text{confidence} \> c_{target} & THEN \ \text{finalize decision} \newline
|
||||
evidence > \alpha & \implies \text{opinion YES} \newline
|
||||
evidence < 1 - \alpha & \implies \text{opinion NO} \newline
|
||||
if\ \text{confidence} > c_{target} & THEN \ \text{finalize decision} \newline
|
||||
\end{array}
|
||||
$$
|
||||
|
||||
@ -398,11 +400,11 @@ opinion is response to further queries from other nodes on the
|
||||
network.
|
||||
|
||||
IF
|
||||
confidence \> confidence_threshold
|
||||
confidence > confidence_threshold
|
||||
OR
|
||||
round \> max_rounds
|
||||
round > max_rounds
|
||||
THEN
|
||||
finalized \<-- T
|
||||
finalized <-- T
|
||||
QUERY LOOP TERMINATES
|
||||
ELSE
|
||||
round +== 1
|
||||
@ -474,11 +476,11 @@ the validity of the following statements expressed in Notation3 (aka
|
||||
|
||||
|
||||
```n3
|
||||
@prefix rdf: \<http://www.w3.org/1999/02/22-rdf-syntax-ns#\> .
|
||||
@prefix rdfs: \<http://www.w3.org/2000/01/rdf-schema#\> .
|
||||
@prefix xsd: \<http://www.w3.org/2001/XMLSchema#\> .
|
||||
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
||||
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
||||
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
|
||||
|
||||
@prefix Claro \<https://rdf.logos.co/protocol/Claro#\> .
|
||||
@prefix Claro <https://rdf.logos.co/protocol/Claro#> .
|
||||
|
||||
Claro:query
|
||||
:holds (
|
||||
@ -605,36 +607,36 @@ they should be of stable interest no matter if Claro isn't.
|
||||
|
||||
## Informative References
|
||||
|
||||
0. [Logos](\<https://logos.co/\>)
|
||||
0. [Logos](<https://logos.co/>)
|
||||
|
||||
1. [On BFT Consensus Evolution: From Monolithic to
|
||||
DAG](\<https://dahliamalkhi.github.io/posts/2022/06/dag-bft/\>)
|
||||
DAG](<https://dahliamalkhi.github.io/posts/2022/06/dag-bft/>)
|
||||
|
||||
2. [snow-ipfs](\<https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV\>)
|
||||
2. [snow-ipfs](<https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV>)
|
||||
|
||||
3. [snow*](\<https://www.avalabs.org/whitepapers\>) The Snow family of
|
||||
3. [snow*](<https://www.avalabs.org/whitepapers>) The Snow family of
|
||||
algorithms
|
||||
|
||||
4. [Move](\<https://cloud.google.com/composer/docs/how-to/using/writing-dags\>)
|
||||
4. [Move](<https://cloud.google.com/composer/docs/how-to/using/writing-dags>)
|
||||
Move: a Language for Writing DAG Abstractions
|
||||
|
||||
5. [rdf](\<http://www.w3.org/1999/02/22-rdf-syntax-ns#\>)
|
||||
5. [rdf](<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
|
||||
|
||||
6. [rdfs](\<http://www.w3.org/2000/01/rdf-schema#\>)
|
||||
6. [rdfs](<http://www.w3.org/2000/01/rdf-schema#>)
|
||||
|
||||
7. [xsd](\<http://www.w3.org/2001/XMLSchema#\>)
|
||||
7. [xsd](<http://www.w3.org/2001/XMLSchema#>)
|
||||
|
||||
8. [n3-w3c-notes](\<https://www.w3.org/TeamSubmission/n3/\>)
|
||||
8. [n3-w3c-notes](<https://www.w3.org/TeamSubmission/n3/>)
|
||||
|
||||
9. [ntp](\<https://www.ntp.org/downloads.html\>)
|
||||
9. [ntp](<https://www.ntp.org/downloads.html>)
|
||||
|
||||
## Normative References
|
||||
|
||||
0. [Claro](\<https://rdf.logos.co/protocol/Claro/1/0/0/raw\>)
|
||||
0. [Claro](<https://rdf.logos.co/protocol/Claro/1/0/0/raw>)
|
||||
|
||||
1. [n3](\<https://www.w3.org/DesignIssues/Notation3.html\>)
|
||||
1. [n3](<https://www.w3.org/DesignIssues/Notation3.html>)
|
||||
|
||||
2. [json-ld](\<https://json-ld.org/\>)
|
||||
2. [json-ld](<https://json-ld.org/>)
|
||||
|
||||
## Copyright
|
||||
|
||||
|
||||
@ -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 <szymon.s@ethworks.io>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Szymon Szlachtowicz \<szymon.s@ethworks.io\>
|
||||
- Editor: Szymon Szlachtowicz <szymon.s@ethworks.io>
|
||||
|
||||
## Abstract
|
||||
This specification is a voting protocol for peers to submit votes to a smart contract. Voting is immutable,
|
||||
|
||||
@ -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 <szymon.s@ethworks.io>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Szymon Szlachtowicz \<szymon.s@ethworks.io\>
|
||||
- Editor: Szymon Szlachtowicz <szymon.s@ethworks.io>
|
||||
|
||||
## Abstract
|
||||
This specification describes a voting method to feature different active Status Communities.
|
||||
|
||||
@ -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 <aaryamann@status.im>
|
||||
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 <andreap@status.im>
|
||||
- Pedro Pombeiro <pedro@status.im>
|
||||
- Corey Petty <corey@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- 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>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -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 <aaryamann@status.im>
|
||||
contributors:
|
||||
- Andrea Piana \<andreap@status.im\>
|
||||
- Andrea Piana <andreap@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- Contributors:
|
||||
- Andrea Piana <andreap@status.im>
|
||||
|
||||
|
||||
## 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]
|
||||
}
|
||||
|
||||
|
||||
@ -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 <r4bbit@status.im>
|
||||
contributors:
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- John Lea \<john@status.im\>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- John Lea <john@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: r4bbit \<r4bbit@status.im\>
|
||||
- Contributors::
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- John Lea \<john@status.im\>
|
||||
- Editor: r4bbit <r4bbit@status.im>
|
||||
- Contributors:
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- John Lea <john@status.im>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -188,7 +189,7 @@ message WakuMessageArchiveIndexMetadata {
|
||||
}
|
||||
|
||||
message WakuMessageArchiveIndex {
|
||||
map\<string, WakuMessageArchiveIndexMetadata\> archives = 1
|
||||
map<string, WakuMessageArchiveIndexMetadata> archives = 1
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@ -2,16 +2,20 @@
|
||||
title: 62/STATUS-Payloads
|
||||
name: Status Message Payloads
|
||||
status: draft
|
||||
editor: r4bbit \<r4bbit@status.im\>
|
||||
editor: r4bbit <r4bbit@status.im>
|
||||
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 <adam@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Oskar Thoren <oskarth@titanproxy.com>
|
||||
- Samuel Hawksby-Robinson <samuel@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: r4bbit \<r4bbit@status.im\>
|
||||
- Contributors::
|
||||
- Editor: r4bbit <r4bbit@status.im>
|
||||
- Contributors:
|
||||
- Adam Babik <adam@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Oskar Thoren <oskarth@titanproxy.com>
|
||||
- Samuel Hawksby-Robinson <samuel@status.im>
|
||||
|
||||
|
||||
## 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<string, IdentityImage> 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<string,CommunityMember> members = 2;
|
||||
CommunityPermissions permissions = 3;
|
||||
ChatIdentity identity = 5;
|
||||
map\<string,CommunityChat\> chats = 6;
|
||||
map<string,CommunityChat> chats = 6;
|
||||
repeated string ban_list = 7;
|
||||
map\<string,CommunityCategory\> categories = 8;
|
||||
map<string,CommunityCategory> 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<string, CommunityTokenPermission> 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<RevealedAccount>` | A list of revealed accounts |
|
||||
|
||||
## Upgradability
|
||||
|
||||
|
||||
@ -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 <aaryamann@status.im>
|
||||
contributors:
|
||||
- Jimmy Debe \<jimmy@status.im\>
|
||||
- Jimmy Debe <jimmy@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Jimmy Debe \<jimmy@status.im\>
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- Contributors:
|
||||
- Jimmy Debe <jimmy@status.im>
|
||||
|
||||
|
||||
## 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>
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@ -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 <aaryamann@status.im>
|
||||
contributors:
|
||||
- Corey Petty \<corey@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Samuel Hawksby-Robinson \<samuel@status.im\>
|
||||
- Corey Petty <corey@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Samuel Hawksby-Robinson <samuel@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- Contributors:
|
||||
- Corey Petty <corey@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Samuel Hawksby-Robinson <samuel@status.im>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -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 <jimmy@status.im>
|
||||
contributors:
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Jimmy Debe \<jimmy@status.im\>
|
||||
- Contributors::
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Editor: Jimmy Debe <jimmy@status.im>
|
||||
- Contributors:
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
|
||||
|
||||
## 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.
|
||||
> 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.
|
||||
|
||||
#### 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))
|
||||
> `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:<br />
|
||||
`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.<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 />
|
||||
`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.<br />
|
||||
`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.<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 />
|
||||
|
||||
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<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 />
|
||||
|
||||
#### 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<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 />
|
||||
|
||||
#### 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`.<br />
|
||||
`message_id`: the message id of the `PushNotificationQueryInfo` the server is replying to.<br />
|
||||
`success`: whether the query was successful.<br />
|
||||
|
||||
#### 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.<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 />
|
||||
`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<br />
|
||||
`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.<br />
|
||||
`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.<br />
|
||||
`error`: the type of the error in case of failure.<br />
|
||||
`public_key`: the public key of the user being notified.<br />
|
||||
`installation_id`: the `installation_id` of the user being notified.
|
||||
|
||||
### Anonymous Mode
|
||||
|
||||
@ -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 <danielkaiser@status.im>
|
||||
contributors:
|
||||
- Alvaro Revuelta \<alrevuelta@status.im\>
|
||||
- Alvaro Revuelta <alrevuelta@status.im>
|
||||
---
|
||||
- Status: raw
|
||||
- Category: Informational
|
||||
- Editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
- Contributors:
|
||||
- Alvaro Revuelta <alrevuelta@status.im>
|
||||
|
||||
|
||||
## 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
|
||||
> *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,
|
||||
> *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).
|
||||
> *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).
|
||||
> *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.
|
||||
> *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.
|
||||
> *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.
|
||||
> *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.
|
||||
> *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):
|
||||
> *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,
|
||||
> *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.
|
||||
|
||||
@ -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 <aaryamann@status.im>
|
||||
contributors:
|
||||
- Jimmy Debe \<jimmy@status.im\>
|
||||
- Jimmy Debe <jimmy@status.im>
|
||||
|
||||
---
|
||||
- Status: raw
|
||||
- Category: Best Current Practice
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- Contributors:
|
||||
- Jimmy Debe <jimmy@status.im>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -3,25 +3,26 @@ title: 1/COSS
|
||||
name: Consensus-Oriented Specification System
|
||||
status: draft
|
||||
category: Best Current Practice
|
||||
editor: Oskar Thoren \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thoren <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
- Pieter Hintjens \<ph@imatix.com\>
|
||||
- André Rebentisch \<andre@openstandards.de\>
|
||||
- Alberto Barrionuevo \<abarrio@opentia.es\>
|
||||
- Chris Puttick \<chris.puttick@thehumanjourney.net\>
|
||||
- Yurii Rashkovskii \<yrashk@gmail.com\>
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Pieter Hintjens <ph@imatix.com>
|
||||
- André Rebentisch <andre@openstandards.de>
|
||||
- Alberto Barrionuevo <abarrio@opentia.es>
|
||||
- Chris Puttick <chris.puttick@thehumanjourney.net>
|
||||
- Yurii Rashkovskii <yrashk@gmail.com>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Best Current Practice
|
||||
- Editor: Oskar Thoren \<oskarth@titanproxy.com\>
|
||||
- Contributors::
|
||||
- Pieter Hintjens \<ph@imatix.com\>
|
||||
- André Rebentisch \<andre@openstandards.de\>
|
||||
- Alberto Barrionuevo \<abarrio@opentia.es\>
|
||||
- Chris Puttick \<chris.puttick@thehumanjourney.net\>
|
||||
- Yurii Rashkovskii \<yrashk@gmail.com\>
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Editor: Oskar Thoren <oskarth@titanproxy.com>
|
||||
- Contributors:
|
||||
- Pieter Hintjens <ph@imatix.com>
|
||||
- André Rebentisch <andre@openstandards.de>
|
||||
- Alberto Barrionuevo <abarrio@opentia.es>
|
||||
- Chris Puttick <chris.puttick@thehumanjourney.net>
|
||||
- Yurii Rashkovskii <yrashk@gmail.com>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
|
||||
|
||||
This document describes a consensus-oriented specification system (COSS) for building interoperable technical specifications.
|
||||
COSS is based on a lightweight editorial process that seeks to engage the widest possible range of interested parties and move rapidly to consensus through working code.
|
||||
@ -100,7 +101,7 @@ Thus, we refer to a specification by specifying its domain, number, and short na
|
||||
New versions of the same specification will have new numbers.
|
||||
The syntax for a specification reference is:
|
||||
|
||||
\<domain\>/spec/\<number\>/\<shortname\>
|
||||
<domain>/spec/<number>/<shortname>
|
||||
|
||||
For example, this specification is **rfc.vac.dev/spec/1/COSS**.
|
||||
The short form **1/COSS** may be used when referring to the specification from other specifications in the same domain.
|
||||
@ -209,8 +210,8 @@ This will enable programmatic access to specification metadata.
|
||||
| **status** | status | string | draft |
|
||||
| **category** | category | string | Best Current Practice |
|
||||
| **tags** | 0 or several tags | list | waku-application, waku-core-protocol |
|
||||
| **editor** | editor name/email | string | Oskar Thoren \<oskarth@titanproxy.com\> |
|
||||
| **contributors** | contributors | list | - Pieter Hintjens \<ph@imatix.com\>\<br/\> - André Rebentisch \<andre@openstandards.de\>\<br/\> - Alberto Barrionuevo \<abarrio@opentia.es\>\<br/\> - Chris Puttick \<chris.puttick@thehumanjourney.net\>\<br/\> - Yurii Rashkovskii \<yrashk@gmail.com\> |
|
||||
| **editor** | editor name/email | string | Oskar Thoren <oskarth@titanproxy.com> |
|
||||
| **contributors** | contributors | list | - Pieter Hintjens <ph@imatix.com><br/> - André Rebentisch <andre@openstandards.de><br/> - Alberto Barrionuevo <abarrio@opentia.es><br/> - Chris Puttick <chris.puttick@thehumanjourney.net><br/> - Yurii Rashkovskii <yrashk@gmail.com> |
|
||||
|
||||
### Specification Template
|
||||
|
||||
|
||||
@ -2,16 +2,17 @@
|
||||
title: 2/MVDS
|
||||
name: Minimum Viable Data Synchronization
|
||||
status: stable
|
||||
editor: Sanaz Taheri \<sanaz@status.im\>
|
||||
editor: Sanaz Taheri <sanaz@status.im>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
- Status: stable
|
||||
- Editor: Sanaz Taheri \<sanaz@status.im\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Sanaz Taheri <sanaz@status.im>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
|
||||
In this specification, we describe a minimum viable protocol for data synchronization inspired by the Bramble Synchronization Protocol[^1]. This protocol is designed to ensure reliable messaging between peers across an unreliable peer-to-peer (P2P) network where they may be unreachable or unresponsive.
|
||||
|
||||
@ -89,7 +90,7 @@ A maximum of one payload SHOULD be sent to peers per epoch, this payload contain
|
||||
|
||||
Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACTIVE` mode. The following rules dictate how nodes construct payloads every epoch for any given peer for both modes.
|
||||
|
||||
\> ***NOTE:** A node may send messages both in interactive and in batch mode.*
|
||||
> ***NOTE:** A node may send messages both in interactive and in batch mode.*
|
||||
|
||||
#### Interactive Mode
|
||||
|
||||
@ -100,11 +101,11 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
|
||||
- When a node receives an `ACK`, the `MESSAGE` is removed from the state for the given peer.
|
||||
- All records that require retransmission are added to the payload, given `Send Epoch` has been reached.
|
||||
|
||||
\<p align="center"\>
|
||||
\<img src="../assets/mvds/interactive.png" /\>
|
||||
\<br /\>
|
||||
<p align="center">
|
||||
<img src="../assets/mvds/interactive.png" />
|
||||
<br />
|
||||
Figure 1: Delivery without retransmissions in interactive mode.
|
||||
\</p\>
|
||||
</p>
|
||||
|
||||
#### Batch Mode
|
||||
|
||||
@ -117,14 +118,14 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
|
||||
<!-- diagram -->
|
||||
|
||||
|
||||
\<p align="center"\>
|
||||
\<img src="../assets/mvds/batch.png" /\>
|
||||
\<br /\>
|
||||
<p align="center">
|
||||
<img src="../assets/mvds/batch.png" />
|
||||
<br />
|
||||
Figure 2: Delivery without retransmissions in batch mode.
|
||||
\</p\>
|
||||
</p>
|
||||
|
||||
|
||||
\> ***NOTE:** Batch mode is higher bandwidth whereas interactive mode is higher latency.*
|
||||
> ***NOTE:** Batch mode is higher bandwidth whereas interactive mode is higher latency.*
|
||||
|
||||
|
||||
<!-- Interactions with state, flow chart with retransmissions? -->
|
||||
@ -136,11 +137,11 @@ The record of the type `Type` SHOULD be retransmitted every time `Send Epoch` is
|
||||
|
||||
`Send Epoch` and `Send Count` MUST be increased every time a record is retransmitted. Although no function is defined on how to increase `Send Epoch`, it SHOULD be exponentially increased until reaching an upper bound where it then goes back to a lower epoch in order to prevent a record's `Send Epoch`'s from becoming too large.
|
||||
|
||||
\> ***NOTE:** We do not retransmission `ACK`s as we do not know when they have arrived, therefore we simply resend them every time we receive a `MESSAGE`.*
|
||||
> ***NOTE:** We do not retransmission `ACK`s as we do not know when they have arrived, therefore we simply resend them every time we receive a `MESSAGE`.*
|
||||
|
||||
## Formal Specification
|
||||
|
||||
MVDS has been formally specified using TLA+: \<https://github.com/vacp2p/formalities/tree/master/MVDS\>.
|
||||
MVDS has been formally specified using TLA+: <https://github.com/vacp2p/formalities/tree/master/MVDS>.
|
||||
|
||||
## Acknowledgments
|
||||
- Preston van Loon
|
||||
@ -155,4 +156,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
|
||||
## Footnotes
|
||||
|
||||
[^1]: akwizgran et al. [BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP). Briar.
|
||||
[^2]: \<https://github.com/vacp2p/mvds\>
|
||||
[^2]: <https://github.com/vacp2p/mvds>
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 25/LIBP2P-DNS-DISCOVERY
|
||||
name: Libp2p Peer Discovery via DNS
|
||||
status: deleted
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: deleted
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
|
||||
`25/LIBP2P-DNS-DISCOVERY` specifies a scheme to implement [`libp2p`](https://libp2p.io/) peer discovery via DNS for Waku v2.
|
||||
The generalised purpose is to retrieve an arbitrarily long, authenticated, updateable list of [`libp2p` peers](https://docs.libp2p.io/concepts/peer-id/) to bootstrap connection to a `libp2p` network.
|
||||
@ -24,13 +24,13 @@ EIP-1459 specifies [the URL scheme](https://eips.ethereum.org/EIPS/eip-1459#spec
|
||||
This specification uses the same approach, but with a `matree` scheme:
|
||||
|
||||
```
|
||||
matree://\<key\>@\<fqdn\>
|
||||
matree://<key>@<fqdn>
|
||||
```
|
||||
|
||||
where
|
||||
- `matree` is the selected `multiaddr` Merkle tree scheme
|
||||
- `\<fqdn\>` is the fully qualified domain name on which the list can be found
|
||||
- `\<key\>` is the base32 encoding of the compressed 32-byte binary public key that signed the list.
|
||||
- `<fqdn>` is the fully qualified domain name on which the list can be found
|
||||
- `<key>` is the base32 encoding of the compressed 32-byte binary public key that signed the list.
|
||||
|
||||
The example URL from EIP-1459, adapted to the above scheme becomes:
|
||||
|
||||
@ -55,7 +55,7 @@ and adapted for use with `multiaddrs`:
|
||||
The tree root entry MUST use the following format:
|
||||
|
||||
```
|
||||
matree-root:v1 m=\<ma-root\> l=\<link-root\> seq=\<sequence number\> sig=\<signature\>
|
||||
matree-root:v1 m=<ma-root> l=<link-root> seq=<sequence number> sig=<signature>
|
||||
```
|
||||
|
||||
where
|
||||
@ -73,11 +73,11 @@ encoded as URL-safe base64
|
||||
Branch entries MUST take the format:
|
||||
|
||||
```
|
||||
matree-branch:\<h₁\>,\<h₂\>,...,\<hₙ\>
|
||||
matree-branch:<h₁>,<h₂>,...,<hₙ>
|
||||
```
|
||||
|
||||
where
|
||||
- `\<h₁\>,\<h₂\>,...,\<hₙ\>` are the hashes of other subtree entries
|
||||
- `<h₁>,<h₂>,...,<hₙ>` are the hashes of other subtree entries
|
||||
|
||||
## Leaf entries
|
||||
|
||||
@ -89,7 +89,7 @@ For the subtree pointed to by `link-root`,
|
||||
leaf entries MUST take the format:
|
||||
|
||||
```
|
||||
matree://\<key\>@\<fqdn\>
|
||||
matree://<key>@<fqdn>
|
||||
```
|
||||
|
||||
which links to a different list located in another domain.
|
||||
@ -100,7 +100,7 @@ For the subtree pointed to by `ma-root`,
|
||||
leaf entries MUST take the format:
|
||||
|
||||
```
|
||||
ma:\<multiaddr\>
|
||||
ma:<multiaddr>
|
||||
```
|
||||
|
||||
which contains the `multiaddr` of a `libp2p` peer.
|
||||
|
||||
@ -2,14 +2,15 @@
|
||||
title: 3/REMOTE-LOG
|
||||
name: Remote log specification
|
||||
status: draft
|
||||
editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
|
||||
|
||||
A remote log is a replication of a local log. This means a node can read data that originally came from a node that is offline.
|
||||
|
||||
@ -126,7 +127,7 @@ message RemoteLog {
|
||||
|
||||
|
||||
|
||||
<!-- TODO: Consider making more useful in conjunction with metadata field. It makes sense to explicitly list what sequence a message is \<local hash, remote hash, data, seqid\> this way I can easily sync a messages prior or after a specific number. To enable this to be dynamic it might make sense to add page info so that I am aware which page I can find seqid on -->
|
||||
<!-- TODO: Consider making more useful in conjunction with metadata field. It makes sense to explicitly list what sequence a message is <local hash, remote hash, data, seqid> this way I can easily sync a messages prior or after a specific number. To enable this to be dynamic it might make sense to add page info so that I am aware which page I can find seqid on -->
|
||||
|
||||
|
||||
## Synchronization
|
||||
@ -157,11 +158,11 @@ The *remote log* protobuf is what is stored in the name system.
|
||||
<!-- diagram -->
|
||||
|
||||
|
||||
\<p align="center"\>
|
||||
\<img src="./images/remote-log.png" /\>
|
||||
\<br /\>
|
||||
<p align="center">
|
||||
<img src="./images/remote-log.png" />
|
||||
<br />
|
||||
Figure 1: Remote log data synchronization.
|
||||
\</p\>
|
||||
</p>
|
||||
|
||||
|
||||
<!-- Document the flow wrt operations -->
|
||||
@ -243,4 +244,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
|
||||
|
||||
## Footnotes
|
||||
|
||||
[^1]: \<https://github.com/vacp2p/research/tree/master/remote_log\>
|
||||
[^1]: <https://github.com/vacp2p/research/tree/master/remote_log>
|
||||
|
||||
@ -2,17 +2,22 @@
|
||||
title: 32/RLN-V1
|
||||
name: Rate Limit Nullifier
|
||||
status: raw
|
||||
editor: Rasul Ibragimov \<curryrasul@gmail.com\>
|
||||
editor: Rasul Ibragimov <curryrasul@gmail.com>
|
||||
contributors:
|
||||
- Barry Whitehat \<barrywhitehat@protonmail.com\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Onur Kilic \<onurkilic1004@gmail.com\>
|
||||
- Blagoj Dimovski \<blagoj.dimovski@yandex.com\>
|
||||
- Barry Whitehat <barrywhitehat@protonmail.com>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Onur Kilic <onurkilic1004@gmail.com>
|
||||
- Blagoj Dimovski <blagoj.dimovski@yandex.com>
|
||||
---
|
||||
- Status: raw
|
||||
- Editor: Rasul Ibragimov \<curryrasul@gmail.com\>
|
||||
- Contributors::
|
||||
- Editor: Rasul Ibragimov <curryrasul@gmail.com>
|
||||
- Contributors:
|
||||
- Barry Whitehat <barrywhitehat@protonmail.com>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Onur Kilic <onurkilic1004@gmail.com>
|
||||
- Blagoj Dimovski <blagoj.dimovski@yandex.com>
|
||||
|
||||
|
||||
## Abstract
|
||||
@ -578,7 +583,7 @@ let mut rln = RLN::new(tree_height, resources);
|
||||
|
||||
```rust
|
||||
// We generate an identity tuple
|
||||
let mut buffer = Cursor::new(Vec::\<u8\>::new());
|
||||
let mut buffer = Cursor::new(Vec::<u8>::new());
|
||||
rln.extended_key_gen(&mut buffer).unwrap();
|
||||
// We deserialize the keygen output to obtain
|
||||
// the identiy_secret and id_commitment
|
||||
@ -612,7 +617,7 @@ let signal = b"RLN is awesome";
|
||||
let proof_input = prepare_prove_input(identity_secret, id_index, epoch, signal);
|
||||
// We generate a RLN proof for proof_input
|
||||
let mut in_buffer = Cursor::new(proof_input);
|
||||
let mut out_buffer = Cursor::new(Vec::\<u8\>::new());
|
||||
let mut out_buffer = Cursor::new(Vec::<u8>::new());
|
||||
rln.generate_rln_proof(&mut in_buffer, &mut out_buffer)
|
||||
.unwrap();
|
||||
// We get the public outputs returned by the circuit evaluation
|
||||
|
||||
@ -2,18 +2,19 @@
|
||||
title: 4/MVDS-META
|
||||
name: MVDS Metadata Field
|
||||
status: draft
|
||||
editor: Sanaz Taheri \<sanaz@status.im\>
|
||||
editor: Sanaz Taheri <sanaz@status.im>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Sanaz Taheri \<sanaz@status.im\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Sanaz Taheri <sanaz@status.im>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
|
||||
In this specification, we describe a method to construct message history that will aid the consistency guarantees of [2/MVDS](../2/mvds). Additionally, we explain how data sync can be used for more lightweight messages that do not require full synchronization.
|
||||
|
||||
@ -80,6 +81,6 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
|
||||
|
||||
## Footnotes
|
||||
[^1]: [2/MVDS](../2/mvds)
|
||||
[^2]: \<https://en.wikipedia.org/wiki/Directed_acyclic_graph\>
|
||||
[^2]: <https://en.wikipedia.org/wiki/Directed_acyclic_graph>
|
||||
[^3]: Jepsen. [Causal Consistency](https://jepsen.io/consistency/models/causal). Jepsen, LLC.
|
||||
[^4]: \<https://en.wikipedia.org/wiki/Eventual_consistency\>
|
||||
[^4]: <https://en.wikipedia.org/wiki/Eventual_consistency>
|
||||
|
||||
@ -3,12 +3,12 @@ title: 46/GOSSIPSUB-TOR-PUSH
|
||||
name: Gossipsub Tor Push
|
||||
status: raw
|
||||
category: Standards Track
|
||||
editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||||
editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: raw
|
||||
- Category: Standards Track
|
||||
- Editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
@ -3,12 +3,12 @@ title: 48/RLN-INTEREP-SPEC
|
||||
name: Interep as group management for RLN
|
||||
status: raw
|
||||
category:
|
||||
editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
editor: Aaryamann Challani <aaryamann@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: raw
|
||||
- Category:
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
@ -2,13 +2,14 @@
|
||||
title: 58/RLN-V2
|
||||
name: Rate Limit Nullifier V2
|
||||
status: raw
|
||||
editor: Rasul Ibragimov \<curryrasul@gmail.com\>
|
||||
editor: Rasul Ibragimov <curryrasul@gmail.com>
|
||||
contributors:
|
||||
- Lev Soukhanov \<0xdeadfae@gmail.com\>
|
||||
- Lev Soukhanov <0xdeadfae@gmail.com>
|
||||
---
|
||||
- Status: raw
|
||||
- Editor: Rasul Ibragimov \<curryrasul@gmail.com\>
|
||||
- Contributors::
|
||||
- Editor: Rasul Ibragimov <curryrasul@gmail.com>
|
||||
- Contributors:
|
||||
- Lev Soukhanov <0xdeadfae@gmail.com>
|
||||
|
||||
|
||||
## Abstract
|
||||
@ -93,7 +94,7 @@ internal_nullifier = poseidonHash([a_1])
|
||||
|
||||
**id_commitment** in [32/RLN-V1](../32/rln-v1) is equal to `poseidonHash(identity_secret)`.
|
||||
The goal of RLN-Diff is to set different rate-limits for different users.
|
||||
It follows that **id_commitment** must somehow depend on the `user_message_limit` parameter, where 0 \<= `user_message_limit` \<= `message_limit`.
|
||||
It follows that **id_commitment** must somehow depend on the `user_message_limit` parameter, where 0 <= `user_message_limit` <= `message_limit`.
|
||||
There are few ways to do that:
|
||||
1. Sending `identity_secret_hash` = `poseidonHash(identity_secret, userMessageLimit)` and zk proof that `user_message_limit` is valid (is in the right range).
|
||||
This approach requires zkSNARK verification, which is an expensive operation on the blockchain.
|
||||
|
||||
@ -3,12 +3,12 @@ title: 70/ETH-SECPM
|
||||
name: Secure channel setup using Ethereum accounts
|
||||
status: raw
|
||||
category: Standards Track
|
||||
editor: Ramses Fernandez \<ramses@status.im\>
|
||||
editor: Ramses Fernandez <ramses@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: raw
|
||||
- Category: Standards Track
|
||||
- Editor: Ramses Fernandez \<ramses@status.im\>
|
||||
- Editor: Ramses Fernandez <ramses@status.im>
|
||||
|
||||
## Motivation
|
||||
The need for secure communications has become paramount.
|
||||
@ -100,7 +100,7 @@ XEd448_sign((ik, IK), message):
|
||||
```
|
||||
```
|
||||
XEd448_verify(u, message, (R || s)):
|
||||
if (R.y \>= 2^448) or (s \>= 2^446): return FALSE
|
||||
if (R.y >= 2^448) or (s >= 2^446): return FALSE
|
||||
h = (SHA512(R || 156326 || message)) % q
|
||||
R_check = s * convert_mont(5) - h * 156326
|
||||
if R == R_check: return TRUE
|
||||
@ -215,10 +215,10 @@ DHRatchet(state, header):
|
||||
```
|
||||
```
|
||||
SkipMessageKeys(state, until):
|
||||
if state.NR + MAX_SKIP \< until:
|
||||
if state.NR + MAX_SKIP < until:
|
||||
raise Error
|
||||
if state.CKr != none:
|
||||
while state.Nr \< until:
|
||||
while state.Nr < until:
|
||||
state.CKr, mk = HMAC-SHA256(state.CKr)
|
||||
state.MKSKIPPED[state.DHr, state.Nr] = mk
|
||||
state.Nr = state.Nr + 1
|
||||
@ -362,8 +362,8 @@ DeriveSecret(Secret, Label) = ExpandWithLabel(Secret, Label, "", KDF.Nh)
|
||||
```
|
||||
struct {
|
||||
uint16 length;
|
||||
opaque label\<V\>;
|
||||
opaque context\<V\>;
|
||||
opaque label<V>;
|
||||
opaque context<V>;
|
||||
} KDFLabel;
|
||||
```
|
||||
The fields of `KDFLabel` MUST be:
|
||||
@ -380,11 +380,11 @@ The sturcture of such object MUST be:
|
||||
struct {
|
||||
ProtocolVersion version = mls10;
|
||||
CipherSuite cipher_suite;
|
||||
opaque group_id\<V\>;
|
||||
opaque group_id<V>;
|
||||
uint64 epoch;
|
||||
opaque tree_hash\<V\>;
|
||||
opaque confirmed_trasncript_hash\<V\>;
|
||||
Extension extension\<V\>;
|
||||
opaque tree_hash<V>;
|
||||
opaque confirmed_trasncript_hash<V>;
|
||||
Extension extension<V>;
|
||||
} GroupContext;
|
||||
```
|
||||
|
||||
@ -435,9 +435,9 @@ ProtocolVersion version;
|
||||
CipherSuite cipher_suite;
|
||||
HPKEPublicKey init_key;
|
||||
LeafNode leaf_node;
|
||||
Extension extensions\<V\>;
|
||||
Extension extensions<V>;
|
||||
/* SignWithLabel(., "KeyPackageTBS", KeyPackageTBS) */
|
||||
opaque signature\<V\>;
|
||||
opaque signature<V>;
|
||||
}
|
||||
```
|
||||
```
|
||||
@ -446,7 +446,7 @@ ProtocolVersion version;
|
||||
CipheSuite cipher_suite;
|
||||
HPKEPublicKey init_key;
|
||||
LeafNode leaf_node;
|
||||
Extension extensions\<V\>;
|
||||
Extension extensions<V>;
|
||||
}
|
||||
```
|
||||
`KeyPackage` object MUST be verified when:
|
||||
@ -495,9 +495,9 @@ All members of a group MUST support the cipher suite and protocol version in use
|
||||
|
||||
```
|
||||
struct {
|
||||
ExtensionType extension_types\<V\>;
|
||||
ProposalType proposal_types\<V\>;
|
||||
CredentialType credential_types\<V\>;
|
||||
ExtensionType extension_types<V>;
|
||||
ProposalType proposal_types<V>;
|
||||
CredentialType credential_types<V>;
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@ -2,13 +2,14 @@
|
||||
title: RLN-STEALTH-COMMITMENTS
|
||||
name: RLN Stealth Commitment Usage
|
||||
category: Standards Track
|
||||
editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
editor: Aaryamann Challani <aaryamann@status.im>
|
||||
contributors:
|
||||
- Jimmy Debe \<jimmy@status.im\>
|
||||
- Jimmy Debe <jimmy@status.im>
|
||||
---
|
||||
- Category: Standards Track
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- Contributors:
|
||||
- Jimmy Debe <jimmy@status.im>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -3,12 +3,12 @@ title: XX/(WAKU2|LOGOS|CODEX|*)-TEMPLATE
|
||||
name: (Waku v2 | Logos | Codex) RFC Template
|
||||
status: (raw|draft|stable)
|
||||
category: (Standards Track|Informational|Best Current Practice)
|
||||
editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||||
editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: (raw|draft|stable)
|
||||
- Category: (Standards Track|Informational|Best Current Practice)
|
||||
- Editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
|
||||
# (Info, remove this section)
|
||||
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
title: 16/WAKU2-RPC
|
||||
name: Waku v2 RPC API
|
||||
status: deprecated
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
---
|
||||
- Status: deprecated
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
|
||||
## Introduction
|
||||
|
||||
@ -57,13 +57,13 @@ Refer to [`Waku Message` specification](../14/message) for more information.
|
||||
|
||||
## Method naming
|
||||
|
||||
The JSON-RPC methods in this document are designed to be mappable to HTTP REST endpoints. Method names follow the pattern `\<method_type\>_waku_\<protocol_version\>_\<api\>_\<api_version\>_\<resource\>`
|
||||
The JSON-RPC methods in this document are designed to be mappable to HTTP REST endpoints. Method names follow the pattern `<method_type>_waku_<protocol_version>_<api>_<api_version>_<resource>`
|
||||
|
||||
- `\<method_type\>`: prefix of the HTTP method type that most closely matches the JSON-RPC function. Supported `method_type` values are `get`, `post`, `put`, `delete` or `patch`.
|
||||
- `\<protocol_version\>`: Waku version. Currently **v2**.
|
||||
- `\<api\>`: one of the listed APIs below, e.g. `store`, `debug`, or `relay`.
|
||||
- `\<api_version\>`: API definition version. Currently **v1** for all APIs.
|
||||
- `\<resource\>`: the resource or resource path being addressed
|
||||
- `<method_type>`: prefix of the HTTP method type that most closely matches the JSON-RPC function. Supported `method_type` values are `get`, `post`, `put`, `delete` or `patch`.
|
||||
- `<protocol_version>`: Waku version. Currently **v2**.
|
||||
- `<api>`: one of the listed APIs below, e.g. `store`, `debug`, or `relay`.
|
||||
- `<api_version>`: API definition version. Currently **v1** for all APIs.
|
||||
- `<resource>`: the resource or resource path being addressed
|
||||
|
||||
The method `post_waku_v2_relay_v1_message`, for example, would map to the HTTP REST endpoint `POST /waku/v2/relay/v1/message`.
|
||||
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 18/WAKU2-SWAP
|
||||
name: Waku SWAP Accounting
|
||||
status: deprecated
|
||||
editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
contributor: Ebube Ud \<ebube@status.im\>
|
||||
editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
contributor: Ebube Ud <ebube@status.im>
|
||||
---
|
||||
- Status: deprecated
|
||||
- Editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -24,7 +24,7 @@ Theoretically, nodes providing and using resources over a long, indefinite, peri
|
||||
|
||||
## Game Theory - Iterated prisoner's dilemma / donation game
|
||||
|
||||
What follows is a sketch of what the game looks like between two nodes. We can look at it as a special case of iterated prisoner's dilemma called a [Donation game](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Special_case:_donation_game) where each node can cooperate with some benefit `b` at a personal cost `c`, where `b\>c`.
|
||||
What follows is a sketch of what the game looks like between two nodes. We can look at it as a special case of iterated prisoner's dilemma called a [Donation game](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Special_case:_donation_game) where each node can cooperate with some benefit `b` at a personal cost `c`, where `b>c`.
|
||||
|
||||
From A's point of view:
|
||||
|
||||
@ -46,10 +46,10 @@ With R=reward, S=Sucker's payoff, T=temptation, P=punishment
|
||||
|
||||
And the following holds:
|
||||
|
||||
- `T\>R\>P\>S`
|
||||
- `2R\>T+S`
|
||||
- `T>R>P>S`
|
||||
- `2R>T+S`
|
||||
|
||||
In our case, this means `b\>b-c\>0\>-c` and `2(b-c)\> b-c` which is trivially true.
|
||||
In our case, this means `b>b-c>0>-c` and `2(b-c)> b-c` which is trivially true.
|
||||
|
||||
As this is an iterated game with no clear finishing point in most circumstances, a tit-for-tat strategy is simple, elegant and functional. To be more theoretically precise, this also requires reasonable assumptions on error rate and discount parameter. This captures notions such as "does the perceived action reflect the intended action" and "how much do you value future (uncertain) actions compared to previous actions". See [Axelrod - Evolution of Cooperation (book)](https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation) for more details. In specific circumstances, nodes can choose slightly different policies if there's a strong need for it. A policy is simply how a node chooses to act given a set of circumstances.
|
||||
|
||||
|
||||
@ -2,20 +2,21 @@
|
||||
title: 5/WAKU0
|
||||
name: Waku v0
|
||||
status: deprecated
|
||||
editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
- Adam Babik \<adam@status.im\>
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Kim De Mey \<kimdemey@status.im\>
|
||||
- Adam Babik <adam@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Kim De Mey <kimdemey@status.im>
|
||||
---
|
||||
- Status: deprecated
|
||||
- Editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Contributors::
|
||||
- Adam Babik \<adam@status.im\>
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Kim De Mey \<kimdemey@status.im\>
|
||||
- Editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Contributors:
|
||||
- Adam Babik <adam@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Kim De Mey <kimdemey@status.im>
|
||||
|
||||
|
||||
This specification describes the format of Waku messages within the ÐΞVp2p Wire Protocol. This spec substitutes [EIP-627](https://eips.ethereum.org/EIPS/eip-627). Waku is a fork of the original Whisper protocol that enables better usability for resource restricted devices, such as mostly-offline bandwidth-constrained smartphones. It does this through (a) light node support, (b) historic messages (with a mailserver) (c) expressing topic interest for better bandwidth usage and (d) basic rate limiting.
|
||||
|
||||
@ -396,7 +397,7 @@ Waku is a different subprotocol from Whisper so it isn't directly compatible. Ho
|
||||
2. C picks up message from A and B and relays them both to Waku and Whisper.
|
||||
3. A receives message on Waku; B on Whisper.
|
||||
|
||||
**Note**: This flow means if another bridge C1 is active, we might get duplicate relaying for a message between C1 and C2. I.e. Whisper(\<\>Waku\<\>Whisper)\<\>Waku, A-C1-C2-B. Theoretically this bridging chain can get as long as TTL permits.
|
||||
**Note**: This flow means if another bridge C1 is active, we might get duplicate relaying for a message between C1 and C2. I.e. Whisper(<>Waku<>Whisper)<>Waku, A-C1-C2-B. Theoretically this bridging chain can get as long as TTL permits.
|
||||
|
||||
### Forward Compatibility
|
||||
|
||||
|
||||
@ -2,13 +2,14 @@
|
||||
title: 22/TOY-CHAT
|
||||
name: Waku v2 Toy Chat
|
||||
status: draft
|
||||
editor: Franck Royer \<franck@status.im\>
|
||||
editor: Franck Royer <franck@status.im>
|
||||
contributors:
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Franck Royer \<franck@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Franck Royer <franck@status.im>
|
||||
- Contributors:
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
|
||||
|
||||
**Content Topic**: `/toy-chat/2/huilong/proto`.
|
||||
|
||||
@ -3,17 +3,18 @@ title: 23/WAKU2-TOPICS
|
||||
name: Waku v2 Topic Usage Recommendations
|
||||
status: draft
|
||||
category: Informational
|
||||
editor: Oskar Thoren \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thoren <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Informational
|
||||
- Editor: Oskar Thoren \<oskarth@titanproxy.com\>
|
||||
- Contributors::
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Editor: Oskar Thoren <oskarth@titanproxy.com>
|
||||
- Contributors:
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
|
||||
|
||||
This document outlines recommended usage of topic names in Waku v2.
|
||||
In [10/WAKU2 spec](../../standards/core/10/waku2) there are two types of topics:
|
||||
@ -43,7 +44,7 @@ The first two parts indicate
|
||||
|
||||
If applicable, it is RECOMMENDED to structure `{topic-name}` in a hierarchical way as well.
|
||||
|
||||
\> *Note*: In previous versions of this document, the structure was `/waku/2/{topic-name}/{encoding}`.
|
||||
> *Note*: In previous versions of this document, the structure was `/waku/2/{topic-name}/{encoding}`.
|
||||
The now deprecated `/{encoding}` was always set to `/proto`,
|
||||
which indicated that the [data field](../../standards/core/11/RELAY#protobuf-definition) in pubsub is serialized/encoded as protobuf.
|
||||
The inspiration for this format was taken from
|
||||
@ -141,10 +142,10 @@ For mapping Waku v1 topics to Waku v2 content topics,
|
||||
the following structure for the content topic SHOULD be used:
|
||||
|
||||
```
|
||||
/waku/1/\<4bytes-waku-v1-topic\>/rfc26
|
||||
/waku/1/<4bytes-waku-v1-topic>/rfc26
|
||||
```
|
||||
|
||||
The `\<4bytes-waku-v1-topic\>` SHOULD be the lowercase hex representation of the 4-byte Waku v1 topic.
|
||||
The `<4bytes-waku-v1-topic>` SHOULD be the lowercase hex representation of the 4-byte Waku v1 topic.
|
||||
A `0x` prefix SHOULD be used.
|
||||
`/rfc26` indicates that the bridged content is encoded according to RFC [26/WAKU2-PAYLOAD](../../standards/application/26/payload).
|
||||
See [15/WAKU-BRIDGE](../../standards/core/15/bridge) for a description of the bridged fields.
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 27/WAKU2-PEERS
|
||||
name: Waku v2 Client Peer Management Recommendations
|
||||
status: draft
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
|
||||
`27/WAKU2-PEERS` describes a recommended minimal set of peer storage and peer management features to be implemented by Waku v2 clients.
|
||||
|
||||
@ -79,7 +79,7 @@ it SHOULD do so by sending periodic [libp2p pings](https://docs.libp2p.io/concep
|
||||
The recommended period between pings SHOULD be _at most_ 50% of the shortest idle connection timeout for the specific client and transport.
|
||||
For example, idle TCP connections often times out after 10 to 15 minutes.
|
||||
|
||||
\> **Implementation note:** the `nim-waku` client currently implements a keep-alive mechanism every `5 minutes`,
|
||||
> **Implementation note:** the `nim-waku` client currently implements a keep-alive mechanism every `5 minutes`,
|
||||
in response to a TCP connection timeout of `10 minutes`.
|
||||
|
||||
## Copyright
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 29/WAKU2-CONFIG
|
||||
name: Waku v2 Client Parameter Configuration Recommendations
|
||||
status: draft
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
|
||||
`29/WAKU2-CONFIG` describes the RECOMMENDED values to assign to configurable parameters for Waku v2 clients.
|
||||
Since Waku v2 is built on [libp2p](https://github.com/libp2p/specs),
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 30/ADAPTIVE-NODES
|
||||
name: Adaptive nodes
|
||||
status: draft
|
||||
editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
This is an informational spec that show cases the concept of adaptive nodes.
|
||||
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 20/TOY-ETH-PM
|
||||
name: Toy Ethereum Private Message
|
||||
status: draft
|
||||
editor: Franck Royer \<franck@status.im\>
|
||||
editor: Franck Royer <franck@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Franck Royer \<franck@status.im\>
|
||||
- Editor: Franck Royer <franck@status.im>
|
||||
|
||||
**Content Topics**:
|
||||
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 21/WAKU2-FAULT-TOLERANT-STORE
|
||||
name: Waku v2 Fault-Tolerant Store
|
||||
status: draft
|
||||
editor: Sanaz Taheri \<sanaz@status.im\>
|
||||
editor: Sanaz Taheri <sanaz@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Sanaz Taheri \<sanaz@status.im\>
|
||||
- Editor: Sanaz Taheri <sanaz@status.im>
|
||||
|
||||
The reliability of [13/WAKU2-STORE](../../core/13/store) protocol heavily relies on the fact that full nodes i.e., those who persist messages have high availability and uptime and do not miss any messages.
|
||||
If a node goes offline, then it will risk missing all the messages transmitted in the network during that time.
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 26/WAKU2-PAYLOAD
|
||||
name: Waku Message Payload Encryption
|
||||
status: draft
|
||||
editor: Oskar Thoren \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thoren <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Oskar Thoren \<oskarth@titanproxy.com\>
|
||||
- Editor: Oskar Thoren <oskarth@titanproxy.com>
|
||||
|
||||
This specification describes how Waku provides confidentiality, authenticity, and integrity, as well as some form of unlinkability.
|
||||
Specifically, it describes how encryption, decryption and signing works in [6/WAKU1](../../legacy/6/waku1) and in [10/WAKU2 spec](../../core/10/waku2) with [14/WAKU-MESSAGE version 1](../../core/14/message#version1).
|
||||
|
||||
@ -3,18 +3,23 @@ title: 53/WAKU2-X3DH
|
||||
name: X3DH usage for Waku payload encryption
|
||||
status: draft
|
||||
category: Standards Track
|
||||
editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
editor: Aaryamann Challani <aaryamann@status.im>
|
||||
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 <andreap@status.im>
|
||||
- Pedro Pombeiro <pedro@status.im>
|
||||
- Corey Petty <corey@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- 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>
|
||||
|
||||
|
||||
## Abstract
|
||||
@ -130,7 +135,7 @@ message Bundle {
|
||||
// Identity key 'IK_B'
|
||||
bytes identity = 1;
|
||||
// Signed prekey 'SPK_B' for each device, indexed by 'installation-id'
|
||||
map\<string,SignedPreKey\> signed_pre_keys = 2;
|
||||
map<string,SignedPreKey> signed_pre_keys = 2;
|
||||
// Prekey signature 'Sig(IK_B, Encode(SPK_B))'
|
||||
bytes signature = 4;
|
||||
// When the bundle was created locally
|
||||
@ -166,7 +171,7 @@ message ProtocolMessage {
|
||||
// A sequence of bundles
|
||||
repeated Bundle bundles = 3;
|
||||
// One to one message, encrypted, indexed by installation_id
|
||||
map\<string,DirectMessageProtocol\> direct_message = 101;
|
||||
map<string,DirectMessageProtocol> direct_message = 101;
|
||||
// Public message, not encrypted
|
||||
bytes public_message = 102;
|
||||
}
|
||||
|
||||
@ -3,18 +3,23 @@ title: 54/WAKU2-X3DH-SESSIONS
|
||||
name: Session management for Waku X3DH
|
||||
status: draft
|
||||
category: Standards Track
|
||||
editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
editor: Aaryamann Challani <aaryamann@status.im>
|
||||
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 <andreap@status.im>
|
||||
- Pedro Pombeiro <pedro@status.im>
|
||||
- Corey Petty <corey@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Aaryamann Challani <aaryamann@status.im>
|
||||
- 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>
|
||||
|
||||
|
||||
## Abstract
|
||||
@ -51,12 +56,12 @@ partitionTopic := "contact-discovery-" + strconv.FormatInt(partition.Int64(), 10
|
||||
var hash []byte = keccak256(partitionTopic)
|
||||
var topicLen int = 4
|
||||
|
||||
if len(hash) \< topicLen {
|
||||
if len(hash) < topicLen {
|
||||
topicLen = len(hash)
|
||||
}
|
||||
|
||||
var contactCodeTopic [4]byte
|
||||
for i = 0; i \< topicLen; i++ {
|
||||
for i = 0; i < topicLen; i++ {
|
||||
contactCodeTopic[i] = hash[i]
|
||||
}
|
||||
```
|
||||
@ -83,12 +88,12 @@ hexEncodedKey := hex.EncodeToString(sharedKey)
|
||||
var hash []byte = keccak256(hexEncodedKey)
|
||||
var topicLen int = 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]
|
||||
}
|
||||
```
|
||||
|
||||
@ -2,22 +2,23 @@
|
||||
title: 10/WAKU2
|
||||
name: Waku v2
|
||||
status: draft
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Reeshav Khan \<reeshav@status.im\>
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
- Reeshav Khan <reeshav@status.im>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Contributors::
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Reeshav Khan \<reeshav@status.im\>
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
- Contributors:
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
- Reeshav Khan <reeshav@status.im>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -351,14 +352,10 @@ therefore the service obtained in the protocol is linkable to the beneficiary's
|
||||
For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics.
|
||||
Likewise, in the `12/WAKU2-FILTER`, a full node can link the light node's `PeerID`s to its content filter.
|
||||
|
||||
|
||||
<!-- TODO: to inspect the nim-libp2p codebase and figure out the exact use of PeerIDs in direct communication, it might be the case that the requester does not have to disclose its PeerID-->
|
||||
|
||||
|
||||
|
||||
<!--TODO: might be good to add a figure visualizing the Waku protocol stack and the security features of each layer-->
|
||||
|
||||
|
||||
## Appendix C: Implementation Notes
|
||||
|
||||
### Implementation Matrix
|
||||
|
||||
@ -2,16 +2,17 @@
|
||||
title: 11/WAKU2-RELAY
|
||||
name: Waku v2 Relay
|
||||
status: stable
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
---
|
||||
- Status: stable
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Contributors::
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
- Contributors:
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
|
||||
|
||||
`11/WAKU2-RELAY` specifies a [Publish/Subscribe approach](https://docs.libp2p.io/concepts/publish-subscribe/) to peer-to-peer messaging with a strong focus on privacy, censorship-resistance, security and scalability.
|
||||
Its current implementation is a minor extension of the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README) and prescribes gossip-based dissemination.
|
||||
@ -92,10 +93,10 @@ message RPC {
|
||||
}
|
||||
```
|
||||
|
||||
\> **_NOTE:_**
|
||||
> **_NOTE:_**
|
||||
The various [control messages](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0##control-messages) defined for GossipSub are used as specified there.
|
||||
|
||||
\> **_NOTE:_**
|
||||
> **_NOTE:_**
|
||||
The [`TopicDescriptor`](https://github.com/libp2p/specs/blob/master/pubsub/README##the-topic-descriptor) is not currently used by `11/WAKU2-RELAY`.
|
||||
|
||||
### Message fields
|
||||
@ -126,7 +127,7 @@ The following usage requirements apply:
|
||||
|
||||
- The `topicid` field MUST contain the pubsub topic.
|
||||
|
||||
\> Note: The `topicid` refering to pubsub topic and
|
||||
> Note: The `topicid` refering to pubsub topic and
|
||||
`topicId` refering to content-topic are detailed in [23/WAKU2-TOPICS](../../../informational/23/topics).
|
||||
|
||||
### Signature Policy
|
||||
|
||||
@ -3,21 +3,20 @@ title: 12/WAKU2-FILTER
|
||||
name: Waku v2 Filter
|
||||
status: draft
|
||||
version: 01
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskar@status.im\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Ebube Ud \<ebube@status.im\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskar@status.im>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Ebube Ud <ebube@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskar@status.im\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Ebube Ud \<ebube@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskar@status.im>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Ebube Ud <ebube@status.im>
|
||||
|
||||
|
||||
previous versions: [00](./previous-versions00)
|
||||
|
||||
@ -2,21 +2,20 @@
|
||||
title: 12/WAKU2-FILTER
|
||||
name: Waku v2 Filter
|
||||
status: draft
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Ebube Ud \<ebube@status.im\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Ebube Ud <ebube@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Ebube Ud \<ebube@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Ebube Ud <ebube@status.im>
|
||||
|
||||
version: 00
|
||||
|
||||
|
||||
@ -2,22 +2,23 @@
|
||||
title: 13/WAKU2-STORE
|
||||
name: Waku v2 Store
|
||||
status: draft
|
||||
editor: Simon-Pierre Vivier \<simvivier@status.im\>
|
||||
editor: Simon-Pierre Vivier <simvivier@status.im>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Aaryamann Challani <aaryamann@status.im>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Simon-Pierre Vivier \<simvivier@status.im\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Editor: Simon-Pierre Vivier <simvivier@status.im>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Aaryamann Challani <aaryamann@status.im>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
|
||||
|
||||
## Abstract
|
||||
This specification explains the `13/WAKU2-STORE` protocol which enables querying of messages received through the relay protocol and
|
||||
|
||||
@ -3,23 +3,24 @@ title: 14/WAKU2-MESSAGE
|
||||
name: Waku v2 Message
|
||||
status: draft
|
||||
category: Standards Track
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Lorenzo Delgado \<lorenzo@status.im\>
|
||||
- Abhimanyu Rawat \<abhi@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Aaryamann Challani <aaryamann@status.im>
|
||||
- Lorenzo Delgado <lorenzo@status.im>
|
||||
- Abhimanyu Rawat <abhi@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Standards Track
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Contributors::
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Lorenzo Delgado \<lorenzo@status.im\>
|
||||
- Abhimanyu Rawat \<abhi@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
- Contributors:
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Aaryamann Challani <aaryamann@status.im>
|
||||
- Lorenzo Delgado <lorenzo@status.im>
|
||||
- Abhimanyu Rawat <abhi@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -172,7 +173,7 @@ Waku message hash computation (`meta` attribute not present):
|
||||
pubsub_topic = "/waku/2/default-waku/proto" (0x2f77616b752f322f64656661756c742d77616b752f70726f746f)
|
||||
message.payload = 0x010203045445535405060708
|
||||
message.content_topic = "/waku/2/default-content/proto" (0x2f77616b752f322f64656661756c742d636f6e74656e742f70726f746f)
|
||||
message.meta = \<not-present\>
|
||||
message.meta = <not-present>
|
||||
message.timestamp = 0x175789bfa23f8400
|
||||
|
||||
message_hash = 0xa2554498b31f5bcdfcbf7fa58ad1c2d45f0254f3f8110a85588ec3cf10720fd8
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
title: 15/WAKU-BRIDGE
|
||||
name: Waku Bridge
|
||||
status: draft
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
|
||||
A bridge between Waku v1 and Waku v2.
|
||||
|
||||
|
||||
@ -2,20 +2,21 @@
|
||||
title: 17/WAKU2-RLN-RELAY
|
||||
name: Waku v2 RLN Relay
|
||||
status: draft
|
||||
editor: Alvaro Revuelta \<alvaro@status.im\>
|
||||
editor: Alvaro Revuelta <alvaro@status.im>
|
||||
contributors:
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Aaryamann Challani <aaryamann@status.im>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Alvaro Revuelta \<alvaro@status.im\>
|
||||
- Contributors::
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Aaryamann Challani \<aaryamann@status.im\>
|
||||
- Sanaz Taheri \<sanaz@status.im\>
|
||||
- Hanno Cornelius \<hanno@status.im\>
|
||||
- Editor: Alvaro Revuelta <alvaro@status.im>
|
||||
- Contributors:
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Aaryamann Challani <aaryamann@status.im>
|
||||
- Sanaz Taheri <sanaz@status.im>
|
||||
- Hanno Cornelius <hanno@status.im>
|
||||
|
||||
|
||||
The `17/WAKU2-RLN-RELAY` protocol is an extension of `11/WAKU2-RELAY` which additionally provides spam protection using [Rate Limiting Nullifiers (RLN)](../../../../vac/32/rln-v1).
|
||||
|
||||
|
||||
@ -2,16 +2,17 @@
|
||||
title: 19/WAKU2-LIGHTPUSH
|
||||
name: Waku v2 Light Push
|
||||
status: draft
|
||||
editor: Hanno Cornelius \<hanno@status.im\>
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Hanno Cornelius \<hanno@status.im\>
|
||||
- Contributors::
|
||||
- Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
- Contributors:
|
||||
- Daniel Kaiser <danielkaiser@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
|
||||
**Protocol identifier**: `/vac/waku/lightpush/2.0.0-beta1`
|
||||
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
title: 33/WAKU2-DISCV5
|
||||
name: Waku v2 Discv5 Ambient Peer Discovery
|
||||
status: draft
|
||||
editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||||
editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Daniel Kaiser \<danielkaiser@status.im\>
|
||||
- Editor: Daniel Kaiser <danielkaiser@status.im>
|
||||
|
||||
## Abstract
|
||||
|
||||
@ -89,31 +89,31 @@ to avoid cluttering peer lists with nodes that are not reachable.
|
||||
|
||||
Ethereum discv5:
|
||||
|
||||
\<pre\>
|
||||
\<code\>
|
||||
<pre>
|
||||
<code>
|
||||
header = static-header || authdata
|
||||
static-header = protocol-id || version || flag || nonce || authdata-size
|
||||
protocol-id = \<b\>"discv5"\</b\>
|
||||
protocol-id = <b>"discv5"</b>
|
||||
version = 0x0001
|
||||
authdata-size = uint16 -- byte length of authdata
|
||||
flag = uint8 -- packet type identifier
|
||||
nonce = uint96 -- nonce of message
|
||||
\</code\>
|
||||
\</pre\>
|
||||
</code>
|
||||
</pre>
|
||||
|
||||
`33/WAKU2-DISCV5`:
|
||||
|
||||
\<pre\>
|
||||
kcode\>
|
||||
<pre>
|
||||
kcode>
|
||||
header = static-header || authdata
|
||||
static-header = protocol-id || version || flag || nonce || authdata-size
|
||||
protocol-id = \<b\>"d5waku"\</b\>
|
||||
protocol-id = <b>"d5waku"</b>
|
||||
version = 0x0001
|
||||
authdata-size = uint16 -- byte length of authdata
|
||||
flag = uint8 -- packet type identifier
|
||||
nonce = uint96 -- nonce of message
|
||||
\</code\>
|
||||
\</pre\>
|
||||
</code>
|
||||
</pre>
|
||||
|
||||
|
||||
## Suggestions for Implementations
|
||||
|
||||
@ -2,13 +2,14 @@
|
||||
title: 36/WAKU2-BINDINGS-API
|
||||
name: Waku v2 C Bindings API
|
||||
status: draft
|
||||
editor: Richard Ramos \<richard@status.im\>
|
||||
editor: Richard Ramos <richard@status.im>
|
||||
contributors:
|
||||
- Franck Royer \<franck@status.im\>
|
||||
- Franck Royer <franck@status.im>
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Richard Ramos \<richard@status.im\>
|
||||
- Contributors::
|
||||
- Editor: Richard Ramos <richard@status.im>
|
||||
- Contributors:
|
||||
- Franck Royer <franck@status.im>
|
||||
|
||||
|
||||
# Introduction
|
||||
@ -273,12 +274,12 @@ interface JsonConfig {
|
||||
nodeKey?: string;
|
||||
keepAliveInterval?: number;
|
||||
relay?: boolean;
|
||||
relayTopics?: Array\<string\>;
|
||||
relayTopics?: Array<string>;
|
||||
gossipsubParameters?: GossipSubParameters;
|
||||
minPeersToPublish?: number
|
||||
legacyFilter?: boolean;
|
||||
discV5?: boolean;
|
||||
discV5BootstrapNodes?: Array\<string\>;
|
||||
discV5BootstrapNodes?: Array<string>;
|
||||
discV5UDPPort?: number;
|
||||
store?: boolean;
|
||||
databaseURL?: string;
|
||||
|
||||
321
waku/standards/core/64/network.md
Normal file
321
waku/standards/core/64/network.md
Normal file
@ -0,0 +1,321 @@
|
||||
---
|
||||
title: 64/WAKU2-NETWORK
|
||||
name: Waku v2 Network
|
||||
status: draft
|
||||
category: Best Current Practice
|
||||
editor: Hanno Cornelius <hanno@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Category: Best Current Practice
|
||||
- Editor: Hanno Cornelius <hanno@status.im>
|
||||
|
||||
## Abstract
|
||||
|
||||
This specification describes an opinionated deployment of [10/WAKU2](../10/waku2) protocols to form a coherent and
|
||||
shared decentralized messaging network that is open-access,
|
||||
useful for generalized messaging, privacy-preserving, scalable and
|
||||
accessible even to resource-restricted devices.
|
||||
We'll refer to this opinionated deployment simply as
|
||||
_the public Waku Network_, _the Waku Network_ or, if the context is clear, _the network_
|
||||
in the rest of this document.
|
||||
|
||||
## Theory / Semantics
|
||||
|
||||
### Routing protocol
|
||||
|
||||
The Waku Network is built on the [17/WAKU2-RLN-RELAY](../17/rln-relay) routing protocol,
|
||||
which in turn is an extension of [11/WAKU2-RELAY](../11/relay) with spam protection measures.
|
||||
|
||||
### Network shards
|
||||
|
||||
Traffic in the Waku Network is sharded into eight [17/WAKU2-RLN-RELAY](../17/rln-relay) pubsub topics.
|
||||
Each pubsub topic is named according to the static shard naming format
|
||||
defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding)
|
||||
with:
|
||||
* `<cluster_id>` set to `1`
|
||||
* `<shard_number>` occupying the range `0` to `7`.
|
||||
In other words, the Waku Network is a [17/WAKU2-RLN-RELAY](../17/rln-relay) network
|
||||
routed on the combination of the eight pubsub topics:
|
||||
```
|
||||
/waku/2/rs/1/0
|
||||
/waku/2/rs/1/1
|
||||
...
|
||||
/waku/2/rs/1/7
|
||||
```
|
||||
|
||||
A node MUST use [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata) protocol to identify the `<cluster_id>` that every
|
||||
inbound/outbound peer that attempts to connect supports. In any of the following cases, the node MUST trigger a disconnection:
|
||||
* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata) dial fails.
|
||||
* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata) reports an empty `<cluster_id>`.
|
||||
* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata) reports a `<cluster_id>` different than `1`.
|
||||
|
||||
## Roles
|
||||
|
||||
There are two distinct roles evident in the network, those of:
|
||||
1) nodes, and
|
||||
2) applications.
|
||||
|
||||
### Nodes
|
||||
|
||||
Nodes are the individual software units
|
||||
using [10/WAKU2](../10/waku2) protocols to form a p2p messaging network.
|
||||
Nodes, in turn, can participate in a shard as full relayers, i.e. _relay nodes_,
|
||||
or by running a combination of protocols suitable for resource-restricted environments,
|
||||
i.e. _non-relay nodes_.
|
||||
Nodes can also provide various services to the network,
|
||||
such as storing historical messages or protecting the network against spam.
|
||||
See the section on [default services](#default-services) for more.
|
||||
|
||||
#### Relay nodes
|
||||
|
||||
Relay nodes MUST follow [17/WAKU2-RLN-RELAY](../17/rln-relay)
|
||||
to route messages to other nodes in the network
|
||||
for any of the pubsub topics [defined as the Waku Network shards](#network-shards).
|
||||
Relay nodes MAY choose to subscribe to any of these shards,
|
||||
but MUST be subscribed to at least one defined shard.
|
||||
Each relay node SHOULD be subscribed to as many shards as it has resources to support.
|
||||
If a relay node supports an encapsulating application,
|
||||
it SHOULD be subscribed to all the shards servicing that application.
|
||||
If resource restrictions prevent a relay node from servicing all shards used by the encapsulating application,
|
||||
it MAY choose to support some shards as a non-relay node.
|
||||
|
||||
#### Bootstrapping and discovery
|
||||
|
||||
Nodes MAY use any method to bootstrap connection to the network,
|
||||
but it is RECOMMENDED that each node retrieves a list of bootstrap peers to connect to using [EIP-1459 DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459).
|
||||
Relay nodes SHOULD use [33/WAKU2-DISCV5](../33/discv5) to continually discover other peers in the network.
|
||||
Each relay node MUST encode its supported shards into its discoverable ENR,
|
||||
as described in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding#discovery).
|
||||
The ENR MUST be updated if the set of supported shards change.
|
||||
A node MAY choose to ignore discovered peers that do not support any of the shards in its own subscribed set.
|
||||
|
||||
#### Transports
|
||||
|
||||
Relay nodes MUST follow [10/WAKU2](../10/waku2) specifications with regards to supporting different transports.
|
||||
If TCP transport is available, each relay node MUST support it as transport for both dialing and listening.
|
||||
In addition, a relay node SHOULD support secure websockets for bidirectional communication streams,
|
||||
for example to allow connections from and to web browser-based clients.
|
||||
A relay node MAY support unsecure websockets if required by the application or running environment.
|
||||
|
||||
#### Default services
|
||||
|
||||
For each supported shard,
|
||||
each relay node SHOULD enable and support the following protocols as a service node:
|
||||
1. [12/WAKU2-FILTER](../12/filter) to allow resource-restricted peers to subscribe to messages matching a specific content filter.
|
||||
2. [13/WAKU2-STORE](../13/store) to allow other peers to request historical messages from this node.
|
||||
3. [19/WAKU2-LIGHTPUSH](../19/lightpush) to allow resource-restricted peers to request publishing a message to the network on their behalf.
|
||||
4. [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange) to allow resource-restricted peers to discover more peers in a resource efficient way.
|
||||
|
||||
#### Store service nodes
|
||||
|
||||
Each relay node SHOULD support [13/WAKU2-STORE](../13/store) as a store service node,
|
||||
for each supported shard.
|
||||
The store SHOULD be configured to retain at least `12` hours of messages per supported shard.
|
||||
Store service nodes SHOULD only store messages with a valid [`rate_limit_proof`](#message-attributes) attribute.
|
||||
|
||||
#### Non-relay nodes
|
||||
|
||||
Nodes MAY opt out of relay functionality on any network shard
|
||||
and instead request services from relay nodes as clients
|
||||
using any of the defined service protocols:
|
||||
1. [12/WAKU2-FILTER](../12/filter) to subscribe to messages matching a specific content filter.
|
||||
2. [13/WAKU2-STORE](../13/store) to request historical messages matching a specific content filter.
|
||||
3. [19/WAKU2-LIGHTPUSH](../19/lightpush) to request publishing a message to the network.
|
||||
4. [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange) to discover more peers in a resource efficient way.
|
||||
|
||||
#### Store client nodes
|
||||
|
||||
Nodes MAY request historical messages from [13/WAKU2-STORE](../13/store) service nodes as store clients.
|
||||
A store client SHOULD discard any messages retrieved from a store service node that do not contain a valid [`rate_limit_proof`](#message-attributes) attribute.
|
||||
The client MAY consider service nodes returning messages without a valid [`rate_limit_proof`](#message-attributes) attribute as untrustworthy.
|
||||
The mechanism by which this may happen is currently underdefined.
|
||||
|
||||
### Applications
|
||||
|
||||
Applications are the higher-layer projects or platforms that make use of the generalized messaging capability of the network.
|
||||
In other words, an application defines a payload used in the various [10/WAKU2](../10/waku2) protocols.
|
||||
Any participant in an application SHOULD make use of an underlying node in order to communicate on the network.
|
||||
Applications SHOULD make use of an [autosharding](#autosharding) API
|
||||
to allow the underlying node to automatically select the target shard on the Waku Network.
|
||||
See the section on [autosharding](#autosharding) for more.
|
||||
|
||||
## RLN rate-limiting
|
||||
|
||||
The [17/WAKU2-RLN-RELAY](../17/rln-relay) protocol uses [32/RLN-V1](../../../../vac/32/rln-v1) proofs
|
||||
to ensure that a pre-agreed rate limit is not exceeded by any publisher.
|
||||
While the network is under capacity,
|
||||
individual relayers MAY choose to freely route messages without RLN proofs
|
||||
up to a discretionary bandwidth limit,
|
||||
after which messages without proofs MUST be discarded by relay nodes.
|
||||
This bandwidth limit SHOULD be enforced using a [bandwidth validation mechanism](#free-bandwidth-exceeded) separate from a RLN rate-limiting.
|
||||
This implies that quality of service and reliability is significantly lower for messages without proofs
|
||||
and at times of high network utilization these messages may not be relayed at all.
|
||||
|
||||
### RLN Parameters
|
||||
|
||||
For the Waku Network,
|
||||
the `epoch` is set to `1` second
|
||||
and the maximum number of messages published per `epoch` is limited to `1` per publisher.
|
||||
The `max_epoch_gap` is set to `20` seconds,
|
||||
meaning that validators (relay nodes),
|
||||
MUST _reject_ messages with an `epoch` more than 20 seconds into the past or
|
||||
future compared to the validator's own clock.
|
||||
All nodes, validators and publishers,
|
||||
SHOULD use Network Time Protocol (NTP) to synchronize their own clocks,
|
||||
thereby ensuring valid timestamps for proof generation and validation.
|
||||
|
||||
|
||||
### Memberships
|
||||
|
||||
Each publisher to the Waku Network SHOULD register an RLN membership
|
||||
with one of the RLN storage contracts
|
||||
moderated in the Sepolia registry contract with address [0xF1935b338321013f11068abCafC548A7B0db732C](https://sepolia.etherscan.io/address/0xF1935b338321013f11068abCafC548A7B0db732C#code).
|
||||
Initial memberships are registered in the Sepolia RLN storage contract with address [0x58322513A35a8f747AF5A385bA14C2AbE602AA59](https://sepolia.etherscan.io/address/0x58322513A35a8f747AF5A385bA14C2AbE602AA59#code).
|
||||
RLN membership setup and registration MUST follow [17/WAKU2-RLN-RELAY](../17/rln-relay#setup-and-registration),
|
||||
with the `staked_fund` set to `0`.
|
||||
In other words, the Waku Network does not use RLN staking.
|
||||
|
||||
### RLN Proofs
|
||||
|
||||
Each RLN member MUST generate and attach an RLN proof to every published message
|
||||
as described in [17/WAKU2-RLN-RELAY](../17/rln-relay#publishing).
|
||||
Slashing is not implemented for the Waku Network.
|
||||
Instead, validators will penalise peers forwarding messages exceeding the rate limit
|
||||
as specified for [the rate-limiting validation mechanism](#rate-limit-exceeded).
|
||||
This incentivizes all relay nodes to validate RLN proofs
|
||||
and reject messages violating rate limits
|
||||
in order to continue participating in the network.
|
||||
|
||||
## Network traffic
|
||||
|
||||
All payload on the Waku Network MUST be encapsulated in a [14/WAKU2-MESSAGE](../14/message)
|
||||
with rate limit proof extensions defined for [17/WAKU2-RLN-RELAY](../17/rln-relay#payloads).
|
||||
Each message on the Waku Network SHOULD be validated by each relayer,
|
||||
according to the rules discussed under [message validation](#message-validation).
|
||||
|
||||
### Message Attributes
|
||||
|
||||
- The mandatory `payload` attribute MUST contain the message data payload as crafted by the application.
|
||||
- The mandatory `content_topic` attribute MUST specify a string identifier that can be used for content-based filtering.
|
||||
This is also crafted by the application.
|
||||
See [Autosharding](#autosharding) for more on the content topic format.
|
||||
- The optional `meta` attribute MAY be omitted.
|
||||
If present, will form part of the message uniqueness vector described in [14/WAKU2-MESSAGE](../14/message).
|
||||
- The optional `version` attribute SHOULD be set to `0`. It MUST be interpreted as `0` if not present.
|
||||
- The mandatory `timestamp` attribute MUST contain the Unix epoch time at which the message was generated by the application.
|
||||
The value MUST be in nanoseconds.
|
||||
It MAY contain a fudge factor of up to 1 seconds in either direction to improve resistance to timing attacks.
|
||||
- The optional `ephemeral` attribute MUST be set to `true` if the message should not be persisted by the Waku Network.
|
||||
- The optional `rate_limit_proof` attribute SHOULD be populated with the RLN proof as set out in [RLN Proofs](#rln-proofs).
|
||||
Messages with this field unpopulated MAY be discarded from the network by relayers.
|
||||
This field MUST be populated if the message should be persisted by the Waku Network.
|
||||
|
||||
### Message Size
|
||||
|
||||
Any [14/WAKU2-MESSAGE](../14/message) published to the network MUST NOT exceed an absolute maximum size of `150` kilobytes.
|
||||
This limit applies to the entire message after protobuf serialization, including attributes.
|
||||
It is RECOMMENDED not to exceed an average size of `4` kilobytes for [14/WAKU2-MESSAGE](../14/message) published to the network.
|
||||
|
||||
### Message Validation
|
||||
|
||||
Relay nodes MUST apply [gossipsub v1.1 validation](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1##extended-validators) to each relayed message and
|
||||
SHOULD apply all of the rules set out in the section below to determine the validity of a message.
|
||||
Validation has one of three outcomes,
|
||||
repeated here from the [gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1##extended-validators) for ease of reference:
|
||||
1. Accept - the message is considered valid and it MUST be delivered and forwarded to the network.
|
||||
2. Reject - the message is considered invalid, MUST be rejected and SHOULD trigger a gossipsub scoring penalty against the transmitting peer.
|
||||
3. Ignore - the message SHOULD NOT be delivered and forwarded to the network, but this MUST NOT trigger a gossipsub scoring penalty against the transmitting peer.
|
||||
|
||||
The following validation rules are defined:
|
||||
|
||||
#### Decoding failure
|
||||
|
||||
If a message fails to decode as a valid [14/WAKU2-MESSAGE](../14/message),
|
||||
the relay node MUST _reject_ the message.
|
||||
This SHOULD trigger a penalty against the transmitting peer.
|
||||
|
||||
#### Invalid timestamp
|
||||
|
||||
If a message has a timestamp deviating by more than `20` seconds
|
||||
either into the past or the future
|
||||
when compared to the relay node's internal clock,
|
||||
the relay node MUST _reject_ the message.
|
||||
This allows for some deviation between internal clocks,
|
||||
network routing latency and
|
||||
an optional [fudge factor when timestamping new messages](#message-attributes).
|
||||
|
||||
#### Free bandwidth exceeded
|
||||
|
||||
If a message contains no RLN proof
|
||||
and the current bandwidth utilization on the shard the message was published to
|
||||
equals or exceeds `1` Mbps,
|
||||
the relay node SHOULD _ignore_ the message.
|
||||
|
||||
#### Invalid RLN epoch
|
||||
|
||||
If a message contains an RLN proof
|
||||
and the `epoch` attached to the proof deviates by more than `max_epoch_gap` seconds
|
||||
from the relay node's own `epoch`,
|
||||
the relay node MUST _reject_ the message.
|
||||
`max_epoch_gap` is [set to `20` seconds](#rln-parameters) for the Waku Network.
|
||||
|
||||
#### Invalid RLN proof
|
||||
|
||||
If a message contains an RLN proof
|
||||
and the zero-knowledge proof is invalid
|
||||
according to the verification process described in [32/RLN-V1](../../../../vac/32/rln-v1),
|
||||
the relay node MUST _ignore_ the message.
|
||||
|
||||
#### Rate limit exceeded
|
||||
|
||||
If a message contains an RLN proof
|
||||
and the relay node detects double signaling
|
||||
according to the verification process described in [32/RLN-V1](../../../../vac/32/rln-v1),
|
||||
the relay node MUST _reject_ the message
|
||||
for violating the agreed rate limit of `1` message every `1` second.
|
||||
This SHOULD trigger a penalty against the transmitting peer.
|
||||
|
||||
## Autosharding
|
||||
|
||||
Nodes in the Waku Network SHOULD allow encapsulating applications to use autosharding,
|
||||
as defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding#automatic-sharding)
|
||||
by automatically determining the appropriate pubsub topic
|
||||
from the list [of defined Waku Network shards](#network-shards).
|
||||
This allows the application to omit the target pubsub topic
|
||||
when invoking any Waku protocol function.
|
||||
Applications using autosharding MUST use content topics in the format
|
||||
defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding#content-topics-format-for-autosharding)
|
||||
and SHOULD use the short length format:
|
||||
|
||||
```
|
||||
/{application-name}/{version-of-the-application}/{content-topic-name}/{encoding}
|
||||
```
|
||||
|
||||
When an encapsulating application makes use of autosharding
|
||||
the underlying node MUST determine the target pubsub topic(s)
|
||||
from the content topics provided by the application
|
||||
using the hashing mechanism defined in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding#automatic-sharding).
|
||||
|
||||
## Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
||||
## References
|
||||
|
||||
* [10/WAKU2](../10/waku2)
|
||||
* [17/WAKU2-RLN-RELAY](../17/rln-relay)
|
||||
* [11/WAKU2-RELAY](../11/relay)
|
||||
* [WAKU2-RELAY-SHARDING](../../core/relay-sharding)
|
||||
* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata)
|
||||
* [EIP-1459 DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459)
|
||||
* [33/WAKU2-DISCV5](../33/discv5)
|
||||
* [12/WAKU2-FILTER](../12/filter)
|
||||
* [13/WAKU2-STORE](../13/store)
|
||||
* [19/WAKU2-LIGHTPUSH](../19/lightpush)
|
||||
* [34/WAKU2-PEER-EXCHANGE](../../core/peer-exchange)
|
||||
* [32/RLN-V1](../../../../vac/32/rln-v1)
|
||||
* [14/WAKU2-MESSAGE](../14/message)
|
||||
* [gossipsub v1.1 validation](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1##extended-validators)
|
||||
* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding)
|
||||
*
|
||||
@ -2,11 +2,11 @@
|
||||
title: 66/WAKU2-METADATA
|
||||
name: Waku Metadata Protocol
|
||||
status: draft
|
||||
editor: Alvaro Revuelta \<alrevuelta@status.im\>
|
||||
editor: Alvaro Revuelta <alrevuelta@status.im>
|
||||
contributors:
|
||||
---
|
||||
- Status: draft
|
||||
- Editor: Alvaro Revuelta \<alrevuelta@status.im\>
|
||||
- Editor: Alvaro Revuelta <alrevuelta@status.im>
|
||||
|
||||
## Abstract
|
||||
This specification describes the metadata that can be associated with a [10/WAKU2](../10/waku2) node.
|
||||
|
||||
@ -2,20 +2,21 @@
|
||||
title: 6/WAKU1
|
||||
name: Waku v1
|
||||
status: stable
|
||||
editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
- Adam Babik \<adam@status.im\>
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Kim De Mey \<kimdemey@status.im\>
|
||||
- Adam Babik <adam@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Kim De Mey <kimdemey@status.im>
|
||||
---
|
||||
- Status: stable
|
||||
- Editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Contributors::
|
||||
- Adam Babik \<adam@status.im\>
|
||||
- Andrea Maria Piana \<andreap@status.im\>
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Kim De Mey \<kimdemey@status.im\>
|
||||
- Editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Contributors:
|
||||
- Adam Babik <adam@status.im>
|
||||
- Andrea Maria Piana <andreap@status.im>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Kim De Mey <kimdemey@status.im>
|
||||
|
||||
|
||||
This specification describes the format of Waku packets within the ÐΞVp2p Wire Protocol. This spec substitutes [EIP-627](https://eips.ethereum.org/EIPS/eip-627). Waku is a fork of the original Whisper protocol that enables better usability for resource restricted devices, such as mostly-offline bandwidth-constrained smartphones. It does this through (a) light node support, (b) historic envelopes (with a mailserver) (c) expressing topic interest for better bandwidth usage and (d) basic rate limiting.
|
||||
|
||||
@ -446,7 +447,7 @@ Waku is a different subprotocol from Whisper so it isn't directly compatible. Ho
|
||||
2. C picks up envelope from A and B and relays them both to Waku and Whisper.
|
||||
3. A receives envelope on Waku; B on Whisper.
|
||||
|
||||
**Note**: This flow means if another bridge C1 is active, we might get duplicate relaying for a envelope between C1 and C2. I.e. Whisper(\<\>Waku\<\>Whisper)\<\>Waku, A-C1-C2-B. Theoretically this bridging chain can get as long as TTL permits.
|
||||
**Note**: This flow means if another bridge C1 is active, we might get duplicate relaying for a envelope between C1 and C2. I.e. Whisper(<>Waku<>Whisper)<>Waku, A-C1-C2-B. Theoretically this bridging chain can get as long as TTL permits.
|
||||
|
||||
### Forward Compatibility
|
||||
|
||||
|
||||
@ -2,16 +2,17 @@
|
||||
title: 7/WAKU-DATA
|
||||
name: Waku Envelope data field
|
||||
status: stable
|
||||
editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Kim De Mey \<kimdemey@status.im\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Kim De Mey <kimdemey@status.im>
|
||||
---
|
||||
- Status: stable
|
||||
- Editor: Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Kim De Mey \<kimdemey@status.im\>
|
||||
- Editor: Oskar Thorén <oskarth@titanproxy.com>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Kim De Mey <kimdemey@status.im>
|
||||
|
||||
|
||||
This specification describes the encryption, decryption and signing of the content in the [data field used in Waku](../6/waku1#abnf-specification).
|
||||
|
||||
|
||||
@ -2,18 +2,19 @@
|
||||
title: 8/WAKU-MAIL
|
||||
name: Waku Mailserver
|
||||
status: stable
|
||||
editor: Andrea Maria Piana \<andreap@status.im\>
|
||||
editor: Andrea Maria Piana <andreap@status.im>
|
||||
contributors:
|
||||
- Adam Babik \<adam@status.im\>
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Adam Babik <adam@status.im>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
- Status: stable
|
||||
- Editor: Andrea Maria Piana \<andreap@status.im\>
|
||||
- Contributors::
|
||||
- Adam Babik \<adam@status.im\>
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Andrea Maria Piana <andreap@status.im>
|
||||
- Contributors:
|
||||
- Adam Babik <adam@status.im>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
@ -2,16 +2,17 @@
|
||||
title: 9/WAKU-RPC
|
||||
name: Waku RPC API
|
||||
status: stable
|
||||
editor: Andrea Maria Piana \<andreap@status.im\>
|
||||
editor: Andrea Maria Piana <andreap@status.im>
|
||||
contributors:
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
---
|
||||
- Status: stable
|
||||
- Editor: Andrea Maria Piana \<andreap@status.im\>
|
||||
- Contributors::
|
||||
- Dean Eigenmann \<dean@status.im\>
|
||||
- Oskar Thorén \<oskarth@titanproxy.com\>
|
||||
- Editor: Andrea Maria Piana <andreap@status.im>
|
||||
- Contributors:
|
||||
- Dean Eigenmann <dean@status.im>
|
||||
- Oskar Thorén <oskarth@titanproxy.com>
|
||||
|
||||
|
||||
This specification describes the RPC API that Waku nodes MAY adhere to. The unified API allows clients to easily
|
||||
be able to connect to any node implementation. The API described is privileged as a node stores the keys of clients.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user