Waku v2 spec: Use WakuMessage in data field (#173)

* Waku v2 spec: Use WakuMessage in data field

- Move contentFilter
- Bump version
- Fix protobuf field numbers in all specs

* Update specs/waku/waku-v2.md

Co-authored-by: Kim De Mey <kim.demey@gmail.com>

Co-authored-by: Kim De Mey <kim.demey@gmail.com>
This commit is contained in:
Oskar Thorén 2020-08-27 18:52:31 +08:00 committed by GitHub
parent f2509b033a
commit 9ba248f47f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 20 additions and 7 deletions

View File

@ -1,6 +1,6 @@
--- ---
title: Waku title: Waku
version: 2.0.0-alpha2 version: 2.0.0-alpha3
status: Raw status: Raw
authors: Oskar Thorén <oskar@status.im> authors: Oskar Thorén <oskar@status.im>
--- ---
@ -110,7 +110,11 @@ message Message {
repeated string topicIDs = 4; repeated string topicIDs = 4;
optional bytes signature = 5; optional bytes signature = 5;
optional bytes key = 6; optional bytes key = 6;
optional string contentTopic = 7; }
message WakuMessage {
optional bytes payload = 1;
optional string contentTopic = 2;
} }
``` ```
@ -130,7 +134,7 @@ TODO Give brief summary of each type here
The `from` field MAY indicate which peer is publishing the message. The `from` field MAY indicate which peer is publishing the message.
The `data` field SHOULD be filled out with whatever payload is being sent. Encryption of this field is done at a separate layer. The `data` field SHOULD be filled out with a `WakuMessage`.
The `seqno` field MAY be used to provide a linearly increasing number. See PubSub spec for more details. The `seqno` field MAY be used to provide a linearly increasing number. See PubSub spec for more details.
@ -153,6 +157,14 @@ The `topicid` field MUST contain the topic.
NOTE: This doesn't appear to be documented in PubSub spec, upstream? NOTE: This doesn't appear to be documented in PubSub spec, upstream?
### WakuMessage
A `WakuMessage` SHOULD be in the `data` field of `Message`.
The `payload` field SHOULD contain whatever payload is being sent. Encryption of this field is done at a separate layer.
The `contentTopic` field SHOULD be filled out to allow for content-based filtering (see section below).
## Discovery domain ## Discovery domain
TODO: To document how we use Discovery v5, etc. See https://github.com/vacp2p/specs/issues/167 TODO: To document how we use Discovery v5, etc. See https://github.com/vacp2p/specs/issues/167
@ -173,8 +185,8 @@ TODO To be elaborated on
```protobuf ```protobuf
message RPC { message RPC {
repeated HistoryQuery historyQuery = 4; repeated HistoryQuery historyQuery = 1;
repeated HistoryResponse historyResponse = 5; repeated HistoryResponse historyResponse = 2;
} }
message HistoryQuery { message HistoryQuery {
@ -209,7 +221,7 @@ corresponds to topics in Waku v1.
A node that only sets this field but doesn't subscribe to any topic SHOULD only A node that only sets this field but doesn't subscribe to any topic SHOULD only
get notified when the content subtopic matches. A content subtopic matches when get notified when the content subtopic matches. A content subtopic matches when
a message `contentTopic` is the same. This means such a node acts as a light node. a `Wakumessage` `contentTopic` field is the same.
A node that receives this RPC SHOULD apply this content filter before relaying. A node that receives this RPC SHOULD apply this content filter before relaying.
Since such a node is doing extra work for a light node, it MAY also account for Since such a node is doing extra work for a light node, it MAY also account for
@ -220,7 +232,7 @@ currently planned but underspecified.
```protobuf ```protobuf
message RPC { message RPC {
repeated ContentFilter contentFilter = 3; repeated ContentFilter contentFilter = 1;
} }
message ContentFilter { message ContentFilter {

View File

@ -156,6 +156,7 @@ vacp
vacp2p vacp2p
Vp Vp
waku waku
WakuMessage
WakuSub WakuSub
WakuWhisper WakuWhisper
WIP WIP