From e231486568cb1ca29ad48f08f9eb544dc217a563 Mon Sep 17 00:00:00 2001 From: jinhojang6 Date: Wed, 17 Apr 2024 21:21:27 +0900 Subject: [PATCH] fix: handle unescaped comments and update content --- fetch-content.js | 6 + nomos/claro.md | 6 +- status/1to1-chat.md | 2 +- status/71/images/notification.png | Bin 106806 -> 106799 bytes status/account-address.md | 2 +- status/communities.md | 8 +- status/keycard-usage.md | 2 +- status/payloads.md | 2 +- vac/mvds.md | 4 +- vac/remote-log.md | 24 +- vac/rln-stealth-commitments.md | 110 +++ waku/README.md | 2 +- waku/deprecated/README.md | 2 +- waku/deprecated/rpc.md | 640 ++++++++++++++++++ .../30/images/adaptive_node_continuum.jpg | Bin 1163627 -> 1163640 bytes .../30/images/adaptive_node_continuum2.png | Bin 86559 -> 86556 bytes .../30/images/adaptive_node_cross_section.jpg | Bin 736191 -> 736195 bytes .../images/adaptive_node_cross_section2.png | Bin 145793 -> 145805 bytes ...ptive_node_network_topology_protocols2.png | Bin 177081 -> 177101 bytes ...node_network_topology_protocols_legend.png | Bin 94822 -> 94834 bytes .../adaptive_node_protocol_selection2.png | Bin 96389 -> 96393 bytes .../30/images/adaptive_protocol_selection.jpg | Bin 1085793 -> 1085792 bytes waku/standards/application/swap.md | 4 +- waku/standards/core/10/images/overview.png | Bin 132354 -> 132357 bytes waku/standards/core/12/filter.md | 4 +- .../17/images/rln-message-verification.png | Bin 220372 -> 220391 bytes waku/standards/core/17/images/rln-relay.png | Bin 170288 -> 170280 bytes waku/standards/core/filter.md | 4 +- waku/standards/core/relay.md | 14 +- waku/standards/core/rln-relay.md | 12 +- waku/standards/core/store.md | 6 +- waku/standards/core/waku2.md | 4 +- 32 files changed, 807 insertions(+), 51 deletions(-) create mode 100644 vac/rln-stealth-commitments.md create mode 100644 waku/deprecated/rpc.md diff --git a/fetch-content.js b/fetch-content.js index 0a9b958..1b3f80b 100644 --- a/fetch-content.js +++ b/fetch-content.js @@ -180,6 +180,10 @@ function parseSlugFromFrontmatter(content) { return 1 // Return null if not found } +function unescapeHtmlComments(htmlString) { + return htmlString.replace(/\\<\!--/g, '') +} + async function downloadAndSaveFile(url, filePath) { https .get(url, res => { @@ -218,6 +222,8 @@ async function downloadAndSaveFile(url, filePath) { // Replace empty Markdown links with placeholder URL content = content.replace(/\[([^\]]+)\]\(\)/g, '[$1](#)') + content = unescapeHtmlComments(content) + // // parse sidebarPosition from the slug in the frontmatter const sidebarPosition = parseSlugFromFrontmatter(content) || 1 diff --git a/nomos/claro.md b/nomos/claro.md index 267bcc8..c275a4c 100644 --- a/nomos/claro.md +++ b/nomos/claro.md @@ -123,8 +123,8 @@ The algorithm is divided into 4 phases: 3. Transition function 4. Opinion and Decision -\ + ### Setup Parameters diff --git a/status/1to1-chat.md b/status/1to1-chat.md index 80914c2..a709828 100644 --- a/status/1to1-chat.md +++ b/status/1to1-chat.md @@ -145,7 +145,7 @@ message MembershipUpdateEvent { } } ``` -\ Note that the definitions for `ChatMessage` and `EmojiReaction` can be found in [chat_message.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/chat_message.proto#L1) and [emoji_reaction.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/emoji_reaction.proto). ##### Chat Created diff --git a/status/71/images/notification.png b/status/71/images/notification.png index 93cec1a3c41afebffc1085bf391045de824e13b4..961fdee506320d52f18fa36c44ac1dc9ff91fc31 100644 GIT binary patch delta 30 mcmdmXh;98LwuUW?DMn03=55b1V%)*W{ATXf?HV?We5nA*+6)Q+ delta 37 lcmZ2~h;7>;wuUW?DMoDX_wNOw?P*4gJ2+t+MH@!GQ~+YI5)uFa diff --git a/status/account-address.md b/status/account-address.md index eeae36b..d98e9d4 100644 --- a/status/account-address.md +++ b/status/account-address.md @@ -56,7 +56,7 @@ The Status node verifies or derives everything else associated with the contact ### User Profile Picture - An account MAY edit the `IK` generated identicon with a chosen picture. This picture will become part of the publicly broadcasted profile of the account. -\ ## Wire Format diff --git a/status/communities.md b/status/communities.md index 92e57ce..4db3310 100644 --- a/status/communities.md +++ b/status/communities.md @@ -74,12 +74,12 @@ The following cryptographic primitives are used in the design - ## Wire format -\ ```protobuf syntax = "proto3"; @@ -317,7 +317,7 @@ contentTopic = "/waku/1/0x" + topic + "/rfc26" #### Community channels/chats The unique identifier for a community channel/chat is the chat id. -\ The content topic that Community channels/chats use MUST be the hex-encoded keccak-256 hash of the public key of the community concatenated with the chat id. ``` @@ -365,7 +365,7 @@ The flows for Community management are as described below. 1. The Community owner generates a public/private key pair. 2. The Community owner configures the Community metadata, according to the wire format "CommunityDescription". 3. The Community owner publishes the Community metadata on a content topic derived from the public key of the Community. -the Community metadata SHOULD be encrypted with the public key of the Community. \ The Community metadata MAY be sent during fixed intervals, to ensure that the Community metadata is available to members. The Community metadata SHOULD be sent every time the Community metadata is updated. 4. The Community owner MAY advertise the Community out of band, by sharing the public key of the Community on other mediums of communication. diff --git a/status/keycard-usage.md b/status/keycard-usage.md index ecc6abb..d9be8b6 100644 --- a/status/keycard-usage.md +++ b/status/keycard-usage.md @@ -248,7 +248,7 @@ To verify the pin of the keycard. Status code reference: - 3: PIN is valid -\ ### 9. Change the pin (`/change-pin`) diff --git a/status/payloads.md b/status/payloads.md index 2ed3c5f..6dd18f7 100644 --- a/status/payloads.md +++ b/status/payloads.md @@ -286,7 +286,7 @@ 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.md). -\ The following messages types MUST be supported: diff --git a/vac/mvds.md b/vac/mvds.md index c6bccc5..172b889 100644 --- a/vac/mvds.md +++ b/vac/mvds.md @@ -114,7 +114,7 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT 3. When a node receives an `ACK`, the `MESSAGE` is removed from the state for the given peer. 4. All records that require retransmission are added to the payload, given `Send Epoch` has been reached. -\ \

\ @@ -125,7 +125,7 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT \> ***NOTE:** Batch mode is higher bandwidth whereas interactive mode is higher latency.* -\ ### Retransmission diff --git a/vac/remote-log.md b/vac/remote-log.md index 44616b2..d3b1c7f 100644 --- a/vac/remote-log.md +++ b/vac/remote-log.md @@ -33,7 +33,7 @@ content addressed storage, or the name system. It is assumed these capabilities are abstracted away in such a way that any such protocol can easily be implemented. -\ ### Payloads @@ -60,7 +60,7 @@ message Content { } ``` -\ **NS service**: @@ -92,8 +92,8 @@ message Response { } ``` -\ + **Remote log:** @@ -114,9 +114,9 @@ message RemoteLog { } ``` -\ -\ ## Synchronization @@ -133,12 +133,12 @@ The *remote log* protobuf is what is stored in the name system. "Bob" can represent anything from 0 to N participants. Unlike Alice, Bob only needs read-only access to NS and CAS. -\ + ### Flow -\ \

\ @@ -146,7 +146,7 @@ The *remote log* protobuf is what is stored in the name system. Figure 1: Remote log data synchronization. \ -\ ### Remote log @@ -202,9 +202,9 @@ log. The latter is useful for things like backups on durable storage. The pointer to the 'next page' is another remote log entry, at a previous point in time. -\ -\ ### Interaction with MVDS diff --git a/vac/rln-stealth-commitments.md b/vac/rln-stealth-commitments.md new file mode 100644 index 0000000..feaad83 --- /dev/null +++ b/vac/rln-stealth-commitments.md @@ -0,0 +1,110 @@ +--- +title: RLN-STEALTH-COMMITMENTS +name: RLN Stealth Commitment Usage +category: Standards Track +editor: Aaryamann Challani \ +contributors: +- Jimmy Debe \ +sidebar_position: 1 +--- +- Category: Standards Track +- Editor: Aaryamann Challani \ +- Contributors:: + + +## Abstract + +This specification describes the usage of stealth commitments to add prospective users to a network-governed [32/RLN-V1](./32/rln-v1.md) membership set. + +## Motivation + +When [32/RLN-V1](./32/rln-v1.md) is enforced in [10/Waku2](../waku/standards/core/10/waku2.md), +all users are required to register to a membership set. +The membership set will store user identities allowing the secure interaction within an application. +Forcing a user to do an on-chain transaction to join a membership set is an onboarding friction, +and some projects may be opposed to this method. +To improve the user experience, +stealth commitments can be used by a counterparty to register identities on the user's behalf, +while maintaining the user's anonymity. + +This document specifies a privacy-preserving mechanism, +allowing a counterparty to utilize [32/RLN-V1](./32/rln-v1.md) to register an `identityCommitment` on-chain. +Counterparties will be able to register members to a RLN membership set without exposing the user's private keys. + +## Background +The [32/RLN-V1](./32/rln-v1.md) protocol, +consists of a smart contract that stores a `idenitityCommitment` in a membership set. +In order for a user to join the membership set, +the user is required to make a transaction on the blockchain. +A set of public keys is used to compute a stealth commitment for a user, +as described in [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564). +This specification is an implementation of the [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) scheme, +tailored to the curve that is used in the [32/RLN-V1](./32/rln-v1.md) protocol. + +This can be used in a couple of ways in applications: +1. Applications can add users to the [32/RLN-V1](./32/rln-v1.md) membership set in a batch. +2. Users of the application can register other users to the [32/RLN-V1](./32/rln-v1.md) membership set. + +This is useful when the prospective user does not have access to funds on the network that [32/RLN-V1](./32/rln-v1.md) is deployed on. + +## Wire Format Specification + +The two parties, the requester and the receiver, MUST exchange the following information: + +```protobuf + +message Request { + // The spending public key of the requester + bytes spending_public_key = 1; + + // The viewing public key of the requester + bytes viewing_public_key = 2; +} + +``` +### Generate Stealth Commitment + +The application or user SHOULD generate a `stealth_commitment` after a request to do so is received. +This commitment MAY be inserted into the corresponding application membership set. + +Once the membership set is updated, the receiver SHOULD exchange the following as a response to the request: + +```protobuf + +message Response { + + // The used to check if the stealth_commitment belongs to the requester + bytes view_tag = 2; + + // The stealth commitment for the requester + bytes stealth_commitment = 3; + + // The ephemeral public key used to generate the commitment + bytes ephemeral_public_key = 4; + +} + +``` + +The receiver MUST generate an `ephemeral_public_key`, `view_tag` and `stealth_commitment`. +This will be used to check the stealth commitment used to register to the membership set, +and the user MUST be able to check ownership with their `viewing_public_key`. + +## Implementation Suggestions + +An implementation of the Stealth Address scheme is available in the [erc-5564-bn254](https://github.com/rymnc/erc-5564-bn254) repository, +which also includes a test to generate a stealth commitment for a given user. + +## Security/Privacy Considerations + +This specification inherits the security and privacy considerations of the [Stealth Address](https://eips.ethereum.org/EIPS/eip-5564) scheme. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References + +- [10/Waku2](../waku/standards/core/10/waku2.md) +- [32/RLN-V1](./32/rln-v1.md) +- [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) diff --git a/waku/README.md b/waku/README.md index 18caa94..2117b35 100644 --- a/waku/README.md +++ b/waku/README.md @@ -1,5 +1,5 @@ -# Waku RFCs +## Waku RFCs Waku builds a family of privacy-preserving, censorship-resistant communication protocols for web3 applications. diff --git a/waku/deprecated/README.md b/waku/deprecated/README.md index 06ae459..a6a0e84 100644 --- a/waku/deprecated/README.md +++ b/waku/deprecated/README.md @@ -1,5 +1,5 @@ -# Deprecated RFCs +## Deprecated RFCs Deprecated specifications are no longer used in Waku products. This subdirectory is for achrive purpose and diff --git a/waku/deprecated/rpc.md b/waku/deprecated/rpc.md new file mode 100644 index 0000000..b7a3d01 --- /dev/null +++ b/waku/deprecated/rpc.md @@ -0,0 +1,640 @@ +--- +title: 16/WAKU2-RPC +name: Waku v2 RPC API +status: deprecated +editor: Hanno Cornelius \ +sidebar_position: 16 +--- +- Status: deprecated +- Editor: Hanno Cornelius \ + +## Introduction + +This specification describes the JSON-RPC API that Waku v2 nodes MAY adhere to. Refer to the [Waku v2 specification](../10/waku2.md) for more information on Waku v2. + +## Wire Protocol + +### Transport + +Nodes SHOULD expose an accessible [JSON-RPC](https://www.jsonrpc.org/specification) API. The JSON-RPC version SHOULD be `2.0`. Below is an example request: + +```json +{ + "jsonrpc":"2.0", + "method":"get_waku_v2_debug_info", + "params":[], + "id":1 +} +``` + +#### Fields + +| Field | Description | +| --------- | --------------------------------------------------- | +| `jsonrpc` | Contains the used JSON-RPC version (`Default: 2.0`) | +| `method` | Contains the JSON-RPC method that is being called | +| `params` | An array of parameters for the request | +| `id` | The request ID | + +### Types + +In this specification, the primitive types `Boolean`, `String`, `Number` and `Null`, as well as the structured types `Array` and `Object`, are to be interpreted according to the [JSON-RPC specification](https://www.jsonrpc.org/specification#conventions). It also adopts the same capitalisation conventions. + +The following structured types are defined for use throughout the document: + +### WakuMessage + +Refer to [`Waku Message` specification](../14/message.md) for more information. + +`WakuMessage` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ---: | :---: | :---: | --- | +| `payload` | `String` | mandatory | The message payload as a [base64 (with padding)](https://datatracker.ietf.org/doc/html/rfc4648) encoded data string | +| `contentTopic` | `String` | optional | Message content topic for optional content-based filtering | +| `version` | `Number` | optional | Message version. Used to indicate type of payload encryption. Default version is 0 (no payload encryption). | +| `timestamp` | `Number` | optional | The time at which the message is generated by its sender. This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | +| `ephemeral` | `Boolean` | optional | This flag indicates the transient nature of the message. Indicates if the message is eligible to be stored by the `store` protocol, [13/WAKU2-STORE](../13/store.md). | + +## Method naming + +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 + +The method `post_waku_v2_relay_v1_message`, for example, would map to the HTTP REST endpoint `POST /waku/v2/relay/v1/message`. + +## Debug API + +### Types + +The following structured types are defined for use on the Debug API: + +#### WakuInfo + +`WakuInfo` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `listenAddresses` | `Array`[`String`] | mandatory | Listening addresses of the node | +| `enrUri` | `String` | optional | ENR URI of the node | + +#### WakuInfo + +### `get_waku_v2_debug_v1_info` + +The `get_waku_v2_debug_v1_info` method retrieves information about a Waku v2 node + +#### Parameters + +none + +#### Response + +- [**`WakuInfo`**](#wakuinfo) - information about a Waku v2 node + + +### `get_waku_v2_debug_v1_version` + +The `get_waku_v2_debug_v1_version` method retrieves the version of a Waku v2 node as a string. +The version SHOULD follow [semantic versioning](https://semver.org/). +In case the node's current build is based on a git commit between semantic versions, +the retrieved version string MAY contain the git commit hash alone or in combination with the latest semantic version. + +#### Parameters + +none + +#### Response + +- **`string`** - represents the version of a Waku v2 node + + +## Relay API + +Refer to the [Waku Relay specification](../11/relay.md) for more information on the relaying of messages. + +### `post_waku_v2_relay_v1_message` + +The `post_waku_v2_relay_v1_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being published on | +| `message` | [`WakuMessage`](#wakumessage) | mandatory | The `message` being relayed | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `post_waku_v2_relay_v1_subscriptions` + +The `post_waku_v2_relay_v1_subscriptions` method subscribes a node to an array of [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topics` | `Array`[`String`] | mandatory | The [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being subscribed to | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `delete_waku_v2_relay_v1_subscriptions` + +The `delete_waku_v2_relay_v1_subscriptions` method unsubscribes a node from an array of [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topics` | `Array`[`String`] | mandatory | The [PubSub `topics`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being unsubscribed from | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `get_waku_v2_relay_v1_messages` + +The `get_waku_v2_relay_v1_messages` method returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) to poll for the latest messages | + +#### Response + +- **`Array`[[`WakuMessage`](#wakumessage)]** - the latest `messages` on the polled `topic` or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +## Relay Private API + +The Private API provides functionality to encrypt/decrypt `WakuMessage` payloads using either symmetric or asymmetric cryptography. This allows backwards compatibility with [Waku v1 nodes](../../legacy/6/waku1.md). +It is the API client's responsibility to keep track of the keys used for encrypted communication. Since keys must be cached by the client and provided to the node to encrypt/decrypt payloads, a Private API SHOULD NOT be exposed on non-local or untrusted nodes. + +### Types + +The following structured types are defined for use on the Private API: + +#### KeyPair + +`KeyPair` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `privateKey` | `String` | mandatory | Private key as hex encoded data string | +| `publicKey` | `String` | mandatory | Public key as hex encoded data string | + +### `get_waku_v2_private_v1_symmetric_key` + +Generates and returns a symmetric key that can be used for message encryption and decryption. + +#### Parameters + +none + +#### Response +- **`String`** - A new symmetric key as hex encoded data string + +### `get_waku_v2_private_v1_asymmetric_keypair` + +Generates and returns a public/private key pair that can be used for asymmetric message encryption and decryption. + +#### Parameters + +none + +#### Response +- **[`KeyPair`](#keypair)** - A new public/private key pair as hex encoded data strings + +### `post_waku_v2_private_v1_symmetric_message` + +The `post_waku_v2_private_v1_symmetric_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). + +Before being relayed, the message payload is encrypted using the supplied symmetric key. The client MUST provide a symmetric key. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being published on | +| `message` | [`WakuMessage`](#wakumessage) | mandatory | The (unencrypted) `message` being relayed | +| `symkey` | `String` | mandatory | The hex encoded symmetric key to use for payload encryption. This field MUST be included if symmetric key cryptography is selected | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `post_waku_v2_private_v1_asymmetric_message` + +The `post_waku_v2_private_v1_asymmetric_message` method publishes a message to be relayed on a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). + +Before being relayed, the message payload is encrypted using the supplied public key. The client MUST provide a public key. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) being published on | +| `message` | [`WakuMessage`](#wakumessage) | mandatory | The (unencrypted) `message` being relayed | +| `publicKey` | `String` | mandatory | The hex encoded public key to use for payload encryption. This field MUST be included if asymmetric key cryptography is selected | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `get_waku_v2_private_v1_symmetric_messages` + +The `get_waku_v2_private_v1_symmetric_messages` method decrypts and returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. + +Before returning the messages, the server decrypts the message payloads using the supplied symmetric key. The client MUST provide a symmetric key. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) to poll for the latest messages | +| `symkey` | `String` | mandatory | The hex encoded symmetric key to use for payload decryption. This field MUST be included if symmetric key cryptography is selected | + +#### Response + +- **`Array`[[`WakuMessage`](#wakumessage)]** - the latest `messages` on the polled `topic` or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `get_waku_v2_private_v1_asymmetric_messages` + +The `get_waku_v2_private_v1_asymmetric_messages` method decrypts and returns a list of messages that were received on a subscribed [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled `topic`. If no message has yet been received on the polled `topic`, the server SHOULD return an empty list. This method can be used to poll a `topic` for new messages. + +Before returning the messages, the server decrypts the message payloads using the supplied private key. The client MUST provide a private key. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `topic` | `String` | mandatory | The [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor) to poll for the latest messages | +| `privateKey` | `String` | mandatory | The hex encoded private key to use for payload decryption. This field MUST be included if asymmetric key cryptography is selected | + +#### Response + +- **`Array`[[`WakuMessage`](#wakumessage)]** - the latest `messages` on the polled `topic` or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + + +## Store API + +Refer to the [Waku Store specification](../13/store.md) for more information on message history retrieval. + +### Types + +The following structured types are defined for use on the Store API: + +#### StoreResponse + +`StoreResponse` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `messages` | `Array`[[`WakuMessage`](#wakumessage)] | mandatory | Array of retrieved historical messages | +| `pagingOptions` | [`PagingOptions`](#pagingOptions) | [conditional](#get_waku_v2_store_v1_messages) | Paging information from which to resume further historical queries | + + +#### PagingOptions + +`PagingOptions` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: |:-----------------:| :---: |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `pageSize` | `Number` | mandatory | Number of messages to retrieve per page | +| `cursor` | [`Index`](#index) | optional | Message [`Index`](#index) from which to perform pagination. If not included and `forward` is set to `true`, paging will be performed from the beginning of the list. If not included and `forward` is set to `false`, paging will be performed from the end of the list. | +| `forward` | `Bool` | mandatory | `true` if paging forward, `false` if paging backward | + +#### Index + +`Index` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |-------------------------------------------------------------------------------------------| +| `digest` | `String` | mandatory | A hash for the message at this [`Index`](#index) | +| `receivedTime` | `Number` | mandatory | UNIX timestamp in nanoseconds at which the message at this [`Index`](#index) was received | + +#### ContentFilter + +`ContentFilter` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `contentTopic` | `String` | mandatory | The content topic of a [`WakuMessage`](#wakumessage) | + +### `get_waku_v2_store_v1_messages` + +The `get_waku_v2_store_v1_messages` method retrieves historical messages on specific content topics. This method MAY be called with [`PagingOptions`](#pagingoptions), to retrieve historical messages on a per-page basis. If the request included [`PagingOptions`](#pagingoptions), the node MUST return messages on a per-page basis and include [`PagingOptions`](#pagingoptions) in the response. These [`PagingOptions`](#pagingoptions) MUST contain a `cursor` pointing to the [`Index`](#index) from which a new page can be requested. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `pubsubTopic` | `String` | optional | The pubsub topic on which a [`WakuMessage`](#wakumessage) is published | +| `contentFilters` | `Array`[[`ContentFilter`](#contentfilter)] | optional | Array of content filters to query for historical messages | +| `startTime` | `Number`| optional | The inclusive lower bound on the [`timestamp`](../14/message.md/#message-attributes) of queried [`WakuMessage`s](#wakumessage). This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | +| `endTime` | `Number` | optional | The inclusive upper bound on the [`timestamp`](../14/message.md/#message-attributes) of queried [`WakuMessage`s](#wakumessage). This field holds the Unix epoch time in nanoseconds as a 64-bits integer value. | +| `pagingOptions` | [`PagingOptions`](#pagingoptions) | optional | Pagination information | + +#### Response + +- [**`StoreResponse`**](#storeresponse) - the response to a `query` for historical messages. + +## Filter API + +Refer to the [Waku Filter specification](../12/filter.md) for more information on content filtering. + +### Types + +The following structured types are defined for use on the Filter API: + +#### ContentFilter + +`ContentFilter` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `contentTopic` | `String` | mandatory | message content topic | + +### `post_waku_v2_filter_v1_subscription` + +The `post_waku_v2_filter_v1_subscription` method creates a subscription in a [light node](../12/filter.md/#rationale) for messages that matches a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `contentFilters` | `Array`[[`ContentFilter`](#contentfilter)] | mandatory | Array of content filters being subscribed to | +| `topic` | `String` | optional | Message topic | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `delete_waku_v2_filter_v1_subscription` + +The `delete_waku_v2_filter_v1_subscription` method removes subscriptions in a [light node](../12/filter.md/#rationale) matching a content filter and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor). + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `contentFilters` | `Array`[[`ContentFilter`](#contentfilter)] | mandatory | Array of content filters being unsubscribed from | +| `topic` | `String` | optional | Message topic | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +### `get_waku_v2_filter_v1_messages` + +The `get_waku_v2_filter_v1_messages` method returns a list of messages that were received on a subscribed content `topic` after the last time this method was called. The server MUST respond with an [error](https://www.jsonrpc.org/specification#error_object) if no subscription exists for the polled content `topic`. If no message has yet been received on the polled content `topic`, the server SHOULD respond with an empty list. This method can be used to poll a content `topic` for new messages. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `contentTopic` | `String` | mandatory | The content topic to poll for the latest messages | + +#### Response + +- **`Array`[[`WakuMessage`](#wakumessage)]** - the latest `messages` on the polled content `topic` or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + +## Admin API + +The Admin API provides privileged accesses to the internal operations of a Waku v2 node. + +### Types + +The following structured types are defined for use on the Admin API: + +#### WakuPeer + +`WakuPeer` is an `Object` containing the following fields: + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `multiaddr` | `String` | mandatory | Multiaddress containing this peer's location and identity | +| `protocol` | `String` | mandatory | Protocol that this peer is registered for | +| `connected` | `bool` | mandatory | `true` if peer has active connection for this `protocol`, `false` if not | + +### `get_waku_v2_admin_v1_peers` + +The `get_waku_v2_admin_v1_peers` method returns an array of peers registered on this node. Since a Waku v2 node may open either continuous or ad hoc connections, depending on the negotiated protocol, these peers may have different connected states. The same peer MAY appear twice in the returned array, if it is registered for more than one protocol. + +#### Parameters + +none + +#### Response + +- **`Array`[[`WakuPeer`](#wakupeer)]** - Array of peers registered on this node + +### `post_waku_v2_admin_v1_peers` + +The `post_waku_v2_admin_v1_peers` method connects a node to a list of peers. + +#### Parameters + +| Field | Type | Inclusion | Description | +| ----: | :---: | :---: |----------- | +| `peers` | `Array`[`String`] | mandatory | Array of peer `multiaddrs` to connect to. Each `multiaddr` must contain the [location and identity addresses](https://docs.libp2p.io/concepts/addressing/) of a peer. | + +#### Response + +- **`Bool`** - `true` on success or an [error](https://www.jsonrpc.org/specification#error_object) on failure. + + +## Example usage + +### Store API + +#### `get_waku_v2_store_v1_messages` + +This method is part of the `store` API and the specific resources to retrieve are (historical) `messages`. The protocol (`waku`) is on `v2`, whereas the Store API definition is on `v1`. + +1. `get` *all* the historical messages for content topic **"/waku/2/default-content/proto"**; no paging required + +#### Request + +```curl -d '{"jsonrpc":"2.0","id":"id","method":"get_waku_v2_store_v1_messages", "params":["", [{"contentTopic":"/waku/2/default-content/proto"}]]}' --header "Content-Type: application/json" http://localhost:8545``` + +```jsonrpc +{ + "jsonrpc": "2.0", + "id": "id", + "method": "get_waku_v2_store_v1_messages", + "params": [ + "", + [ + {"contentTopic": "/waku/2/default-content/proto"} + ] + ] +} +``` + +#### Response + +```jsonrpc +{ + "jsonrpc": "2.0", + "id": "id", + "result": { + "messages": [ + { + "payload": dGVzdDE, + "contentTopic": "/waku/2/default-content/proto", + "version": 0 + }, + { + "payload": dGVzdDI, + "contentTopic": "/waku/2/default-content/proto", + "version": 0 + }, + { + "payload": dGVzdDM, + "contentTopic": "/waku/2/default-content/proto", + "version": 0 + } + ], + "pagingInfo": null + }, + "error": null +} +``` + +--- + +2. `get` a single page of historical messages for content topic **"/waku/2/default-content/proto"**; 2 messages per page, backward direction. Since this is the initial query, no `cursor` is provided, so paging will be performed from the end of the list. + +#### Request + +```curl -d '{"jsonrpc":"2.0","id":"id","method":"get_waku_v2_store_v1_messages", "params":[ "", [{"contentTopic":"/waku/2/default-content/proto"}],{"pageSize":2,"forward":false}]}' --header "Content-Type: application/json" http://localhost:8545``` + +```jsonrpc +{ + "jsonrpc": "2.0", + "id": "id", + "method": "get_waku_v2_store_v1_messages", + "params": [ + "", + [ + {"contentTopic": "/waku/2/default-content/proto"} + ], + { + "pageSize": 2, + "forward": false + } + ] +} +``` + +#### Response + +```jsonrpc +{ + "jsonrpc": "2.0", + "id": "id", + "result": { + "messages": [ + { + "payload": dGVzdDI, + "contentTopic": "/waku/2/default-content/proto", + "version": 0 + }, + { + "payload": dGVzdDM, + "contentTopic": "/waku/2/default-content/proto", + "version": 0 + } + ], + "pagingInfo": { + "pageSize": 2, + "cursor": { + "digest": "abcdef", + "receivedTime": 1605887187000000000 + }, + "forward": false + } + }, + "error": null +} +``` + +--- + +3. `get` the next page of historical messages for content topic **"/waku/2/default-content/proto"**, using the cursor received above; 2 messages per page, backward direction. + +#### Request + +```curl -d '{"jsonrpc":"2.0","id":"id","method":"get_waku_v2_store_v1_messages", "params":[ "", [{"contentTopic":"/waku/2/default-content/proto"}],{"pageSize":2,"cursor":{"digest":"abcdef","receivedTime":1605887187000000000},"forward":false}]}' --header "Content-Type: application/json" http://localhost:8545``` + +```jsonrpc +{ + "jsonrpc": "2.0", + "id": "id", + "method": "get_waku_v2_store_v1_messages", + "params": [ + "", + [ + {"contentTopic": "/waku/2/default-content/proto"} + ], + { + "pageSize": 2, + "cursor": { + "digest": "abcdef", + "receivedTime": 1605887187000000000 + }, + "forward": false + } + ] +} +``` + +#### Response + +```jsonrpc +{ + "jsonrpc": "2.0", + "id": "id", + "result": { + "messages": [ + { + "payload": dGVzdDE, + "contentTopic": "/waku/2/default-content/proto", + "version": 0 + }, + ], + "pagingInfo": { + "pageSize": 2, + "cursor": { + "digest": "123abc", + "receivedTime": 1605866187000000000 + }, + "forward": false + } + }, + "error": null +} +``` + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References + +1. [JSON-RPC specification](https://www.jsonrpc.org/specification) +1. [LibP2P Addressing](https://docs.libp2p.io/concepts/addressing/) +1. [LibP2P PubSub specification - topic descriptor](https://github.com/libp2p/specs/tree/master/pubsub#the-topic-descriptor) +1. [Waku v2 specification](../10/waku2.md) +1. [IETF RFC 4648 - The Base16, Base32, and Base64 Data Encodings](https://datatracker.ietf.org/doc/html/rfc4648) diff --git a/waku/informational/30/images/adaptive_node_continuum.jpg b/waku/informational/30/images/adaptive_node_continuum.jpg index 90c1d1cea9b47fc50039acb40b438e67804ca3ca..c6750110d55d0afbef9da85c9339b0f4a4e251da 100644 GIT binary patch delta 102 zcmaFeh&Am#vKP9Ww2 mVs0Sj0b*Vt=G(4r&j01ube*4EoZIF8@n62P{oO5r+GhYrJ0!6H delta 92 zcmey-$Jyh&Am#vKP9Ww2Vs0Sj0b*Vt d=G!h}&d+_E`AOHp?Hd31FW=ez@0LK-GXU`O9lihn diff --git a/waku/informational/30/images/adaptive_node_continuum2.png b/waku/informational/30/images/adaptive_node_continuum2.png index dceecfc72170104b25383274e4fa710d6c7ad6fa..2a77b0dcfa820550093ede4a3ea08067e9e9aec4 100644 GIT binary patch delta 14 WcmbQggmumm)(zK-Hs308y$=93Ob4m} delta 14 WcmbQUgmwNB)(zK-HeV_7xDNm}F$bpr diff --git a/waku/informational/30/images/adaptive_node_cross_section.jpg b/waku/informational/30/images/adaptive_node_cross_section.jpg index 21c0addeb10c6c0ea4a44ea54c0f4c0ee52b7682..ebadfa583df7c5ec14f1c36064dce92ea3f00c49 100644 GIT binary patch delta 63 zcmdo0UFYz3oee$4(-)R=3OCO-Zl7(;2*gZ4%nZaVK+FonY(UHo#2i4(3B+96XB%^? GZ~y>J1{awC delta 61 zcmX^7U1$Gyoee$4OgGmzPcm+wWXuS}OhC*G#4JF}3dC$c%nrmHK+FlmT-zrZa~pC1 E047!z`2YX_ diff --git a/waku/informational/30/images/adaptive_node_cross_section2.png b/waku/informational/30/images/adaptive_node_cross_section2.png index d13836cd3bd46c5fd1a58342755f1c6d8774c312..59e4ed3a47bfc7bfc95e7437b2ed83bed1332ea9 100644 GIT binary patch delta 49 scmZqt%+dRqV?!P%+xz`{foO99=SyE0J33sl70PZdyR*IQ4kLFg0IuvCYybcN delta 37 tcmeDE%+dInV?!P%)9HnqOE_QpGF|Q3oE$FM%5<~2x#`aKraO$>u>eZz5h(xw diff --git a/waku/informational/30/images/adaptive_node_network_topology_protocols2.png b/waku/informational/30/images/adaptive_node_network_topology_protocols2.png index fac5b3ac61c67bc71434414e747873c613823c83..0c57b2ca9852afd0465176ed44924b5e21ca9e33 100644 GIT binary patch delta 74 zcmdn_oa^j!t__tcZ14B)1)|N>D(m%OY@LurJ}~x$1t~?WU^UxKg&9k$q2ldp`WUyb J>0{zm1pr9rDP;fv delta 54 zcmV-60LlN&=L)&!3b1)30?nzjeWd8z>We9CDer&_5c6? diff --git a/waku/informational/30/images/adaptive_node_network_topology_protocols_legend.png b/waku/informational/30/images/adaptive_node_network_topology_protocols_legend.png index dfab74201b4ca302f88800deff1b61d0bf2dd4bd..283c05b54cb066b339648333a7d70a3a6ced2b01 100644 GIT binary patch delta 116 zcmaF%g!R)C)(y9=u)W{E7l=0BxzfW4V`tstRG-`)!MnYdm9a(!D!To*B4el^)2XT3 z!;BeQMPZ_MJs8(Hy7RGRG-`x!L_}Em9a*K>E4FzTuO|gf^6^i n?**dmiN=hrqD=SqZGYpzxQ=uC+#p6hDNcwSNcvn3;}TW?q%$i` diff --git a/waku/informational/30/images/adaptive_node_protocol_selection2.png b/waku/informational/30/images/adaptive_node_protocol_selection2.png index 8ef67a8252cc5a907ce25664d18a67ddc8bf3bbc..fb8f0b929f1c593c89794cfe2d97e1d8ab51117a 100644 GIT binary patch delta 24 ecmZqu$lCdlwP6dRlO@~x{d<9EyNe~GqdfqU{tG++ delta 20 bcmeDD$lCgmwP6dRlO@x&wc9-`86E8bT}%h* diff --git a/waku/informational/30/images/adaptive_protocol_selection.jpg b/waku/informational/30/images/adaptive_protocol_selection.jpg index de04de0ec4d9df3b67fb622e1c3f2935e9029b2a..55fefbd50faeb7907da382c9f80170bedbb0908e 100644 GIT binary patch delta 97 zcmaF3$mzi%rwuA|n-%A_E6!yEVkRJF24WTH&t-?x-*?!-_Ck~3y8UamjD1givYu0CN}^8 diff --git a/waku/standards/application/swap.md b/waku/standards/application/swap.md index 12eb298..a91f0d4 100644 --- a/waku/standards/application/swap.md +++ b/waku/standards/application/swap.md @@ -177,7 +177,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public 3. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth) 4. [13/WAKU2-STORE](../../core/13/store.md) -\ diff --git a/waku/standards/core/10/images/overview.png b/waku/standards/core/10/images/overview.png index 3c05c8f8fe7927d45335fe66e4fb6b23f963cf23..1e9eb3f2cd5ddf6ae3f84701f7f478db3a8620f3 100644 GIT binary patch delta 17 YcmZqb;%M#SXxPFid3?LramF{c06i%N{{R30 delta 17 YcmZqe;%MsPXxPFid3?LfamJUn06j_v0ssI2 diff --git a/waku/standards/core/12/filter.md b/waku/standards/core/12/filter.md index 0b95082..58a53ae 100644 --- a/waku/standards/core/12/filter.md +++ b/waku/standards/core/12/filter.md @@ -145,9 +145,9 @@ implementation, though a reasonable default is one minute. --- # Future Work -\ **Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: -- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor\. Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. - By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI). diff --git a/waku/standards/core/17/images/rln-message-verification.png b/waku/standards/core/17/images/rln-message-verification.png index bf3a009fa414bec591bb55d57352fb2deef7b41a..46ec55886f93a3d3c2a3ffe7c865b35544c77065 100644 GIT binary patch delta 85 zcmcbzllS>f-VJ1(Pqhg0nZeC5V?$eF6Em bkOTpu0k`@@0b?Qp!iI-qX92fkX99%vEnpp? diff --git a/waku/standards/core/17/images/rln-relay.png b/waku/standards/core/17/images/rln-relay.png index 6c333ff31930a490f5222b78ff44c22c6a642941..285c287f4ef9b77d2c914b617abdc401f23736e2 100644 GIT binary patch delta 30 mcmdn6iEG6st_?m{nC|Z09CSstfa%PP_EHzd?WHbEyF&ou>kY{O delta 38 mcmZ3niE9H8`CMUpzke?fZT7n&TL5LZ=ejU%&vjwi9RdKLvlMLr diff --git a/waku/standards/core/filter.md b/waku/standards/core/filter.md index ea673b9..1ee0ea1 100644 --- a/waku/standards/core/filter.md +++ b/waku/standards/core/filter.md @@ -234,9 +234,9 @@ and that it matches filter criteria belonging to that subscription. --- ## Future Work -\ **Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: -- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor\. Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. - By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI). diff --git a/waku/standards/core/relay.md b/waku/standards/core/relay.md index bd61253..a798b69 100644 --- a/waku/standards/core/relay.md +++ b/waku/standards/core/relay.md @@ -26,10 +26,10 @@ As such the scope is limited to defining a separate [`protocol id`](https://gith The `11/WAKU2-RELAY` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model). Note that data confidentiality, integrity, and authenticity are currently considered out of scope for `11/WAKU2-RELAY` and must be handled by higher layer protocols such as [`14/WAKU2-MESSAGE`](../14/message.md). -\ - **Publisher-Message Unlinkability**: This property indicates that no adversarial entity can link a published `Message` to its publisher. @@ -38,7 +38,7 @@ This feature also implies the unlinkability of the publisher to its published to - **Subscriber-Topic Unlinkability**: This feature stands for the inability of any adversarial entity from linking a subscriber to its subscribed topic IDs. -\ ### Terminology @@ -133,7 +133,7 @@ Note that this does not merely imply that these fields be empty, but that they M ## Security Analysis -\ - **Publisher-Message Unlinkability**: To address publisher-message unlinkability, one should remove any PII from the published message. @@ -141,7 +141,7 @@ As such, `11/WAKU2-RELAY` follows the `StrictNoSign` policy as described in [lib As the result of the `StrictNoSign` policy, `Message`s should be built without the `from`, `signature` and `key` fields since each of these three fields individually counts as PII for the author of the message (one can link the creation of the message with libp2p peerId and thus indirectly with the IP address of the publisher). Note that removing identifiable information from messages cannot lead to perfect unlinkability. The direct connections of a publisher might be able to figure out which `Message`s belong to that publisher by analyzing its traffic. -The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. \ - **Subscriber-Topic Unlinkability:** To preserve subscriber-topic unlinkability, it is recommended by [`10/WAKU2`](../10/waku2.md) to use a single PubSub topic in the `11/WAKU2-RELAY` protocol. @@ -159,13 +159,13 @@ At a high level, peers utilize a scoring function to locally score the behavior `11/WAKU2-RELAY` aims at enabling an advanced spam protection mechanism with economic disincentives by utilizing Rate Limiting Nullifiers. In a nutshell, peers must conform to a certain message publishing rate per a system-defined epoch, otherwise, they get financially penalized for exceeding the rate. More details on this new technique can be found in [`17/WAKU2-RLN-RELAY`](../17/rln-relay.md). - \ - Providing **Unlinkability**, **Integrity** and **Authenticity** simultaneously: Integrity and authenticity are typically addressed through digital signatures and Message Authentication Code (MAC) schemes, however, the usage of digital signatures (where each signature is bound to a particular peer) contradicts with the unlinkability requirement (messages signed under a certain signature key are verifiable by a verification key that is bound to a particular publisher). As such, integrity and authenticity are missing features in `11/WAKU2-RELAY` in the interest of unlinkability. In future work, advanced signature schemes like group signatures can be utilized to enable authenticity, integrity, and unlinkability simultaneously. -In a group signature scheme, a member of a group can anonymously sign a message on behalf of the group as such the true signer is indistinguishable from other group members. \ ## Copyright diff --git a/waku/standards/core/rln-relay.md b/waku/standards/core/rln-relay.md index ca91db4..97bc326 100644 --- a/waku/standards/core/rln-relay.md +++ b/waku/standards/core/rln-relay.md @@ -25,7 +25,7 @@ Peers that violate the messaging rate are considered spammers and their message Spammers are also financially punished and removed from the system. -\ ## Motivation @@ -50,7 +50,7 @@ The higher-level layers adopting `17/WAKU2-RLN-RELAY` MAY choose to enforce the ### Setup and Registration Peers subscribed to a specific `pubsubTopic` form a [RLN group](../../../../vac/32/rln-v1.md). -\ Peers MUST be registered to the RLN group to be able to publish messages. Registration is moderated through a smart contract deployed on the Ethereum blockchain. Each peer has an [RLN key pair](../../../../vac/32/rln-v1.md) denoted by `sk` and `pk`. @@ -59,7 +59,7 @@ The state of the membership contract contains the list of registered members' pu For the registration, a peer creates a transaction that invokes the registration function of the contract via which registers its `pk` in the group. The transaction also transfers some amount of ether to the contract to be staked. This amount is denoted by `staked_fund` and is a system parameter. -The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` of the staked fund by providing valid proof. \ `reward_portion` is also a system parameter. Note that `sk` is initially only known to its owning peer however, it may get exposed to other peers in case the owner attempts spamming the system i.e., sending more than one message per `epoch`. @@ -92,7 +92,7 @@ The `proof` field is a zero-knowledge proof signifying that: 3. The `nullifier` is constructed correctly. For more details about the proof generation check [RLN](../../../../vac/32/rln-v1.md) The proof generation relies on the knowledge of two pieces of private information i.e., `sk` and `authPath`. -The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. \ The proof generation also requires a set of public inputs which are: the Merkle tree root `merkle_root`, the current `epoch`, and the message for which the proof is going to be generated. In `17/WAKU2-RLN-RELAY`, the message is the concatenation of `WakuMessage`'s `payload` filed and its `contentTopic` i.e., `payload||contentTopic`. @@ -153,7 +153,7 @@ The `sk` then can be used to delete the spammer from the group and withdraw a po An overview of the routing procedure and slashing is provided in Figure 2. -\ ![Figure 2: Publishing, Routing and Slashing workflow.](./17/images/rln-message-verification.png) @@ -198,7 +198,7 @@ Below is the description of the fields of `RateLimitProof` and their types. | ----: | ----------- | ----------- | | `proof` | array of 256 bytes | the zkSNARK proof as explained in the [Publishing process](##Publishing) | | `merkle_root` | array of 32 bytes in little-endian order | the root of membership group Merkle tree at the time of publishing the message | -| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md) | \ | `nullifier` | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](../../../../vac/32/rln-v1.md)| diff --git a/waku/standards/core/store.md b/waku/standards/core/store.md index 3d9c451..574b2d0 100644 --- a/waku/standards/core/store.md +++ b/waku/standards/core/store.md @@ -221,12 +221,12 @@ However, one can consider preserving anonymity through one of the following ways This can happen by the utilization of a proxy server or by using Tor. Note that the current structure of historical requests does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve query anonymity. - \ - By deploying secure 2-party computations in which the querying node obtains the historical messages of a certain topic, the queried node learns nothing about the query. Examples of such 2PC protocols are secure one-way Private Set Intersections (PSI). - \ + - **Robust and verifiable timestamps**: Messages timestamp is a way to show that the message existed prior to some point in time. However, the lack of timestamp verifiability can create room for a range of attacks, diff --git a/waku/standards/core/waku2.md b/waku/standards/core/waku2.md index e6fb38c..c3d50ad 100644 --- a/waku/standards/core/waku2.md +++ b/waku/standards/core/waku2.md @@ -352,9 +352,9 @@ 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