acid-info
/
rnd-rfc.vac.dev
mirror of https://github.com/acid-info/rnd-rfc.vac.dev.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix: handle unescaped comments and update content

This commit is contained in:
jinhojang6 2024-04-17 21:21:27 +09:00
parent 5e2df2cd2d
commit e231486568
No known key found for this signature in database
GPG Key ID: 1762F21FE8B543F8
32 changed files with 807 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
fetch-content.js
View File

@ -180,6 +180,10 @@ function parseSlugFromFrontmatter(content) {
return 1 // Return null if not found
}
function unescapeHtmlComments(htmlString) {
return htmlString.replace(/\\<\!--/g, '<!--').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

6
nomos/claro.md
View File

@ -123,8 +123,8 @@ The algorithm is divided into 4 phases:
3. Transition function
4. Opinion and Decision
\<!-- NOTE from CP: not sure this fits, commenting for now --\>
\<!-- ### Proposal Identification
<!-- NOTE from CP: not sure this fits, commenting for now -->
<!-- ### Proposal Identification
The node has a semantics and serialization of the proposal, of which
it sets an initial opinion:
@ -140,7 +140,7 @@ severely constrained in the absence of timeouts for a round to
proceed. When a given node has finalized its decision on the
proposal, it enters a quiescent state in which it optionally discards
all information gathered during the query process retaining only the
final opinion on the truth of the proposal. --\>
final opinion on the truth of the proposal. -->
### Setup Parameters

2
status/1to1-chat.md
View File

@ -145,7 +145,7 @@ message MembershipUpdateEvent {
}
}
```
\<!-- Note: I don't like defining wire formats which are out of the scope of the rfc this way. Should explore alternatives --\>
<!-- Note: I don't like defining wire formats which are out of the scope of the rfc this way. Should explore alternatives -->
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

BIN
status/71/images/notification.png
View File

Binary file not shown.

2
status/account-address.md
View File

@ -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.
\<!-- TODO: Elaborate on wallet account and multiaccount --\>
<!-- TODO: Elaborate on wallet account and multiaccount -->
## Wire Format

8
status/communities.md
View File

@ -74,12 +74,12 @@ The following cryptographic primitives are used in the design -
## Wire format
\<!--
<!--
The wire format is described first to give an overview of the protocol.
It is referenced in the flow of community creation and community management.
More or less an intersection of https://github.com/status-im/specs/blob/403b5ce316a270565023fc6a1f8dec138819f4b0/docs/raw/organisation-channels.md and https://github.com/status-im/status-go/blob/6072bd17ab1e5d9fc42cf844fcb8ad18aa07760c/protocol/protobuf/communities.proto,
--\>
-->
```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.
\<!-- Don't enforce any constraints on the unique id generation --\>
<!-- Don't enforce any constraints on the unique id generation -->
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. \<!-- TODO: Verify this--\>
the Community metadata SHOULD be encrypted with the public key of the Community. <!-- TODO: Verify this-->
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.

2
status/keycard-usage.md
View File

@ -248,7 +248,7 @@ To verify the pin of the keycard.
Status code reference:
- 3: PIN is valid
\<!--TODO: what are the other status codes?--\>
<!--TODO: what are the other status codes?-->
### 9. Change the pin (`/change-pin`)

2
status/payloads.md
View File

@ -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).
\<!-- TODO: This reference is a bit odd, considering the layer payloads should interact with is Secure Transport, and not Whisper/Waku. This requires more detail --\>
<!-- TODO: This reference is a bit odd, considering the layer payloads should interact with is Secure Transport, and not Whisper/Waku. This requires more detail -->
The following messages types MUST be supported:

4
vac/mvds.md
View File

@ -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.
\<!-- diagram --\>
<!-- diagram -->
\<p align="center"\>
\<img src="../assets/mvds/batch.png" /\>
@ -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.*
\<!-- Interactions with state, flow chart with retransmissions? --\>
<!-- Interactions with state, flow chart with retransmissions? -->
### Retransmission

