14/WAKU2-MESSAGE: Update #655
Conversation
|
|
||
| An example proto file following this specification can be found [here (vacp2p/waku)](https://github.com/vacp2p/waku/blob/main/waku/message/v1/message.proto). |
There was a problem hiding this comment.
This link is not necessary as the message.proto is displayed in the specification.
content/docs/rfcs/14/README.md
Outdated
| @@ -82,11 +94,17 @@ message WakuMessage { | |||
| optional bool ephemeral = 31; | |||
| } | |||
| ``` | |||
| ## Waku Message Vaildator | |||
There was a problem hiding this comment.
This specification does not explicitly mention message validation. As detailed in libp2p spec and pubsub spec there is a message validator. Also in Waku node implements a validator here, message_validator.ts and wakuGossipSub.
content/docs/rfcs/14/README.md
Outdated
| If, instead, the attribute is omitted or set to `false`, the message SHOULD be interpreted as non-ephemeral. | ||
| * The `ephemeral` attribute, if present, | ||
| signifies the transient nature of the message. | ||
| For example, an ephemeral message SHOULD not be persisted by the [64/WAKU2-NETWORK](/spec/64). |
There was a problem hiding this comment.
Perhaps a bit weird to refer to a specific network deployment (RFC64) here. Perhaps the more correct phrasing is more generic:
SHOULD not be persisted by any Waku nodes
content/docs/rfcs/14/README.md
Outdated
| syntax = "proto3"; | ||
|
|
||
| message WakuMessage { | ||
| bytes payload = 1; | ||
| string content_topic = 2; | ||
| string contentTopic = 2; |
There was a problem hiding this comment.
Protobuf field names should use snake_case.
content/docs/rfcs/14/README.md
Outdated
| ``` | ||
|
|
||
| An example proto file following this specification can be found [here (vacp2p/waku)](https://github.com/vacp2p/waku/blob/main/waku/message/v1/message.proto). | ||
| ### Waku Message Vaildation |
There was a problem hiding this comment.
Not sure this section belongs in this RFC. Wouldn't validation rather be a function of the relay protocol (RFC17, which already includes RLN validation)? We do a bunch of validations on Waku Messages, but this is covered in the network spec in RFC64. According to me the scope of this RFC should just be the minimal definition of a Waku Message - Relayer behaviour and how the message is interpreted otherwise belong on "higher layer" specs. Happy to hear other opinions here though.
There was a problem hiding this comment.
@jm-clius Should this spec maybe reference 64/Waku2-Network for message interpretation instead? I suggested this section so the implementer can be aware why the two attributes content_topic and payload MUST be included in a message.
There was a problem hiding this comment.
Agree with @jm-clius . Validation should be in 17. This doc just specs the message format.
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
|
Continue discussion: vacp2p/rfc-index#20. The RFC process has been changed separating raw specs and the draft/stable specs into different repositories. |
Updating spec fixing links, sembr and language. Also included new message validator section.