feat(67/status-waku2-usage): status usage of wakuv2 #627

rymnc · 2023-10-23T06:36:34Z

This RFC includes how status currently uses Wakuv2. It can be extended in the future for additional protocols, such as RLN.
ref: #608

rymnc · 2023-12-19T13:45:44Z

looks like I can't approve it since I opened the pr, LGTM ✅

kaiserd

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.

kaiserd · 2024-01-09T17:17:36Z

content/docs/rfcs/67/README.md

+name: Status Waku2 Usage
+status: raw
+category: Standards Track
+description: Get familiar with all the Waku protocols used by the Status application.


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."

content/docs/rfcs/67/README.md

kaiserd · 2024-01-09T17:22:39Z

content/docs/rfcs/67/README.md

+| `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/) |


Suggested change

| `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)

kaiserd · 2024-01-09T17:22:54Z

content/docs/rfcs/67/README.md

+| `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/) |
+
+


Suggested change

kaiserd · 2024-01-09T17:23:44Z

content/docs/rfcs/67/README.md

+### 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


Suggested change

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

Maybe you could say a Status client "comprises a Waku node" to be more explicit about the involved layering.

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 😅

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

cc: @jm-clius

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.

kaiserd · 2024-01-09T17:35:50Z

content/docs/rfcs/67/README.md

+
+## 2. `STORE`
+
+> Note: This protocol MUST remain optional according to the user's preferences,


Suggested change

> Note: This protocol MUST remain optional according to the user's preferences,

This protocol MUST remain optional according to the user's preferences,

kaiserd · 2024-01-09T17:37:36Z

content/docs/rfcs/67/README.md

+
+## 5. `DISCOVERY`
+
+> Note: This protocol MUST be supported by Light clients and Full clients


Suggested change

> Note: This protocol MUST be supported by Light clients and Full clients

This protocol MUST be supported by Light clients and Full clients

What is "this protocol" here? There are several discovery protocols.

kaiserd · 2024-01-09T17:37:56Z

content/docs/rfcs/67/README.md

+it MUST check if Light mode is enabled,
+and if so, it MUST publish the message via this protocol.
+
+## 5. `DISCOVERY`


Discovery has not been defined in the Terminology above.

kaiserd · 2024-01-09T17:39:02Z

content/docs/rfcs/67/README.md

+# Security/Privacy Considerations
+
+This specification inherits the security and privacy considerations from the following specifications -
+


For future versions, we should provide a summary of security considerations here.

kaiserd · 2024-01-09T17:40:46Z

content/docs/rfcs/67/README.md

+title: 67/STATUS-WAKU2-USAGE
+name: Status Waku2 Usage
+status: raw
+category: Standards Track


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 <1684595+kaiserd@users.noreply.github.com>

jm-clius

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

jm-clius · 2024-01-10T08:37:16Z

content/docs/rfcs/67/README.md

+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, 


Suggested change

Once integrated, an application will benifit from privacy preserving,

Once integrated, an application will benefit from privacy-preserving,

jm-clius · 2024-01-10T08:38:09Z

content/docs/rfcs/67/README.md

+slug: 67
+title: 67/STATUS-WAKU2-USAGE
+name: Status Waku2 Usage
+status: raw


Would this be raw or draft, since presumably there is a reference implementation?

@jm-clius This is considered raw since all new specs should be raw.

jm-clius · 2024-01-10T08:41:00Z

content/docs/rfcs/67/README.md

+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).


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/

jm-clius · 2024-01-10T08:41:47Z

content/docs/rfcs/67/README.md

+## 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).


See earlier note. Status does not use the RFC64 Waku Network

content/docs/rfcs/67/README.md

jm-clius · 2024-01-10T08:49:06Z

content/docs/rfcs/67/README.md

+
+## 3. `FILTER`
+
+> Note: This protocol SHOULD be enabled on Light clients.


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.

jm-clius · 2024-01-10T08:50:00Z

content/docs/rfcs/67/README.md

+
+## 4. `LIGHTPUSH`
+
+The `LIGHTPUSH` protocol MUST be enabled solely on Light clients.


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 <68783915+jm-clius@users.noreply.github.com>

jm-clius

Thanks for the changes. LGTM!

rymnc self-assigned this Oct 23, 2023

rymnc requested review from 0x-r4bbit, kaiserd and ramsesfv October 23, 2023 06:36

kaiserd removed the request for review from ramsesfv October 23, 2023 10:24

rymnc marked this pull request as ready for review October 25, 2023 07:28

jimstir force-pushed the 67-status-waku2-usage branch from 6a35ea8 to ea5dce1 Compare November 28, 2023 19:49

jimstir force-pushed the 67-status-waku2-usage branch 2 times, most recently from ea5dce1 to f32943c Compare December 6, 2023 00:24

jimstir closed this Dec 6, 2023

jimstir force-pushed the 67-status-waku2-usage branch from f32943c to cfaef76 Compare December 6, 2023 00:25

new

b93c6ed

jimstir reopened this Dec 8, 2023

jimstir added 5 commits December 10, 2023 16:20

Update README.md

add8200

Update README.md

bae3dc1

Update README.md

5f48023

Update README.md

46ae208

Update index.md

4da2a9c

kaiserd reviewed Jan 9, 2024

View reviewed changes

kaiserd requested a review from jm-clius January 9, 2024 17:43

jimstir and others added 5 commits January 9, 2024 15:30

Update content/docs/rfcs/67/README.md

960d687

Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>

Update content/docs/rfcs/67/README.md

b18038a

Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>

Update README.md

717e76e

Update README.md

c4ebe11

Update README.md

855843b

jm-clius requested changes Jan 10, 2024

View reviewed changes

jimstir and others added 3 commits January 10, 2024 04:54

Update content/docs/rfcs/67/README.md

affd4cc

Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>

Update README.md

f9e0273

Update README.md

03b8ae8

jm-clius approved these changes Jan 22, 2024

View reviewed changes

jimstir merged commit 8463804 into master Feb 20, 2024

jimstir deleted the 67-status-waku2-usage branch February 20, 2024 17:53

jimstir mentioned this pull request Mar 1, 2024

feat(67/status-waku2-usage): status usage of wakuv2 vacp2p/rfc-index#18

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(67/status-waku2-usage): status usage of wakuv2 #627

feat(67/status-waku2-usage): status usage of wakuv2 #627

rymnc commented Oct 23, 2023 •

edited

rymnc commented Dec 19, 2023

kaiserd left a comment

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

jimstir Jan 9, 2024 •

edited

jimstir Jan 10, 2024

jm-clius Jan 10, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

kaiserd Jan 9, 2024

jm-clius left a comment

jm-clius Jan 10, 2024

jm-clius Jan 10, 2024

jimstir Jan 10, 2024

jm-clius Jan 10, 2024

jm-clius Jan 10, 2024

jm-clius Jan 10, 2024

jm-clius Jan 10, 2024

jm-clius left a comment

	\| `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/) \|

		\| `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/) \|

	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


		## 2. `STORE`

		> Note: This protocol MUST remain optional according to the user's preferences,

	> Note: This protocol MUST remain optional according to the user's preferences,
	This protocol MUST remain optional according to the user's preferences,


		## 5. `DISCOVERY`

		> Note: This protocol MUST be supported by Light clients and Full clients

	> Note: This protocol MUST be supported by Light clients and Full clients
	This protocol MUST be supported by Light clients and Full clients

		# Security/Privacy Considerations

		This specification inherits the security and privacy considerations from the following specifications -

	Once integrated, an application will benifit from privacy preserving,
	Once integrated, an application will benefit from privacy-preserving,


		## 3. `FILTER`

		> Note: This protocol SHOULD be enabled on Light clients.


		## 4. `LIGHTPUSH`

		The `LIGHTPUSH` protocol MUST be enabled solely on Light clients.

feat(67/status-waku2-usage): status usage of wakuv2 #627

feat(67/status-waku2-usage): status usage of wakuv2 #627

Conversation

rymnc commented Oct 23, 2023 • edited

rymnc commented Dec 19, 2023

kaiserd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jimstir Jan 9, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jm-clius left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jm-clius left a comment

Choose a reason for hiding this comment

rymnc commented Oct 23, 2023 •

edited

jimstir Jan 9, 2024 •

edited