24
vac/remote-log.md
View File

@ -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.
\<!-- TODO: Elaborate on properties required here. --\>
<!-- TODO: Elaborate on properties required here. -->
### Payloads
@ -60,7 +60,7 @@ message Content {
}
```
\<!-- XXX/TODO: Can we get rid of the id/data complication and just use bytes? --\>
<!-- XXX/TODO: Can we get rid of the id/data complication and just use bytes? -->
**NS service**:
@ -92,8 +92,8 @@ message Response {
}
```
\<!-- XXX: Response and data type a bit weird, Ok/Err enum? --\>
\<!-- TODO: Do we want NameInit here? --\>
<!-- XXX: Response and data type a bit weird, Ok/Err enum? -->
<!-- TODO: Do we want NameInit here? -->
**Remote log:**
@ -114,9 +114,9 @@ message RemoteLog {
}
```
\<!-- TODO: Better name for Pair, Mapping? --\>
<!-- TODO: Better name for Pair, Mapping? -->
\<!-- TODO: Consider making more useful in conjunction with metadata field. It makes sense to explicitly list what sequence a message is \<local hash, remote hash, data, seqid\> this way I can easily sync a messages prior or after a specific number. To enable this to be dynamic it might make sense to add page info so that I am aware which page I can find seqid on --\>
<!-- TODO: Consider making more useful in conjunction with metadata field. It makes sense to explicitly list what sequence a message is \<local hash, remote hash, data, seqid\> this way I can easily sync a messages prior or after a specific number. To enable this to be dynamic it might make sense to add page info so that I am aware which page I can find seqid on -->
## Synchronization
@ -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.
\<!-- TODO: Document random node as remote log --\>
\<!-- TODO: Document how to find initial remote log (e.g. per sync contexts --\>
<!-- TODO: Document random node as remote log -->
<!-- TODO: Document how to find initial remote log (e.g. per sync contexts -->
### Flow
\<!-- diagram --\>
<!-- diagram -->
\<p align="center"\>
\<img src="./images/remote-log.png" /\>
@ -146,7 +146,7 @@ The *remote log* protobuf is what is stored in the name system.
Figure 1: Remote log data synchronization.
\</p\>
\<!-- Document the flow wrt operations --\>
<!-- Document the flow wrt operations -->
### 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.
\<!-- TODO: Determine requirement re overlapping, adjacent, and/or missing entries --\>
<!-- TODO: Determine requirement re overlapping, adjacent, and/or missing entries -->
\<!-- TODO: Document message ordering append only requirements --\>
<!-- TODO: Document message ordering append only requirements -->
### Interaction with MVDS

110
vac/rln-stealth-commitments.md Normal file
View File

@ -0,0 +1,110 @@
---
title: RLN-STEALTH-COMMITMENTS
name: RLN Stealth Commitment Usage
category: Standards Track
editor: Aaryamann Challani \<aaryamann@status.im\>
contributors:
- Jimmy Debe \<jimmy@status.im\>
sidebar_position: 1
---
- Category: Standards Track
- Editor: Aaryamann Challani \<aaryamann@status.im\>
- 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)

2
waku/README.md
View File

@ -1,5 +1,5 @@
# Waku RFCs
## Waku RFCs
Waku builds a family of privacy-preserving, censorship-resistant communication protocols for web3 applications.

2
waku/deprecated/README.md
View File

@ -1,5 +1,5 @@
# Deprecated RFCs
## Deprecated RFCs
Deprecated specifications are no longer used in Waku products.
This subdirectory is for achrive purpose and

640
waku/deprecated/rpc.md Normal file
View File

@ -0,0 +1,640 @@
---
title: 16/WAKU2-RPC
name: Waku v2 RPC API
status: deprecated
editor: Hanno Cornelius \<hanno@status.im\>
sidebar_position: 16
---
- Status: deprecated
- Editor: Hanno Cornelius \<hanno@status.im\>
## 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 `\<method_type\>_waku_\<protocol_version\>_\<api\>_\<api_version\>_\<resource\>`
- `\<method_type\>`: prefix of the HTTP method type that most closely matches the JSON-RPC function. Supported `method_type` values are `get`, `post`, `put`, `delete` or `patch`.
- `\<protocol_version\>`: Waku version. Currently **v2**.
- `\<api\>`: one of the listed APIs below, e.g. `store`, `debug`, or `relay`.
- `\<api_version\>`: API definition version. Currently **v1** for all APIs.
- `\<resource\>`: the resource or resource path being addressed
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)

BIN
waku/informational/30/images/adaptive_node_continuum.jpg
View File

Binary file not shown.

BIN
waku/informational/30/images/adaptive_node_continuum2.png
View File

Binary file not shown.

BIN
waku/informational/30/images/adaptive_node_cross_section.jpg
View File

Binary file not shown.

BIN
waku/informational/30/images/adaptive_node_cross_section2.png
View File

Binary file not shown.

BIN
waku/informational/30/images/adaptive_node_network_topology_protocols2.png
View File

Binary file not shown.

BIN
waku/informational/30/images/adaptive_node_network_topology_protocols_legend.png
View File

Binary file not shown.

BIN
waku/informational/30/images/adaptive_node_protocol_selection2.png
View File

Binary file not shown.

BIN
waku/informational/30/images/adaptive_protocol_selection.jpg
View File

Binary file not shown.

4
waku/standards/application/swap.md
View File

@ -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)
\<!--
<!--
General TODOs:
@ -187,4 +187,4 @@ General TODOs:
- Illustrate flow
- Specify chequeboo
--\>
-->

BIN
waku/standards/core/10/images/overview.png
View File

Binary file not shown.

4
waku/standards/core/12/filter.md
View File

@ -145,9 +145,9 @@ implementation, though a reasonable default is one minute.
---
# Future Work
\<!-- Alternative title: Filter-subscriber unlinkability --\>
<!-- Alternative title: Filter-subscriber unlinkability -->
**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\<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address--\>.
- 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<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address-->.
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).

BIN
waku/standards/core/17/images/rln-message-verification.png
View File

Binary file not shown.

BIN
waku/standards/core/17/images/rln-relay.png
View File

Binary file not shown.

4
waku/standards/core/filter.md
View File

@ -234,9 +234,9 @@ and that it matches filter criteria belonging to that subscription.
---
## Future Work
\<!-- Alternative title: Filter-subscriber unlinkability --\>
<!-- Alternative title: Filter-subscriber unlinkability -->
**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\<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address--\>.
- 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<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the WakuFilter protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a subscriber and its content filter despite hiding the IP address-->.
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).

14
waku/standards/core/relay.md
View File

@ -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).
\<!-- May add the definition of the unsupported feature:
<!-- May add the definition of the unsupported feature:
Confidentiality indicates that an adversary should not be able to learn the data carried by the `WakuRelay` protocol.
Integrity indicates that the data transferred by the `WakuRelay` protocol can not be tampered with by an adversarial entity without being detected.
Authenticity no adversary can forge data on behalf of a targeted publisher and make it accepted by other subscribers as if the origin is the target. --\>
Authenticity no adversary can forge data on behalf of a targeted publisher and make it accepted by other subscribers as if the origin is the target. -->
- **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.
\<!-- TODO: more requirements can be added, but that needs further and deeper investigation--\>
<!-- TODO: more requirements can be added, but that needs further and deeper investigation-->
### Terminology
@ -133,7 +133,7 @@ Note that this does not merely imply that these fields be empty, but that they M
## Security Analysis
\<!-- TODO: realized that the prime security objective of the `WakuRelay` protocol is to provide peers unlinkability as such this feature is prioritized over other features e.g., unlinkability is preferred over authenticity and integrity. It might be good to motivate unlinkability and its impact on the relay protocol or other protocols invoking relay protocol.--\>
<!-- TODO: realized that the prime security objective of the `WakuRelay` protocol is to provide peers unlinkability as such this feature is prioritized over other features e.g., unlinkability is preferred over authenticity and integrity. It might be good to motivate unlinkability and its impact on the relay protocol or other protocols invoking relay protocol.-->
- **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. \<!-- TODO: more investigation on traffic analysis attacks and their success probability--\>
The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. <!-- TODO: more investigation on traffic analysis attacks and their success probability-->
- **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).
\<!-- TODO havn't checked if all the measures in libp2p GossipSub v1.1 are taken in the nim-libp2p as well, may need to audit the code --\>
<!-- TODO havn't checked if all the measures in libp2p GossipSub v1.1 are taken in the nim-libp2p as well, may need to audit the code -->
- 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. \<!-- TODO: shall I add a reference for group signatures?--\>
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. <!-- TODO: shall I add a reference for group signatures?-->
## Copyright

12
waku/standards/core/rln-relay.md
View File

@ -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.
\<!-- **Protocol identifier***: `/vac/waku/waku-rln-relay/2.0.0-alpha1` --\>
<!-- **Protocol identifier***: `/vac/waku/waku-rln-relay/2.0.0-alpha1` -->
## 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).
\<!-- link to the RLN group definition in the RLN RFC --\>
<!-- link to the RLN group definition in the RLN RFC -->
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. \<!-- a secure way to prove the possession of a pk is yet under discussion, maybe via commit and reveal --\>
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. <!-- a secure way to prove the possession of a pk is yet under discussion, maybe via commit and reveal -->
`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. \<!-- TODO refer to RLN RFC for authPath def --\>
The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. <!-- TODO refer to RLN RFC for authPath def -->
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.
\<!-- TODO: may consider [validator functions](https://github.com/libp2p/specs/tree/master/pubsub#topic-validation) or [extended validators](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) for the spam detection --\>
<!-- TODO: may consider [validator functions](https://github.com/libp2p/specs/tree/master/pubsub#topic-validation) or [extended validators](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) for the spam detection -->
![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) | \<!-- todo specify the poseidon hash setting --\>
| `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) | <!-- todo specify the poseidon hash setting -->
| `nullifier` | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](../../../../vac/32/rln-v1.md)|

6
waku/standards/core/store.md
View File

@ -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.
\<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the store protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a querying node and its queried topics despite hiding the IP address--\>
<!-- TODO: if nodes have to disclose their PeerIDs (e.g., for authentication purposes) when connecting to other nodes in the store protocol, then Tor does not preserve anonymity since it only helps in hiding the IP. So, the PeerId usage in switches must be investigated further. Depending on how PeerId is used, one may be able to link between a querying node and its queried topics despite hiding the IP address-->
- 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).
\<!-- TODO: add a reference for PSIs? --\> \<!-- TODO: more techniques to be included --\>
\<!-- TODO: Censorship resistant: this is about a node that hides the historical messages from other nodes. This attack is not included in the specs since it does not fit the passive adversarial model (the attacker needs to deviate from the store protocol).--\>
<!-- TODO: add a reference for PSIs? --> <!-- TODO: more techniques to be included -->
<!-- TODO: Censorship resistant: this is about a node that hides the historical messages from other nodes. This attack is not included in the specs since it does not fit the passive adversarial model (the attacker needs to deviate from the store protocol).-->
- **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,

4
waku/standards/core/waku2.md
View File

@ -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.
\<!-- TODO: to inspect the nim-libp2p codebase and figure out the exact use of PeerIDs in direct communication, it might be the case that the requester does not have to disclose its PeerID--\>
<!-- TODO: to inspect the nim-libp2p codebase and figure out the exact use of PeerIDs in direct communication, it might be the case that the requester does not have to disclose its PeerID-->
\<!--TODO: might be good to add a figure visualizing the Waku protocol stack and the security features of each layer--\>
<!--TODO: might be good to add a figure visualizing the Waku protocol stack and the security features of each layer-->
## Appendix C: Implementation Notes