From c51271253a5147a9f0e50a3024272b183e37b030 Mon Sep 17 00:00:00 2001 From: Filip Pajic <42151917+pajicf@users.noreply.github.com> Date: Thu, 9 May 2024 11:24:54 +0200 Subject: [PATCH 1/5] fix: Headers parsing fix (#5) * fix: html tag symbol parsing * fix: missing contributors in parsing --- .../scrapper/markdown-convertor.mjs | 21 ++++++++++++------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/docusaurus-utils/scrapper/markdown-convertor.mjs b/docusaurus-utils/scrapper/markdown-convertor.mjs index e29a495f2..1c60bd53d 100644 --- a/docusaurus-utils/scrapper/markdown-convertor.mjs +++ b/docusaurus-utils/scrapper/markdown-convertor.mjs @@ -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')}`) contributorsLines = [] // Reset for safety } return line // Keep the frontmatter delimiters @@ -24,13 +24,11 @@ function enhanceMarkdownWithBulletPointsCorrected(input) { if (line.startsWith('contributors:')) { inContributors = true // Entering contributors section } else if (inContributors) { - if (line.startsWith(' -')) { + if (line.trim().startsWith('-')) { contributorsLines.push(line.trim()) // Add contributors line } else { // Exiting contributors section inContributors = false - extractedFields.push(`contributors:\n${contributorsLines.join('\n')}`) - contributorsLines = [] // Reset } } else { const match = line.match(/(status|category|editor):(.*)/) @@ -82,8 +80,17 @@ function parseSlugFromFrontmatter(content) { return 1 // Return null if not found } +function escapeHtmlTagSymbols(content) { + // Escape < and > with < and >, respectively + // Be cautious with this replacement; adjust as needed based on your context + content = content.replace(/(?(?!.*?`)/g, '>') + + return content; +} + function unescapeHtmlComments(htmlString) { - return htmlString.replace(/\\<\!--/g, '\n\n') + return htmlString.replace(/<\!--/g, '\n\n') } function updateMarkdownLinksToExcludeMD(content) { @@ -107,9 +114,7 @@ export function vacMarkdownToDocusaurusMarkdown(fileContent) { // Replace
with
convertedContent = convertedContent.replace(/
/g, '
') - // Escape < and > with \< and \>, respectively - // Be cautious with this replacement; adjust as needed based on your context - convertedContent = convertedContent.replace(//g, '\\>') + convertedContent = escapeHtmlTagSymbols(convertedContent) // NEW: Remove 'slug' line from frontmatter convertedContent = convertedContent.replace(/^slug:.*\n?/m, '') From 6a9b7654cce0b937abb5966a1feba583a11c3706 Mon Sep 17 00:00:00 2001 From: Filip Pajic <42151917+pajicf@users.noreply.github.com> Date: Thu, 9 May 2024 12:40:06 +0200 Subject: [PATCH 2/5] chore: Fresh scraping on each sync (#4) --- docusaurus-utils/scrapper/file.mjs | 16 +++++++++++++++- docusaurus-utils/scrapper/main.mjs | 9 +++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/docusaurus-utils/scrapper/file.mjs b/docusaurus-utils/scrapper/file.mjs index 3f11b6433..03cad0032 100644 --- a/docusaurus-utils/scrapper/file.mjs +++ b/docusaurus-utils/scrapper/file.mjs @@ -36,7 +36,7 @@ export async function writeLargeFile(path, data) { export function removeDirectory(path) { return new Promise((resolve, reject) => { - fs.rmdir(path, {recursive: true}, err => { + fs.rm(path, {recursive: true}, err => { if (err) { reject(err) } @@ -46,6 +46,20 @@ export function removeDirectory(path) { }) } +export function directoryExists(path) { + return new Promise((resolve, _) => { + const accessBitwiseOperator = fs.constants.F_OK | fs.constants.R_OK; + + fs.access(path, accessBitwiseOperator, err => { + if (err) { + resolve(false) + } else { + resolve(true) + } + }) + }) +} + export async function createDirectory(path) { try { /* diff --git a/docusaurus-utils/scrapper/main.mjs b/docusaurus-utils/scrapper/main.mjs index 580e00a3f..57aac7c7e 100644 --- a/docusaurus-utils/scrapper/main.mjs +++ b/docusaurus-utils/scrapper/main.mjs @@ -1,4 +1,6 @@ import { fetchDirectoryContents } from './fetch-content.mjs' +import path from 'path' +import { directoryExists, removeDirectory } from './file.mjs' const directoriesToSync = ['codex', 'nomos', 'status', 'vac', 'waku'] @@ -10,6 +12,13 @@ async function main() { const baseSavePath = `./${dirName}/` const prefixToRemove = dirName + '/' + const directoryPath = path.join(process.cwd(), dirName); + + const shouldRemoveOldContent = await directoryExists(directoryPath); + if (shouldRemoveOldContent) { + await removeDirectory(directoryPath) + console.log(`Removed old ${dirName}`) + } await fetchDirectoryContents(baseUrl, baseSavePath, prefixToRemove) console.log(`Synced ${dirName}`) From 802fdfe62b471b427bbf96d3419209a65d7e562c Mon Sep 17 00:00:00 2001 From: Filip Pajic <42151917+pajicf@users.noreply.github.com> Date: Sun, 12 May 2024 14:25:36 +0200 Subject: [PATCH 3/5] feature: support for multiple versions of the same document (#6) --- docusaurus-utils/sidebar/classifiers.js | 50 +++++++++++++++++++++++++ docusaurus-utils/sidebar/generator.js | 8 +++- docusaurus-utils/sidebar/helpers.js | 39 ++++++++++++++++++- docusaurus-utils/sidebar/utils.js | 4 +- 4 files changed, 97 insertions(+), 4 deletions(-) create mode 100644 docusaurus-utils/sidebar/classifiers.js diff --git a/docusaurus-utils/sidebar/classifiers.js b/docusaurus-utils/sidebar/classifiers.js new file mode 100644 index 000000000..c43368e50 --- /dev/null +++ b/docusaurus-utils/sidebar/classifiers.js @@ -0,0 +1,50 @@ +const { + isIndexDocument, + getRFCOccurrenceMapKey +} = require("./helpers"); +const { isNumber } = require('./utils') + +// By convention, Docusaurus considers some docs are "indexes": +// - index.md +// - readme.md +// - /.md +// +// This function is the default implementation of this convention +// +// Those index docs produce a different behavior +// - Slugs do not end with a weird "/index" suffix +// - Auto-generated sidebar categories link to them as intro +const isCategoryIndex = (rfcOccurrenceMap) => ({ + fileName, + directories, + extension +}) => { + const isIndexByName = isIndexDocument(fileName, directories[0]); + const isRFCWithMultipleVersions = isVersionedRFC(fileName, directories, extension, rfcOccurrenceMap); + + return (isIndexByName || isRFCWithMultipleVersions) +} + +function isVersionedRFC(fileName, directories, extension, rfcOccurrenceMap) { + if (extension.toLowerCase() !== ".md") { + return false; + } + + if (!isNumber(directories[0])) { + return false; + } + + if (rfcOccurrenceMap) { + const key = getRFCOccurrenceMapKey(fileName, extension, directories.reverse().join("/")); + + if (rfcOccurrenceMap[key] >= 2) { + return true + } + } + + return false; +} + +module.exports = { + isCategoryIndex +} \ No newline at end of file diff --git a/docusaurus-utils/sidebar/generator.js b/docusaurus-utils/sidebar/generator.js index b487f8cfd..f9af7d39a 100644 --- a/docusaurus-utils/sidebar/generator.js +++ b/docusaurus-utils/sidebar/generator.js @@ -5,9 +5,15 @@ const { separateFoldersAndFilesOrder, orderAlphabeticallyAndByNumber } = require("./modifiers") +const { isCategoryIndex } = require("./classifiers") +const { rawDocsToRFCOccurrenceMap } = require("./helpers") async function sidebarItemsGenerator({defaultSidebarItemsGenerator, ...args}) { - const defaultSidebarItems = await defaultSidebarItemsGenerator(args); + const rfcOccurrenceMap = rawDocsToRFCOccurrenceMap(args.docs) + const defaultSidebarItems = await defaultSidebarItemsGenerator({ + ...args, + isCategoryIndex: isCategoryIndex(rfcOccurrenceMap) + }); /* We'll have multiple O(N) passes through the items depending on the reducer implementation, diff --git a/docusaurus-utils/sidebar/helpers.js b/docusaurus-utils/sidebar/helpers.js index b45c4caf9..56df611f9 100644 --- a/docusaurus-utils/sidebar/helpers.js +++ b/docusaurus-utils/sidebar/helpers.js @@ -1,3 +1,5 @@ +const path = require("path") + function isIndexDocument(documentId, parentDirectory) { if (!documentId) { return false @@ -10,6 +12,41 @@ function isIndexDocument(documentId, parentDirectory) { ) } +function rawDocsToRFCOccurrenceMap(rawDocs) { + /* + Map containing occurrences of items + The key is made of (Root Numbered Folder + lowercase(Filename + Extension)) + The value is number of occurrences + */ + const occurrenceMap = {} + + rawDocs.forEach(rawDoc => { + const { name, ext } = path.parse(rawDoc.source) + const key = getRFCOccurrenceMapKey(name, ext, rawDoc.sourceDirName) + + if (key) { + occurrenceMap[key] = (occurrenceMap[key] || 0) + 1; + } + }) + + return occurrenceMap +} + +function getRFCOccurrenceMapKey(fileName, ext, dir) { + const parsedDir = dir[0] !== "/" ? `/${dir}` : dir.toString(); + const parsedExt = ext[0] === "." ? ext.slice(1) : ext; + + const match = parsedDir.match(/.*\/\d+(?=\/|$)/) + if (match) { + const rootNumberedRFC = match[0] + return `${rootNumberedRFC}/${fileName.toLowerCase()}.${parsedExt.toLowerCase()}` + } else { + return undefined + } +} + module.exports = { - isIndexDocument + isIndexDocument, + getRFCOccurrenceMapKey, + rawDocsToRFCOccurrenceMap } \ No newline at end of file diff --git a/docusaurus-utils/sidebar/utils.js b/docusaurus-utils/sidebar/utils.js index 208eabda9..b811c5bc1 100644 --- a/docusaurus-utils/sidebar/utils.js +++ b/docusaurus-utils/sidebar/utils.js @@ -1,8 +1,8 @@ function isNumber(value) { - if (true === Array.isArray(value)) { + if (Array.isArray(value)) { return false; } - return !isNaN(parseInt(value, 10)); + return !isNaN(value); } /* From 40a3a4604d8debd22c5e92dc119758e2562afc9f Mon Sep 17 00:00:00 2001 From: Filip Pajic <42151917+pajicf@users.noreply.github.com> Date: Mon, 13 May 2024 11:59:40 +0200 Subject: [PATCH 4/5] chore: MD content updates (#7) * chore: MD content updates * fix: comparison symbol parsing by groups * chore: MD content updates --- .../scrapper/markdown-convertor.mjs | 33 +- nomos/38/claro.md | 110 +++--- status/24/curation.md | 4 +- status/28/featuring.md | 4 +- status/55/1to1-chat.md | 21 +- status/56/communities.md | 31 +- status/61/community-history-service.md | 17 +- status/62/payloads.md | 46 +-- status/63/keycard-usage.md | 31 +- status/65/account-address.md | 15 +- status/71/push-notification-server.md | 97 +++--- status/raw/simple-scaling.md | 41 +-- status/raw/status-waku-usage.md | 9 +- vac/1/coss.md | 37 +- vac/2/mvds.md | 41 +-- vac/25/libp2p-dns-discovery.md | 20 +- vac/3/remote-log.md | 23 +- vac/32/rln-v1.md | 25 +- vac/4/mvds-meta.md | 23 +- vac/46/gossipsub-tor-push.md | 4 +- vac/48/rln-interep-spec.md | 4 +- vac/58/rln-v2.md | 11 +- vac/70/eth-secpm.md | 34 +- vac/raw/rln-stealth-commitments.md | 9 +- vac/template.md | 4 +- waku/deprecated/16/rpc.md | 16 +- waku/deprecated/18/swap.md | 14 +- waku/deprecated/5/waku0.md | 25 +- waku/informational/22/toy-chat.md | 9 +- waku/informational/23/topics.md | 21 +- waku/informational/27/peers.md | 6 +- waku/informational/29/config.md | 4 +- waku/informational/30/adaptive-nodes.md | 4 +- waku/standards/application/20/toy-eth-pm.md | 4 +- .../application/21/fault-tolerant-store.md | 4 +- waku/standards/application/26/payload.md | 4 +- waku/standards/application/53/x3dh.md | 25 +- .../standards/application/54/x3dh-sessions.md | 29 +- waku/standards/core/10/waku2.md | 31 +- waku/standards/core/11/relay.md | 21 +- waku/standards/core/12/filter.md | 23 +- .../core/12/previous-versions00/filter.md | 23 +- waku/standards/core/13/store.md | 27 +- waku/standards/core/14/message.md | 29 +- waku/standards/core/15/bridge.md | 4 +- waku/standards/core/17/rln-relay.md | 23 +- waku/standards/core/19/lightpush.md | 15 +- waku/standards/core/33/discv5.md | 24 +- waku/standards/core/36/bindings-api.md | 13 +- waku/standards/core/64/network.md | 321 ++++++++++++++++++ waku/standards/core/66/metadata.md | 4 +- waku/standards/legacy/6/waku1.md | 25 +- waku/standards/legacy/7/data.md | 15 +- waku/standards/legacy/8/mail.md | 19 +- waku/standards/legacy/9/rpc.md | 15 +- 55 files changed, 941 insertions(+), 550 deletions(-) create mode 100644 waku/standards/core/64/network.md diff --git a/docusaurus-utils/scrapper/markdown-convertor.mjs b/docusaurus-utils/scrapper/markdown-convertor.mjs index 1c60bd53d..a041865d3 100644 --- a/docusaurus-utils/scrapper/markdown-convertor.mjs +++ b/docusaurus-utils/scrapper/markdown-convertor.mjs @@ -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, '>') + 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; } diff --git a/nomos/38/claro.md b/nomos/38/claro.md index 39a300a2c..404853d76 100644 --- a/nomos/38/claro.md +++ b/nomos/38/claro.md @@ -3,18 +3,20 @@ title: 38/CONSENSUS-CLARO name: Claro Consensus Protocol status: raw category: Standards Track -editor: Corey Petty \ +editor: Corey Petty <corey@status.im> created: 01-JUL-2022 -revised: \<2022-08-26 Fri 13:11Z\> -uri: \ +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 \ -- 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: \ . -@prefix rdfs: \ . -@prefix xsd: \ . +@prefix rdf: . +@prefix rdfs: . +@prefix xsd: . -@prefix Claro \ . +@prefix Claro . Claro:query :holds ( @@ -605,36 +607,36 @@ they should be of stable interest no matter if Claro isn't. ## Informative References -0. [Logos](\) +0. [Logos](<https://logos.co/>) 1. [On BFT Consensus Evolution: From Monolithic to - DAG](\) + DAG](<https://dahliamalkhi.github.io/posts/2022/06/dag-bft/>) -2. [snow-ipfs](\) +2. [snow-ipfs](<https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV>) -3. [snow*](\) The Snow family of +3. [snow*](<https://www.avalabs.org/whitepapers>) The Snow family of algorithms -4. [Move](\) +4. [Move](<https://cloud.google.com/composer/docs/how-to/using/writing-dags>) Move: a Language for Writing DAG Abstractions -5. [rdf](\) +5. [rdf](<http://www.w3.org/1999/02/22-rdf-syntax-ns#>) -6. [rdfs](\) +6. [rdfs](<http://www.w3.org/2000/01/rdf-schema#>) -7. [xsd](\) +7. [xsd](<http://www.w3.org/2001/XMLSchema#>) -8. [n3-w3c-notes](\) +8. [n3-w3c-notes](<https://www.w3.org/TeamSubmission/n3/>) -9. [ntp](\) +9. [ntp](<https://www.ntp.org/downloads.html>) ## Normative References -0. [Claro](\) +0. [Claro](<https://rdf.logos.co/protocol/Claro/1/0/0/raw>) -1. [n3](\) +1. [n3](<https://www.w3.org/DesignIssues/Notation3.html>) -2. [json-ld](\) +2. [json-ld](<https://json-ld.org/>) ## Copyright diff --git a/status/24/curation.md b/status/24/curation.md index 0788848ba..d5bf3baa3 100644 --- a/status/24/curation.md +++ b/status/24/curation.md @@ -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 \ +editor: Szymon Szlachtowicz <szymon.s@ethworks.io> --- - Status: draft -- Editor: Szymon Szlachtowicz \ +- 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, diff --git a/status/28/featuring.md b/status/28/featuring.md index f08a830a7..2b024702b 100644 --- a/status/28/featuring.md +++ b/status/28/featuring.md @@ -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 \ +editor: Szymon Szlachtowicz <szymon.s@ethworks.io> --- - Status: draft -- Editor: Szymon Szlachtowicz \ +- Editor: Szymon Szlachtowicz <szymon.s@ethworks.io> ## Abstract This specification describes a voting method to feature different active Status Communities. diff --git a/status/55/1to1-chat.md b/status/55/1to1-chat.md index 7490293a8..f191ffef2 100644 --- a/status/55/1to1-chat.md +++ b/status/55/1to1-chat.md @@ -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 \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: -- Andrea Piana \ -- Pedro Pombeiro \ -- Corey Petty \ -- Oskar Thorén \ -- Dean Eigenmann \ +- 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 \ -- 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 diff --git a/status/56/communities.md b/status/56/communities.md index 76afb92a5..b8d856d73 100644 --- a/status/56/communities.md +++ b/status/56/communities.md @@ -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 \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: -- Andrea Piana \ +- Andrea Piana <andreap@status.im> --- - Status: draft - Category: Standards Track -- Editor: Aaryamann Challani \ -- 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\ images = 3; + map 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\ members = 1; + map 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\ members = 2; + map 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\ chats = 6; + map chats = 6; // A list of banned members repeated string ban_list = 7; // A mapping of categories to their details - map\ categories = 8; + map 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] } diff --git a/status/61/community-history-service.md b/status/61/community-history-service.md index 634f17b74..43948b202 100644 --- a/status/61/community-history-service.md +++ b/status/61/community-history-service.md @@ -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 \ +editor: r4bbit <r4bbit@status.im> contributors: - - Sanaz Taheri \ - - John Lea \ + - Sanaz Taheri <sanaz@status.im> + - John Lea <john@status.im> --- - Status: draft - Category: Standards Track -- Editor: r4bbit \ -- Contributors:: - - Sanaz Taheri \ - - John Lea \ +- 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\ archives = 1 + map archives = 1 } ``` diff --git a/status/62/payloads.md b/status/62/payloads.md index a17378f9f..6f56a8ac5 100644 --- a/status/62/payloads.md +++ b/status/62/payloads.md @@ -2,16 +2,20 @@ title: 62/STATUS-Payloads name: Status Message Payloads status: draft -editor: r4bbit \ +editor: r4bbit <r4bbit@status.im> contributors: -- Adam Babik \ -- Andrea Maria Piana \ -- Oskar Thoren \ -- Samuel Hawksby-Robinson \ +- 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 \ -- 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). - - 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\ 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\` | Image data associated with the chat key | +| 3 | images | `map` | 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\` | A list of links to social platforms | +| 8 | social_links | `array` | 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\ members = 2; + map<string,CommunityMember> members = 2; CommunityPermissions permissions = 3; ChatIdentity identity = 5; - map\ chats = 6; + map<string,CommunityChat> chats = 6; repeated string ban_list = 7; - map\ 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\ 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\` | The members of the community | +| 2| members | `map` | 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\` | A list of links to social platforms | +| 8 | social_links | `array` | 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\` | A list of accounts to reveal to the control node | +| 6 | revealed_accounts | `array` | 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\` | Updated link metadata | +| 8 | unfurled_links | `array` | 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\` | A list of revealed accounts | +| 3 | revealed_accounts | `array<RevealedAccount>` | A list of revealed accounts | ## Upgradability diff --git a/status/63/keycard-usage.md b/status/63/keycard-usage.md index 332f79dc8..b3bfe9bdb 100644 --- a/status/63/keycard-usage.md +++ b/status/63/keycard-usage.md @@ -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 \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: - - Jimmy Debe \ + - Jimmy Debe <jimmy@status.im> --- - Status: draft - Category: Standards Track -- Editor: Aaryamann Challani \ -- Contributors:: - - Jimmy Debe \ +- 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": \/\/\<256_bit_salt\> OR null + "pairing": //<256_bit_salt> OR null } ``` @@ -118,7 +119,7 @@ To establish a secure communication channel described [here](https://keycard.tec #### Response wire format ```json -"\/\/\<256_bit_salt\>" +"//<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": \/\/\<256_bit_salt\>, + "pairing": //<256_bit_salt>, "pin": 6_digit_pin } ``` @@ -162,7 +163,7 @@ To fetch the keys that are currently loaded on the keycard. ```json { - "pairing": \/\/\<256_bit_salt\>, + "pairing": //<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": \/\/\<256_bit_salt\>, + "pairing": //<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": \/\/\<256_bit_salt\>, + "pairing": //<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": \/\/\<256_bit_salt\> + "pairing": //<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": \/\/\<256_bit_salt\> + "pairing": //<256_bit_salt> } ``` diff --git a/status/65/account-address.md b/status/65/account-address.md index 2d488be11..72fb3e796 100644 --- a/status/65/account-address.md +++ b/status/65/account-address.md @@ -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 \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: -- Corey Petty \ -- Oskar Thorén \ -- Samuel Hawksby-Robinson \ +- 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 \ -- 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 diff --git a/status/71/push-notification-server.md b/status/71/push-notification-server.md index c6ae34a47..11720c5cd 100644 --- a/status/71/push-notification-server.md +++ b/status/71/push-notification-server.md @@ -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 \ +editor: Jimmy Debe <jimmy@status.im> contributors: - - Andrea Maria Piana \ + - Andrea Maria Piana <andreap@status.im> --- - Status: draft - Category: Standards Track -- Editor: Jimmy Debe \ -- Contributors:: - - Andrea Maria Piana \ +- 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:\
+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.\
-`device_token`: the actual push notification token sent by `Firebase` or `APN` and `FIREBASE_TOKEN` for firebase.\
-`installation_id`: the `installation_id` of the device.\
-`access_token`: the access token that will be given to clients to send push notifications.\
-`enabled`: whether the device wants to be sent push notifications.\
+`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.\
+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.\
-`blocked_chat_list`: a list of `SHA2-256` hashes of chat ids. Any chat id in this list will not trigger a notification.\
-`unregister`: whether the account should be unregistered.\
-`grant`: the grant for this specific server.\
-`allow_from_contacts_only`: whether the client only wants push notifications from contacts.\
-`apn_topic`: the APN topic for the push notification.\
-`block_mentions`: whether the client does not want to be notified on mentions.\
-`allowed_mentions_chat_list`: a list of SHA2-256 hashes of chat ids where we want to receive mentions.\
+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\
-`error`: the error type, if any\
-`request_id`: the `SHAKE-256` hash of the `signature` of the request\
-`preferences`: the server stored preferences in case of an error\
+`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\
-`installation_id`: the `installation_id` of the device associated with the `access_token`\
-`public_key`: the `SHAKE-256` of the public key associated with this `access_token` and `installation_id`.\
-`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.\
-`grant`: the grant used to register with this server.\
-`version`: the version of the registration on the server.\
-`server_public_key`: the compressed public key of the server.\
+`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`.\
-`message_id`: the message id of the `PushNotificationQueryInfo` the server is replying to.\
-`success`: whether the query was successful.\
+`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.\
-`chat_id`: the `SHAKE-256` of the `chat_id`.\
-`public_key`: the `SHAKE-256` of the compressed public key of the receiving client.\
-`installation_id`: the `installation_id` of the receiving client.\
-`message`: the encrypted message that is being notified on.\
-`type`: the type of the push notification, either `MESSAGE` or `MENTION`\
+`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\
+`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.\
+`message_id`: the `message_id` being notified on.<br /> `reports`: a list of `PushNotificationReport` #### PushNotificationReport: -`success`: whether the push notification was successful.\
-`error`: the type of the error in case of failure.\
-`public_key`: the public key of the user being notified.\
+`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 diff --git a/status/raw/simple-scaling.md b/status/raw/simple-scaling.md index 545ea5628..04dfeb22f 100644 --- a/status/raw/simple-scaling.md +++ b/status/raw/simple-scaling.md @@ -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 \ +editor: Daniel Kaiser <danielkaiser@status.im> contributors: -- Alvaro Revuelta \ +- Alvaro Revuelta <alrevuelta@status.im> --- - Status: raw - Category: Informational -- Editor: Daniel Kaiser \ -- 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/\/\` +`/waku/2/rs//` 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\ members = 2; + map 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\ chats = 6; + map chats = 6; // A list of banned members repeated string ban_list = 7; // A mapping of categories to their details - map\ categories = 8; + map 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. diff --git a/status/raw/status-waku-usage.md b/status/raw/status-waku-usage.md index 0ff2cce66..77d5e7764 100644 --- a/status/raw/status-waku-usage.md +++ b/status/raw/status-waku-usage.md @@ -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 \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: -- Jimmy Debe \ +- Jimmy Debe <jimmy@status.im> --- - Status: raw - Category: Best Current Practice -- Editor: Aaryamann Challani \ -- Contributors:: +- Editor: Aaryamann Challani <aaryamann@status.im> +- Contributors: + - Jimmy Debe <jimmy@status.im> ## Abstract diff --git a/vac/1/coss.md b/vac/1/coss.md index 616c611c8..452608cb0 100644 --- a/vac/1/coss.md +++ b/vac/1/coss.md @@ -3,25 +3,26 @@ title: 1/COSS name: Consensus-Oriented Specification System status: draft category: Best Current Practice -editor: Oskar Thoren \ +editor: Oskar Thoren <oskarth@titanproxy.com> contributors: - - Pieter Hintjens \ - - André Rebentisch \ - - Alberto Barrionuevo \ - - Chris Puttick \ - - Yurii Rashkovskii \ - - Daniel Kaiser \ + - 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 \ -- Contributors:: - - Pieter Hintjens \ - - André Rebentisch \ - - Alberto Barrionuevo \ - - Chris Puttick \ - - Yurii Rashkovskii \ - - Daniel Kaiser \ +- 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: - \/spec/\/\ + <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 \ | -| **contributors** | contributors | list | - Pieter Hintjens \\
- André Rebentisch \\
- Alberto Barrionuevo \\
- Chris Puttick \\
- Yurii Rashkovskii \ | +| **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 diff --git a/vac/2/mvds.md b/vac/2/mvds.md index ca4fefa0c..d83d20b89 100644 --- a/vac/2/mvds.md +++ b/vac/2/mvds.md @@ -2,16 +2,17 @@ title: 2/MVDS name: Minimum Viable Data Synchronization status: stable -editor: Sanaz Taheri \ +editor: Sanaz Taheri <sanaz@status.im> contributors: - - Dean Eigenmann \ - - Oskar Thorén \ + - Dean Eigenmann <dean@status.im> + - Oskar Thorén <oskarth@titanproxy.com> --- - Status: stable -- Editor: Sanaz Taheri \ -- Contributors:: - - Dean Eigenmann \ - - Oskar Thorén \ +- 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 /> Figure 1: Delivery without retransmissions in interactive mode. -\ +</p> #### Batch Mode @@ -117,14 +118,14 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT -\

- \ - \
+<p align="center"> + <img src="../assets/mvds/batch.png" /> + <br /> Figure 2: Delivery without retransmissions in batch mode. -\ +</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.* @@ -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+: \. +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]: \ +[^2]: <https://github.com/vacp2p/mvds> diff --git a/vac/25/libp2p-dns-discovery.md b/vac/25/libp2p-dns-discovery.md index 7c56f6a9b..a6fa7d8aa 100644 --- a/vac/25/libp2p-dns-discovery.md +++ b/vac/25/libp2p-dns-discovery.md @@ -2,11 +2,11 @@ title: 25/LIBP2P-DNS-DISCOVERY name: Libp2p Peer Discovery via DNS status: deleted -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: --- - Status: deleted -- Editor: Hanno Cornelius \ +- 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://\@\ +matree://@ ``` where - `matree` is the selected `multiaddr` Merkle tree scheme -- `\` is the fully qualified domain name on which the list can be found -- `\` is the base32 encoding of the compressed 32-byte binary public key that signed the list. +- `` is the fully qualified domain name on which the list can be found +- `` 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=\ l=\ seq=\ sig=\ +matree-root:v1 m= l= seq= sig= ``` where @@ -73,11 +73,11 @@ encoded as URL-safe base64 Branch entries MUST take the format: ``` -matree-branch:\,\,...,\ +matree-branch:,,..., ``` where -- `\,\,...,\` are the hashes of other subtree entries +- `,,...,` 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://\@\ +matree://@ ``` 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:\ +ma: ``` which contains the `multiaddr` of a `libp2p` peer. diff --git a/vac/3/remote-log.md b/vac/3/remote-log.md index 7ba12c2ba..f399092d8 100644 --- a/vac/3/remote-log.md +++ b/vac/3/remote-log.md @@ -2,14 +2,15 @@ title: 3/REMOTE-LOG name: Remote log specification status: draft -editor: Oskar Thorén \ +editor: Oskar Thorén <oskarth@titanproxy.com> contributors: - - Dean Eigenmann \ + - Dean Eigenmann <dean@status.im> --- - Status: draft -- Editor: Oskar Thorén \ -- Contributors:: - - Dean Eigenmann \ +- 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 { - + ## Synchronization @@ -157,11 +158,11 @@ The *remote log* protobuf is what is stored in the name system. -\

- \ - \
+<p align="center"> + <img src="./images/remote-log.png" /> + <br /> Figure 1: Remote log data synchronization. -\ +</p> @@ -243,4 +244,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## Footnotes -[^1]: \ +[^1]: <https://github.com/vacp2p/research/tree/master/remote_log> diff --git a/vac/32/rln-v1.md b/vac/32/rln-v1.md index 1744cf61e..451910cdb 100644 --- a/vac/32/rln-v1.md +++ b/vac/32/rln-v1.md @@ -2,17 +2,22 @@ title: 32/RLN-V1 name: Rate Limit Nullifier status: raw -editor: Rasul Ibragimov \ +editor: Rasul Ibragimov <curryrasul@gmail.com> contributors: -- Barry Whitehat \ -- Sanaz Taheri \ -- Oskar Thorén \ -- Onur Kilic \ -- Blagoj Dimovski \ +- 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 \ -- 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::\::new()); +let mut buffer = Cursor::new(Vec::::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::\::new()); +let mut out_buffer = Cursor::new(Vec::::new()); rln.generate_rln_proof(&mut in_buffer, &mut out_buffer) .unwrap(); // We get the public outputs returned by the circuit evaluation diff --git a/vac/4/mvds-meta.md b/vac/4/mvds-meta.md index 6b8c9453d..9c58d54a9 100644 --- a/vac/4/mvds-meta.md +++ b/vac/4/mvds-meta.md @@ -2,18 +2,19 @@ title: 4/MVDS-META name: MVDS Metadata Field status: draft -editor: Sanaz Taheri \ +editor: Sanaz Taheri <sanaz@status.im> contributors: - - Dean Eigenmann \ - - Andrea Maria Piana \ - - Oskar Thorén \ + - Dean Eigenmann <dean@status.im> + - Andrea Maria Piana <andreap@status.im> + - Oskar Thorén <oskarth@titanproxy.com> --- - Status: draft -- Editor: Sanaz Taheri \ -- Contributors:: - - Dean Eigenmann \ - - Andrea Maria Piana \ - - Oskar Thorén \ +- 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]: \ +[^2]: <https://en.wikipedia.org/wiki/Directed_acyclic_graph> [^3]: Jepsen. [Causal Consistency](https://jepsen.io/consistency/models/causal). Jepsen, LLC. -[^4]: \ +[^4]: <https://en.wikipedia.org/wiki/Eventual_consistency> diff --git a/vac/46/gossipsub-tor-push.md b/vac/46/gossipsub-tor-push.md index dfd92d9b8..f9e33afc4 100644 --- a/vac/46/gossipsub-tor-push.md +++ b/vac/46/gossipsub-tor-push.md @@ -3,12 +3,12 @@ title: 46/GOSSIPSUB-TOR-PUSH name: Gossipsub Tor Push status: raw category: Standards Track -editor: Daniel Kaiser \ +editor: Daniel Kaiser <danielkaiser@status.im> contributors: --- - Status: raw - Category: Standards Track -- Editor: Daniel Kaiser \ +- Editor: Daniel Kaiser <danielkaiser@status.im> ## Abstract diff --git a/vac/48/rln-interep-spec.md b/vac/48/rln-interep-spec.md index a9735f7cc..ee5285c35 100644 --- a/vac/48/rln-interep-spec.md +++ b/vac/48/rln-interep-spec.md @@ -3,12 +3,12 @@ title: 48/RLN-INTEREP-SPEC name: Interep as group management for RLN status: raw category: -editor: Aaryamann Challani \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: --- - Status: raw - Category: -- Editor: Aaryamann Challani \ +- Editor: Aaryamann Challani <aaryamann@status.im> ## Abstract diff --git a/vac/58/rln-v2.md b/vac/58/rln-v2.md index a8e4590bc..67975ea52 100644 --- a/vac/58/rln-v2.md +++ b/vac/58/rln-v2.md @@ -2,13 +2,14 @@ title: 58/RLN-V2 name: Rate Limit Nullifier V2 status: raw -editor: Rasul Ibragimov \ +editor: Rasul Ibragimov <curryrasul@gmail.com> contributors: -- Lev Soukhanov \<0xdeadfae@gmail.com\> +- Lev Soukhanov <0xdeadfae@gmail.com> --- - Status: raw -- Editor: Rasul Ibragimov \ -- 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. diff --git a/vac/70/eth-secpm.md b/vac/70/eth-secpm.md index a1dcc48a3..e6329ebbe 100644 --- a/vac/70/eth-secpm.md +++ b/vac/70/eth-secpm.md @@ -3,12 +3,12 @@ title: 70/ETH-SECPM name: Secure channel setup using Ethereum accounts status: raw category: Standards Track -editor: Ramses Fernandez \ +editor: Ramses Fernandez <ramses@status.im> contributors: --- - Status: raw - Category: Standards Track -- Editor: Ramses Fernandez \ +- 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\; - opaque context\; + opaque label; + opaque context; } 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\; +opaque group_id; uint64 epoch; -opaque tree_hash\; -opaque confirmed_trasncript_hash\; -Extension extension\; +opaque tree_hash; +opaque confirmed_trasncript_hash; +Extension extension; } GroupContext; ``` @@ -435,9 +435,9 @@ ProtocolVersion version; CipherSuite cipher_suite; HPKEPublicKey init_key; LeafNode leaf_node; -Extension extensions\; +Extension extensions; /* SignWithLabel(., "KeyPackageTBS", KeyPackageTBS) */ -opaque signature\; +opaque signature; } ``` ``` @@ -446,7 +446,7 @@ ProtocolVersion version; CipheSuite cipher_suite; HPKEPublicKey init_key; LeafNode leaf_node; -Extension extensions\; +Extension extensions; } ``` `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\; -ProposalType proposal_types\; -CredentialType credential_types\; +ExtensionType extension_types; +ProposalType proposal_types; +CredentialType credential_types; } ``` diff --git a/vac/raw/rln-stealth-commitments.md b/vac/raw/rln-stealth-commitments.md index ed10eb293..d37629b3f 100644 --- a/vac/raw/rln-stealth-commitments.md +++ b/vac/raw/rln-stealth-commitments.md @@ -2,13 +2,14 @@ title: RLN-STEALTH-COMMITMENTS name: RLN Stealth Commitment Usage category: Standards Track -editor: Aaryamann Challani \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: -- Jimmy Debe \ +- Jimmy Debe <jimmy@status.im> --- - Category: Standards Track -- Editor: Aaryamann Challani \ -- Contributors:: +- Editor: Aaryamann Challani <aaryamann@status.im> +- Contributors: + - Jimmy Debe <jimmy@status.im> ## Abstract diff --git a/vac/template.md b/vac/template.md index 04418b3ff..b23a44bea 100644 --- a/vac/template.md +++ b/vac/template.md @@ -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 \ +editor: Daniel Kaiser <danielkaiser@status.im> contributors: --- - Status: (raw|draft|stable) - Category: (Standards Track|Informational|Best Current Practice) -- Editor: Daniel Kaiser \ +- Editor: Daniel Kaiser <danielkaiser@status.im> # (Info, remove this section) diff --git a/waku/deprecated/16/rpc.md b/waku/deprecated/16/rpc.md index 990f1a5a8..5f715689f 100644 --- a/waku/deprecated/16/rpc.md +++ b/waku/deprecated/16/rpc.md @@ -2,10 +2,10 @@ title: 16/WAKU2-RPC name: Waku v2 RPC API status: deprecated -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> --- - Status: deprecated -- Editor: Hanno Cornelius \ +- 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 `\_waku_\_\_\_\` +The JSON-RPC methods in this document are designed to be mappable to HTTP REST endpoints. Method names follow the pattern `_waku____` -- `\`: 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`. -- `\`: Waku version. Currently **v2**. -- `\`: one of the listed APIs below, e.g. `store`, `debug`, or `relay`. -- `\`: API definition version. Currently **v1** for all APIs. -- `\`: the resource or resource path being addressed +- ``: 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`. +- ``: Waku version. Currently **v2**. +- ``: one of the listed APIs below, e.g. `store`, `debug`, or `relay`. +- ``: API definition version. Currently **v1** for all APIs. +- ``: 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`. diff --git a/waku/deprecated/18/swap.md b/waku/deprecated/18/swap.md index fd5d7e4d1..2dc396207 100644 --- a/waku/deprecated/18/swap.md +++ b/waku/deprecated/18/swap.md @@ -2,11 +2,11 @@ title: 18/WAKU2-SWAP name: Waku SWAP Accounting status: deprecated -editor: Oskar Thorén \ -contributor: Ebube Ud \ +editor: Oskar Thorén <oskarth@titanproxy.com> +contributor: Ebube Ud <ebube@status.im> --- - Status: deprecated -- Editor: Oskar Thorén \ +- 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. diff --git a/waku/deprecated/5/waku0.md b/waku/deprecated/5/waku0.md index 8d7d4340c..43544141f 100644 --- a/waku/deprecated/5/waku0.md +++ b/waku/deprecated/5/waku0.md @@ -2,20 +2,21 @@ title: 5/WAKU0 name: Waku v0 status: deprecated -editor: Oskar Thorén \ +editor: Oskar Thorén <oskarth@titanproxy.com> contributors: - - Adam Babik \ - - Andrea Maria Piana \ - - Dean Eigenmann \ - - Kim De Mey \ + - 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 \ -- Contributors:: - - Adam Babik \ - - Andrea Maria Piana \ - - Dean Eigenmann \ - - Kim De Mey \ +- 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 diff --git a/waku/informational/22/toy-chat.md b/waku/informational/22/toy-chat.md index ef7e5b43c..c45926235 100644 --- a/waku/informational/22/toy-chat.md +++ b/waku/informational/22/toy-chat.md @@ -2,13 +2,14 @@ title: 22/TOY-CHAT name: Waku v2 Toy Chat status: draft -editor: Franck Royer \ +editor: Franck Royer <franck@status.im> contributors: - - Hanno Cornelius \ + - Hanno Cornelius <hanno@status.im> --- - Status: draft -- Editor: Franck Royer \ -- Contributors:: +- Editor: Franck Royer <franck@status.im> +- Contributors: + - Hanno Cornelius <hanno@status.im> **Content Topic**: `/toy-chat/2/huilong/proto`. diff --git a/waku/informational/23/topics.md b/waku/informational/23/topics.md index 2fac7f928..c754bfc6f 100644 --- a/waku/informational/23/topics.md +++ b/waku/informational/23/topics.md @@ -3,17 +3,18 @@ title: 23/WAKU2-TOPICS name: Waku v2 Topic Usage Recommendations status: draft category: Informational -editor: Oskar Thoren \ +editor: Oskar Thoren <oskarth@titanproxy.com> contributors: - - Hanno Cornelius \ - - Daniel Kaiser \ + - Hanno Cornelius <hanno@status.im> + - Daniel Kaiser <danielkaiser@status.im> --- - Status: draft - Category: Informational -- Editor: Oskar Thoren \ -- Contributors:: - - Hanno Cornelius \ - - Daniel Kaiser \ +- 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. diff --git a/waku/informational/27/peers.md b/waku/informational/27/peers.md index 132e49f1f..8825e1393 100644 --- a/waku/informational/27/peers.md +++ b/waku/informational/27/peers.md @@ -2,11 +2,11 @@ title: 27/WAKU2-PEERS name: Waku v2 Client Peer Management Recommendations status: draft -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: --- - Status: draft -- Editor: Hanno Cornelius \ +- 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 diff --git a/waku/informational/29/config.md b/waku/informational/29/config.md index c47a85b24..b643dec81 100644 --- a/waku/informational/29/config.md +++ b/waku/informational/29/config.md @@ -2,11 +2,11 @@ title: 29/WAKU2-CONFIG name: Waku v2 Client Parameter Configuration Recommendations status: draft -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: --- - Status: draft -- Editor: Hanno Cornelius \ +- 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), diff --git a/waku/informational/30/adaptive-nodes.md b/waku/informational/30/adaptive-nodes.md index 7c73e03c3..2566a8170 100644 --- a/waku/informational/30/adaptive-nodes.md +++ b/waku/informational/30/adaptive-nodes.md @@ -2,11 +2,11 @@ title: 30/ADAPTIVE-NODES name: Adaptive nodes status: draft -editor: Oskar Thorén \ +editor: Oskar Thorén <oskarth@titanproxy.com> contributors: --- - Status: draft -- Editor: Oskar Thorén \ +- Editor: Oskar Thorén <oskarth@titanproxy.com> This is an informational spec that show cases the concept of adaptive nodes. diff --git a/waku/standards/application/20/toy-eth-pm.md b/waku/standards/application/20/toy-eth-pm.md index b52fc0634..0c7a04283 100644 --- a/waku/standards/application/20/toy-eth-pm.md +++ b/waku/standards/application/20/toy-eth-pm.md @@ -2,11 +2,11 @@ title: 20/TOY-ETH-PM name: Toy Ethereum Private Message status: draft -editor: Franck Royer \ +editor: Franck Royer <franck@status.im> contributors: --- - Status: draft -- Editor: Franck Royer \ +- Editor: Franck Royer <franck@status.im> **Content Topics**: diff --git a/waku/standards/application/21/fault-tolerant-store.md b/waku/standards/application/21/fault-tolerant-store.md index f4a6871cf..4b3344cda 100644 --- a/waku/standards/application/21/fault-tolerant-store.md +++ b/waku/standards/application/21/fault-tolerant-store.md @@ -2,11 +2,11 @@ title: 21/WAKU2-FAULT-TOLERANT-STORE name: Waku v2 Fault-Tolerant Store status: draft -editor: Sanaz Taheri \ +editor: Sanaz Taheri <sanaz@status.im> contributors: --- - Status: draft -- Editor: Sanaz Taheri \ +- 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. diff --git a/waku/standards/application/26/payload.md b/waku/standards/application/26/payload.md index ebf86ef66..d66b1cbc7 100644 --- a/waku/standards/application/26/payload.md +++ b/waku/standards/application/26/payload.md @@ -2,11 +2,11 @@ title: 26/WAKU2-PAYLOAD name: Waku Message Payload Encryption status: draft -editor: Oskar Thoren \ +editor: Oskar Thoren <oskarth@titanproxy.com> contributors: --- - Status: draft -- Editor: Oskar Thoren \ +- 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). diff --git a/waku/standards/application/53/x3dh.md b/waku/standards/application/53/x3dh.md index b81125e91..1315bcd8c 100644 --- a/waku/standards/application/53/x3dh.md +++ b/waku/standards/application/53/x3dh.md @@ -3,18 +3,23 @@ title: 53/WAKU2-X3DH name: X3DH usage for Waku payload encryption status: draft category: Standards Track -editor: Aaryamann Challani \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: -- Andrea Piana \ -- Pedro Pombeiro \ -- Corey Petty \ -- Oskar Thorén \ -- Dean Eigenmann \ +- 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 \ -- 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\ signed_pre_keys = 2; + map 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\ direct_message = 101; + map direct_message = 101; // Public message, not encrypted bytes public_message = 102; } diff --git a/waku/standards/application/54/x3dh-sessions.md b/waku/standards/application/54/x3dh-sessions.md index f00d7732a..0c6b79a4c 100644 --- a/waku/standards/application/54/x3dh-sessions.md +++ b/waku/standards/application/54/x3dh-sessions.md @@ -3,18 +3,23 @@ title: 54/WAKU2-X3DH-SESSIONS name: Session management for Waku X3DH status: draft category: Standards Track -editor: Aaryamann Challani \ +editor: Aaryamann Challani <aaryamann@status.im> contributors: -- Andrea Piana \ -- Pedro Pombeiro \ -- Corey Petty \ -- Oskar Thorén \ -- Dean Eigenmann \ +- 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 \ -- 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] } ``` diff --git a/waku/standards/core/10/waku2.md b/waku/standards/core/10/waku2.md index 841623dc2..84114d1cf 100644 --- a/waku/standards/core/10/waku2.md +++ b/waku/standards/core/10/waku2.md @@ -2,22 +2,23 @@ title: 10/WAKU2 name: Waku v2 status: draft -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: - - Sanaz Taheri \ - - Hanno Cornelius \ - - Reeshav Khan \ - - Daniel Kaiser \ - - Oskar Thorén \ + - 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 \ -- Contributors:: - - Sanaz Taheri \ - - Hanno Cornelius \ - - Reeshav Khan \ - - Daniel Kaiser \ - - Oskar Thorén \ +- 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. - - - - ## Appendix C: Implementation Notes ### Implementation Matrix diff --git a/waku/standards/core/11/relay.md b/waku/standards/core/11/relay.md index d3735fb6d..34e00f0da 100644 --- a/waku/standards/core/11/relay.md +++ b/waku/standards/core/11/relay.md @@ -2,16 +2,17 @@ title: 11/WAKU2-RELAY name: Waku v2 Relay status: stable -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: - - Oskar Thorén \ - - Sanaz Taheri \ + - Oskar Thorén <oskarth@titanproxy.com> + - Sanaz Taheri <sanaz@status.im> --- - Status: stable -- Editor: Hanno Cornelius \ -- Contributors:: - - Oskar Thorén \ - - Sanaz Taheri \ +- 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 diff --git a/waku/standards/core/12/filter.md b/waku/standards/core/12/filter.md index 10ef80418..1140e7348 100644 --- a/waku/standards/core/12/filter.md +++ b/waku/standards/core/12/filter.md @@ -3,21 +3,20 @@ title: 12/WAKU2-FILTER name: Waku v2 Filter status: draft version: 01 -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: - - Dean Eigenmann \ - - Oskar Thorén \ - - Sanaz Taheri \ - - Ebube Ud \ + - 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 \ -- Contributors:: - - Dean Eigenmann \ - - Oskar Thorén \ - - Sanaz Taheri \ - - Ebube Ud \ -- 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) diff --git a/waku/standards/core/12/previous-versions00/filter.md b/waku/standards/core/12/previous-versions00/filter.md index 642f0a73f..a5dd24d7c 100644 --- a/waku/standards/core/12/previous-versions00/filter.md +++ b/waku/standards/core/12/previous-versions00/filter.md @@ -2,21 +2,20 @@ title: 12/WAKU2-FILTER name: Waku v2 Filter status: draft -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: - - Dean Eigenmann \ - - Oskar Thorén \ - - Sanaz Taheri \ - - Ebube Ud \ + - 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 \ -- Contributors:: - - Dean Eigenmann \ - - Oskar Thorén \ - - Sanaz Taheri \ - - Ebube Ud \ -- 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 diff --git a/waku/standards/core/13/store.md b/waku/standards/core/13/store.md index c7ad6498f..f0ef76c53 100644 --- a/waku/standards/core/13/store.md +++ b/waku/standards/core/13/store.md @@ -2,22 +2,23 @@ title: 13/WAKU2-STORE name: Waku v2 Store status: draft -editor: Simon-Pierre Vivier \ +editor: Simon-Pierre Vivier <simvivier@status.im> contributors: - - Dean Eigenmann \ - - Oskar Thorén \ - - Aaryamann Challani \ - - Sanaz Taheri \ - - Hanno Cornelius \ + - 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 \ -- Contributors:: - - Dean Eigenmann \ - - Oskar Thorén \ - - Aaryamann Challani \ - - Sanaz Taheri \ - - Hanno Cornelius \ +- 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 diff --git a/waku/standards/core/14/message.md b/waku/standards/core/14/message.md index ff99fa5f0..012aa6e1c 100644 --- a/waku/standards/core/14/message.md +++ b/waku/standards/core/14/message.md @@ -3,23 +3,24 @@ title: 14/WAKU2-MESSAGE name: Waku v2 Message status: draft category: Standards Track -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: - - Sanaz Taheri \ - - Aaryamann Challani \ - - Lorenzo Delgado \ - - Abhimanyu Rawat \ - - Oskar Thorén \ + - 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 \ -- Contributors:: - - Sanaz Taheri \ - - Aaryamann Challani \ - - Lorenzo Delgado \ - - Abhimanyu Rawat \ - - Oskar Thorén \ +- 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 = \ +message.meta = message.timestamp = 0x175789bfa23f8400 message_hash = 0xa2554498b31f5bcdfcbf7fa58ad1c2d45f0254f3f8110a85588ec3cf10720fd8 diff --git a/waku/standards/core/15/bridge.md b/waku/standards/core/15/bridge.md index 286f5a555..b0c62ab3d 100644 --- a/waku/standards/core/15/bridge.md +++ b/waku/standards/core/15/bridge.md @@ -2,10 +2,10 @@ title: 15/WAKU-BRIDGE name: Waku Bridge status: draft -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> --- - Status: draft -- Editor: Hanno Cornelius \ +- Editor: Hanno Cornelius <hanno@status.im> A bridge between Waku v1 and Waku v2. diff --git a/waku/standards/core/17/rln-relay.md b/waku/standards/core/17/rln-relay.md index 48834bc2c..f0237c482 100644 --- a/waku/standards/core/17/rln-relay.md +++ b/waku/standards/core/17/rln-relay.md @@ -2,20 +2,21 @@ title: 17/WAKU2-RLN-RELAY name: Waku v2 RLN Relay status: draft -editor: Alvaro Revuelta \ +editor: Alvaro Revuelta <alvaro@status.im> contributors: - - Oskar Thorén \ - - Aaryamann Challani \ - - Sanaz Taheri \ - - Hanno Cornelius \ + - 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 \ -- Contributors:: - - Oskar Thorén \ - - Aaryamann Challani \ - - Sanaz Taheri \ - - Hanno Cornelius \ +- 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). diff --git a/waku/standards/core/19/lightpush.md b/waku/standards/core/19/lightpush.md index a85e7b5ac..c6fbc718f 100644 --- a/waku/standards/core/19/lightpush.md +++ b/waku/standards/core/19/lightpush.md @@ -2,16 +2,17 @@ title: 19/WAKU2-LIGHTPUSH name: Waku v2 Light Push status: draft -editor: Hanno Cornelius \ +editor: Hanno Cornelius <hanno@status.im> contributors: - - Daniel Kaiser \ - - Oskar Thorén \ + - Daniel Kaiser <danielkaiser@status.im> + - Oskar Thorén <oskarth@titanproxy.com> --- - Status: draft -- Editor: Hanno Cornelius \ -- Contributors:: - - Daniel Kaiser \ - - Oskar Thorén \ +- 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` diff --git a/waku/standards/core/33/discv5.md b/waku/standards/core/33/discv5.md index 13eb102df..0579a808b 100644 --- a/waku/standards/core/33/discv5.md +++ b/waku/standards/core/33/discv5.md @@ -2,11 +2,11 @@ title: 33/WAKU2-DISCV5 name: Waku v2 Discv5 Ambient Peer Discovery status: draft -editor: Daniel Kaiser \ +editor: Daniel Kaiser <danielkaiser@status.im> contributors: --- - Status: draft -- Editor: Daniel Kaiser \ +- 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> header = static-header || authdata static-header = protocol-id || version || flag || nonce || authdata-size -protocol-id = \"discv5"\ +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> `33/WAKU2-DISCV5`: -\ -kcode\> +<pre> +kcode> header = static-header || authdata static-header = protocol-id || version || flag || nonce || authdata-size -protocol-id = \"d5waku"\ +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> ## Suggestions for Implementations diff --git a/waku/standards/core/36/bindings-api.md b/waku/standards/core/36/bindings-api.md index 76b84347b..a3b79adaf 100644 --- a/waku/standards/core/36/bindings-api.md +++ b/waku/standards/core/36/bindings-api.md @@ -2,13 +2,14 @@ title: 36/WAKU2-BINDINGS-API name: Waku v2 C Bindings API status: draft -editor: Richard Ramos \ +editor: Richard Ramos <richard@status.im> contributors: -- Franck Royer \ +- Franck Royer <franck@status.im> --- - Status: draft -- Editor: Richard Ramos \ -- 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\; + relayTopics?: Array; gossipsubParameters?: GossipSubParameters; minPeersToPublish?: number legacyFilter?: boolean; discV5?: boolean; - discV5BootstrapNodes?: Array\; + discV5BootstrapNodes?: Array; discV5UDPPort?: number; store?: boolean; databaseURL?: string; diff --git a/waku/standards/core/64/network.md b/waku/standards/core/64/network.md new file mode 100644 index 000000000..a36b53d5f --- /dev/null +++ b/waku/standards/core/64/network.md @@ -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: +* `` set to `1` +* `` 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 `` 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 ``. +* [WAKU-METADATA](https://github.com/waku-org/specs/blob/master/standards/core/metadata) reports a `` 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) +* diff --git a/waku/standards/core/66/metadata.md b/waku/standards/core/66/metadata.md index 2959c014a..cd3c79d7c 100644 --- a/waku/standards/core/66/metadata.md +++ b/waku/standards/core/66/metadata.md @@ -2,11 +2,11 @@ title: 66/WAKU2-METADATA name: Waku Metadata Protocol status: draft -editor: Alvaro Revuelta \ +editor: Alvaro Revuelta <alrevuelta@status.im> contributors: --- - Status: draft -- Editor: Alvaro Revuelta \ +- Editor: Alvaro Revuelta <alrevuelta@status.im> ## Abstract This specification describes the metadata that can be associated with a [10/WAKU2](../10/waku2) node. diff --git a/waku/standards/legacy/6/waku1.md b/waku/standards/legacy/6/waku1.md index e8e137c2c..fe7fd86ea 100644 --- a/waku/standards/legacy/6/waku1.md +++ b/waku/standards/legacy/6/waku1.md @@ -2,20 +2,21 @@ title: 6/WAKU1 name: Waku v1 status: stable -editor: Oskar Thorén \ +editor: Oskar Thorén <oskarth@titanproxy.com> contributors: - - Adam Babik \ - - Andrea Maria Piana \ - - Dean Eigenmann \ - - Kim De Mey \ + - 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 \ -- Contributors:: - - Adam Babik \ - - Andrea Maria Piana \ - - Dean Eigenmann \ - - Kim De Mey \ +- 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 diff --git a/waku/standards/legacy/7/data.md b/waku/standards/legacy/7/data.md index 7b71b48fb..efe4abe7f 100644 --- a/waku/standards/legacy/7/data.md +++ b/waku/standards/legacy/7/data.md @@ -2,16 +2,17 @@ title: 7/WAKU-DATA name: Waku Envelope data field status: stable -editor: Oskar Thorén \ +editor: Oskar Thorén <oskarth@titanproxy.com> contributors: - - Dean Eigenmann \ - - Kim De Mey \ + - Dean Eigenmann <dean@status.im> + - Kim De Mey <kimdemey@status.im> --- - Status: stable -- Editor: Oskar Thorén \ -- Contributors:: - - Dean Eigenmann \ - - Kim De Mey \ +- 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). diff --git a/waku/standards/legacy/8/mail.md b/waku/standards/legacy/8/mail.md index cde591d9d..fbfecbc8b 100644 --- a/waku/standards/legacy/8/mail.md +++ b/waku/standards/legacy/8/mail.md @@ -2,18 +2,19 @@ title: 8/WAKU-MAIL name: Waku Mailserver status: stable -editor: Andrea Maria Piana \ +editor: Andrea Maria Piana <andreap@status.im> contributors: - - Adam Babik \ - - Dean Eigenmann \ - - Oskar Thorén \ + - Adam Babik <adam@status.im> + - Dean Eigenmann <dean@status.im> + - Oskar Thorén <oskarth@titanproxy.com> --- - Status: stable -- Editor: Andrea Maria Piana \ -- Contributors:: - - Adam Babik \ - - Dean Eigenmann \ - - Oskar Thorén \ +- 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 diff --git a/waku/standards/legacy/9/rpc.md b/waku/standards/legacy/9/rpc.md index 353cbaf9c..b7c6c5d1e 100644 --- a/waku/standards/legacy/9/rpc.md +++ b/waku/standards/legacy/9/rpc.md @@ -2,16 +2,17 @@ title: 9/WAKU-RPC name: Waku RPC API status: stable -editor: Andrea Maria Piana \ +editor: Andrea Maria Piana <andreap@status.im> contributors: - - Dean Eigenmann \ - - Oskar Thorén \ + - Dean Eigenmann <dean@status.im> + - Oskar Thorén <oskarth@titanproxy.com> --- - Status: stable -- Editor: Andrea Maria Piana \ -- Contributors:: - - Dean Eigenmann \ - - Oskar Thorén \ +- 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. From 482361674d4bc2ba5f38ce76fc0231cb96e76b89 Mon Sep 17 00:00:00 2001 From: Filip Pajic Date: Wed, 15 May 2024 09:54:06 +0200 Subject: [PATCH 5/5] fix: reorder home page links --- docs/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/index.md b/docs/index.md index 8e6940abc..3b8998d6c 100644 --- a/docs/index.md +++ b/docs/index.md @@ -4,10 +4,10 @@ title: Vac RFCs description: Codex is building a decentralised durability storage engine --- -- [Status](/status) - - [Vac](/vac) +- [Status](/status) + - [Waku](/waku) - [Codex](/codex)