-
Notifications
You must be signed in to change notification settings - Fork 15
feat(67/status-waku2-usage): status usage of wakuv2 #627
Conversation
6a35ea8
to
ea5dce1
Compare
ea5dce1
to
f32943c
Compare
f32943c
to
cfaef76
Compare
looks like I can't approve it since I opened the pr, LGTM ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for this RFC.
The parts on Protocol Usage are under-speced, but that is OK for a first raw version.
We need to spec these parts out in future versions.
content/docs/rfcs/67/README.md
Outdated
name: Status Waku2 Usage | ||
status: raw | ||
category: Standards Track | ||
description: Get familiar with all the Waku protocols used by the Status application. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not sound like "RFC language", especially in a Standards Track RFC.
Rather something like: "Defines how the Status application uses the Waku protocol stack."
| `STORE` | This refers to the Waku Store protocol, described in [13/WAKU2-STORE](/spec/13) | | ||
| `MESSAGE` | This refers to the Waku Message format, described in [14/WAKU2-MESSAGE](/spec/14) | | ||
| `LIGHTPUSH` | This refers to the Waku Lightpush protocol, described in [19/WAKU2-LIGHTPUSH](/spec/19) | | ||
| `Pubsub Topic` / `Content Topic` | This refers to the routing of messages within the Waku network, described in [23/WAKU2-TOPICS](/spec/23/) | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| `Pubsub Topic` / `Content Topic` | This refers to the routing of messages within the Waku network, described in [23/WAKU2-TOPICS](/spec/23/) | | |
| `Pubsub Topic` / `Content Topic` | This refers to the routing and filtering of messages within the Waku network, described in [23/WAKU2-TOPICS](/spec/23/) | |
(content topics are for filtering)
content/docs/rfcs/67/README.md
Outdated
| `LIGHTPUSH` | This refers to the Waku Lightpush protocol, described in [19/WAKU2-LIGHTPUSH](/spec/19) | | ||
| `Pubsub Topic` / `Content Topic` | This refers to the routing of messages within the Waku network, described in [23/WAKU2-TOPICS](/spec/23/) | | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
content/docs/rfcs/67/README.md
Outdated
### Waku Node: | ||
|
||
A server running Waku software configured with a set of protocols. | ||
A Status client is a Waku node as that can be a full relay node or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A Status client is a Waku node as that can be a full relay node or | |
A Status client is a Waku node that can be a full relay node or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you could say a Status client "comprises a Waku node" to be more explicit about the involved layering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a definition for "full relay"?
We could just say a Waku node that supports relay. You could use "relay node" and "light node".
@jm-clius is it OK to say "light node" here, since it goes a bit against the adaptive nodes concept. Maybe you have a better term 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some specifications use full node language, like 12/WAKU2-FILTER, in 10/WAKU2 it is mentioned once in the Security Considerations. In 6/WAKU1 "A full bloom filter (all the bits set to 1) means that the node is to be considered a Full Node
and it will accept any topic."
The Full node terminology is not consistent throughout the specification, but light client and full client is used. @kaiserd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc: @jm-clius
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't refer to any WAKU1
specs or terminology as this has been replaced by new concepts for WAKU2
.
In Waku we generally don't refer to "full nodes" or "light nodes" with specific definitions. Instead, we have adaptive nodes that can be as "full" or "light" as is required by their application/environment. When a node is "resource restricted" it tends to choose protocols suitable for the constraints it faces, but there is no definition of what set of protocols constitutes a "light" mode. My reading of "full" or "light" in this RFC, though, was that these were Status concepts with clearly defined use case of Waku in each case? In other words, I'll opt for the terminology that Status uses inside their app when switching from "default relay" mode to filter+lightpush mode.
content/docs/rfcs/67/README.md
Outdated
|
||
## 2. `STORE` | ||
|
||
> Note: This protocol MUST remain optional according to the user's preferences, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
> Note: This protocol MUST remain optional according to the user's preferences, | |
This protocol MUST remain optional according to the user's preferences, |
content/docs/rfcs/67/README.md
Outdated
|
||
## 5. `DISCOVERY` | ||
|
||
> Note: This protocol MUST be supported by Light clients and Full clients |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
> Note: This protocol MUST be supported by Light clients and Full clients | |
This protocol MUST be supported by Light clients and Full clients |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is "this protocol" here? There are several discovery protocols.
content/docs/rfcs/67/README.md
Outdated
it MUST check if Light mode is enabled, | ||
and if so, it MUST publish the message via this protocol. | ||
|
||
## 5. `DISCOVERY` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discovery has not been defined in the Terminology above.
# Security/Privacy Considerations | ||
|
||
This specification inherits the security and privacy considerations from the following specifications - | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For future versions, we should provide a summary of security considerations here.
content/docs/rfcs/67/README.md
Outdated
title: 67/STATUS-WAKU2-USAGE | ||
name: Status Waku2 Usage | ||
status: raw | ||
category: Standards Track |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to the "best common practice" category here. See template.
Depends on how the RFC develops. I recommend switching to BCP, since this is what this document most likely evolves into.
Co-authored-by: kaiserd <[email protected]>
Co-authored-by: kaiserd <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Directionally looks good to me. I've added a couple of comments, most important of which are around clarifying the service/client sides in req-resp protocols.
content/docs/rfcs/67/README.md
Outdated
The Status application aspires to achieve censorship resistance and incorporates specific privacy features, | ||
leveraging the comprehensive set of protocols offered by Waku to enhance these attributes. | ||
Waku protocols provide secure communication capbailites over decentralized networks. | ||
Once integrated, an application will benifit from privacy preserving, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once integrated, an application will benifit from privacy preserving, | |
Once integrated, an application will benefit from privacy-preserving, |
slug: 67 | ||
title: 67/STATUS-WAKU2-USAGE | ||
name: Status Waku2 Usage | ||
status: raw |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this be raw
or draft
, since presumably there is a reference implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jm-clius This is considered raw since all new specs should be raw.
content/docs/rfcs/67/README.md
Outdated
a non-relay node. | ||
|
||
The Waku network is a group of Waku nodes used to create an open access messaging network, | ||
as described in [64/WAKU2-NETWORK](/spec/64). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since Status does not run on "the" Waku Network, I'm not sure that RFC 64 is relevant here. Instead, they run on semi-private Status-specific static shards, perhaps best described in https://rfc.vac.dev/spec/57/
content/docs/rfcs/67/README.md
Outdated
## 1. `RELAY` | ||
|
||
The `RELAY` MUST not be used by Status light clients. | ||
The `RELAY` is used to broadcast messages from a Status client nodes to peers in the [64/WAKU2-NETWORK](/spec/64). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See earlier note. Status does not use the RFC64 Waku Network
content/docs/rfcs/67/README.md
Outdated
|
||
## 3. `FILTER` | ||
|
||
> Note: This protocol SHOULD be enabled on Light clients. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general here (and I think for the STORE
protocol above as well) there is an overloading of the term client
. A Status client you've defined earlier, but now we also have the concept of FILTER
as a service node and FILTER
as a (filter) client node.
FILTER
service protocol (filter-subscribe
) SHOULD be enabled on all RELAY Status Clients (in other words, we want all relayers to also provide filter services).
FILTER
client protocol (filter-push
) SHOULD be enabled and used on all Status Light Clients as the preferred way to install subscriptions and receive messages.
content/docs/rfcs/67/README.md
Outdated
|
||
## 4. `LIGHTPUSH` | ||
|
||
The `LIGHTPUSH` protocol MUST be enabled solely on Light clients. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, light clients use LIGHTPUSH
to publish messages to the network, but the service-side protocol SHOULD be installed on all RELAY
Status Clients in order to provide this service to light clients.
Co-authored-by: Hanno Cornelius <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes. LGTM!
This RFC includes how status currently uses Wakuv2. It can be extended in the future for additional protocols, such as RLN.
ref: #608