From f7e1057a3eaa72012d6cdc7b73619f965369a6a0 Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Wed, 29 May 2024 18:31:10 +0200 Subject: [PATCH 01/10] Based on https://github.com/waku-org/pm/issues/93 this new version of lightpush protobuf protocol definition is proposed. --- standards/core/lightpush.md | 88 +++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 standards/core/lightpush.md diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md new file mode 100644 index 0000000..081c0ca --- /dev/null +++ b/standards/core/lightpush.md @@ -0,0 +1,88 @@ +--- +slug: 19 +title: 19/WAKU2-LIGHTPUSH +name: Waku v2 Light Push +status: draft +editor: Zoltan Nagy +contributors: + - Hanno Cornelius + - Daniel Kaiser + - Oskar Thorén +--- + +previous version: `/vac/waku/lightpush/2.0.0-beta1` [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/waku/standards/core/19/lightpush) + +--- +**Protocol identifier**: `/vac/waku/lightpush/2.0.0-beta2` + +## Motivation and Goals + +Light nodes with short connection windows and limited bandwidth wish to publish messages into the Waku network. +Additionally, there is sometimes a need for confirmation that a message has been received "by the network" +(here, at least one node). + +`19/WAKU2-LIGHTPUSH` is a request/response protocol for this. + +## Payloads + +```protobuf +syntax = "proto3"; + +message LightPushRequest { + enum RequestType { // Future extension point + RELAY = 0; + } + + string request_id = 1; + RequestType kind = 10; // default is RELAY, placeholder for future extensions + string pubsub_topic = 20; + WakuMessage message = 21; +} + +message LightPushResponse { + enum Status { + SUCCESS = 0; + BAD_REQUEST = 400; + NO_PEERS_TO_RELAY = 404; + PAYLOAD_TOO_LARGE = 413; + UNSUPPORTED_TOPIC = 415; + TOO_MANY_REQUESTS = 429; + INTERNAL_SERVER_ERROR = 500; + SERVICE_UNAVAILABLE = 503; + } + + string request_id = 1; + Status status_code = 10; + optional string status_desc = 11; + uint32 relay_peer_count = 12; +} +``` + +### Message Relaying + +Nodes that respond to `LightPushRequest` MUST either +relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`, +or forward the `LightPushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) stem. +If they are unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. + +## Security Considerations + +Since this can introduce an amplification factor, it is RECOMMENDED for the node relaying to the rest of the network to take extra precautions. +This can be done by rate limiting via [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay). + +Note that the above is currently not fully implemented. + +## Future work + +- Add support attaching RLN proof for the message requested to be relayed. +- Add support for other request types. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References + +* [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) +* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) +* [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay) From 13a3cc4d6754a0ae1f557553e1c951a727bfc731 Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Sun, 9 Jun 2024 19:36:56 +0200 Subject: [PATCH 02/10] Answer review notices, rephrase of some sections. Rework the protobuf definition as requested. --- standards/core/lightpush.md | 60 ++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index 081c0ca..3a45ccd 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -1,6 +1,5 @@ --- -slug: 19 -title: 19/WAKU2-LIGHTPUSH +title: WAKU2-LIGHTPUSH name: Waku v2 Light Push status: draft editor: Zoltan Nagy @@ -13,15 +12,16 @@ contributors: previous version: `/vac/waku/lightpush/2.0.0-beta1` [19/WAKU2-LIGHTPUSH](https://rfc.vac.dev/waku/standards/core/19/lightpush) --- -**Protocol identifier**: `/vac/waku/lightpush/2.0.0-beta2` +**Protocol identifier**: `/vac/waku/lightpush/3.0.0` ## Motivation and Goals -Light nodes with short connection windows and limited bandwidth wish to publish messages into the Waku network. +Light nodes with short connection windows and limited bandwidth wish to push messages to other nodes in the Waku network to request message services. +A common use case is to request that service node to publish the message to a `11/WAKU2-RELAY` pubsub topic. Additionally, there is sometimes a need for confirmation that a message has been received "by the network" (here, at least one node). -`19/WAKU2-LIGHTPUSH` is a request/response protocol for this. +`WAKU2-LIGHTPUSH` is a request/response protocol for this. ## Payloads @@ -29,30 +29,15 @@ Additionally, there is sometimes a need for confirmation that a message has been syntax = "proto3"; message LightPushRequest { - enum RequestType { // Future extension point - RELAY = 0; - } - - string request_id = 1; - RequestType kind = 10; // default is RELAY, placeholder for future extensions - string pubsub_topic = 20; + string request_id = 1; + uin32 request_type = 10; // reserved for future request type selection, currently it is always RELAY (0) + string topic = 20; WakuMessage message = 21; } message LightPushResponse { - enum Status { - SUCCESS = 0; - BAD_REQUEST = 400; - NO_PEERS_TO_RELAY = 404; - PAYLOAD_TOO_LARGE = 413; - UNSUPPORTED_TOPIC = 415; - TOO_MANY_REQUESTS = 429; - INTERNAL_SERVER_ERROR = 500; - SERVICE_UNAVAILABLE = 503; - } - string request_id = 1; - Status status_code = 10; + uint32 status_code = 10; // non zero in case of failure, see appendix optional string status_desc = 11; uint32 relay_peer_count = 12; } @@ -60,22 +45,38 @@ message LightPushResponse { ### Message Relaying -Nodes that respond to `LightPushRequest` MUST either -relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`, -or forward the `LightPushRequest` via 19/LIGHTPUSH on a [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) stem. +Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic` or `shard` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)) depending on the network configuration. If they are unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. +### Examples of possible error codes + +| Result | Code | Note | +|--------|------|------| +| SUCCESS | 0 | Successfull push, response's relay_peer_count holds the number of peers the message is pushed. | +| BAD_REQUEST | 400 | | +| NO_PEERS_TO_RELAY | 404 | Service node has no relay peers | +| PAYLOAD_TOO_LARGE | 413 | Message exceeds certain size limit, it can depend on network configuration, see status_desc for details. | +| UNSUPPORTED_TOPIC | 415 | Requested push on pubsub_topic or shard is not possible as the service node is not subscibed to. | +| TOO_MANY_REQUESTS | 429 | DOS protection prevented this request as the current request exceeds the configured request rate. | +| INTERNAL_SERVER_ERROR | 500 | status_desc holds explanation of the error. | +| SERVICE_UNAVAILABLE | 503 | Lightpush service not available | + +> The list of error codes are not complete and can be extended in the future. + ## Security Considerations Since this can introduce an amplification factor, it is RECOMMENDED for the node relaying to the rest of the network to take extra precautions. -This can be done by rate limiting via [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay). +Therefore Waku2 applies or will apply: +- DOS protection through request rate limitation on the service itself. +- message rate limiting via [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay), applied via network membership subscription. -Note that the above is currently not fully implemented. +> These features are under development. ## Future work - Add support attaching RLN proof for the message requested to be relayed. - Add support for other request types. +- Incentivization of the service ## Copyright @@ -84,5 +85,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References * [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) -* [WAKU2-DANDELION](https://github.com/waku-org/specs/blob/waku-RFC/standards/application/dandelion.md) * [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay) From 9a4f375141987a7a89f7842d2fd47b4cdafd88d1 Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Wed, 19 Jun 2024 15:56:43 +0200 Subject: [PATCH 03/10] Finalize with incorporating review findings. --- standards/core/lightpush.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index 3a45ccd..a779074 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -1,7 +1,6 @@ --- title: WAKU2-LIGHTPUSH -name: Waku v2 Light Push -status: draft +name: Waku Light Push editor: Zoltan Nagy contributors: - Hanno Cornelius @@ -21,7 +20,7 @@ A common use case is to request that service node to publish the message to a `1 Additionally, there is sometimes a need for confirmation that a message has been received "by the network" (here, at least one node). -`WAKU2-LIGHTPUSH` is a request/response protocol for this. +`WAKU-LIGHTPUSH` is a request/response protocol for this. ## Payloads @@ -29,9 +28,9 @@ Additionally, there is sometimes a need for confirmation that a message has been syntax = "proto3"; message LightPushRequest { - string request_id = 1; - uin32 request_type = 10; // reserved for future request type selection, currently it is always RELAY (0) - string topic = 20; + string request_id = 1; + uin32 request_type = 10; // 10 Reserved for future `request_type`. Currently RELAY is only available service. + optional string pubsub_topic = 20; WakuMessage message = 21; } @@ -45,18 +44,18 @@ message LightPushResponse { ### Message Relaying -Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic` or `shard` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)) depending on the network configuration. +Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`. Depending on the network configuration, user may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). If they are unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. ### Examples of possible error codes | Result | Code | Note | |--------|------|------| -| SUCCESS | 0 | Successfull push, response's relay_peer_count holds the number of peers the message is pushed. | -| BAD_REQUEST | 400 | | -| NO_PEERS_TO_RELAY | 404 | Service node has no relay peers | +| SUCCESS | 200 | Successfull push, response's relay_peer_count holds the number of peers the message is pushed. | +| BAD_REQUEST | 400 | Wrong request payload. | +| NO_PEERS_TO_RELAY | 404 | Service node has no relay peers. | | PAYLOAD_TOO_LARGE | 413 | Message exceeds certain size limit, it can depend on network configuration, see status_desc for details. | -| UNSUPPORTED_TOPIC | 415 | Requested push on pubsub_topic or shard is not possible as the service node is not subscibed to. | +| UNSUPPORTED_TOPIC | 421 | Requested push on pubsub_topic is not possible as the service node does not support it. | | TOO_MANY_REQUESTS | 429 | DOS protection prevented this request as the current request exceeds the configured request rate. | | INTERNAL_SERVER_ERROR | 500 | status_desc holds explanation of the error. | | SERVICE_UNAVAILABLE | 503 | Lightpush service not available | @@ -66,7 +65,7 @@ If they are unable to do so for some reason, they SHOULD return an error code in ## Security Considerations Since this can introduce an amplification factor, it is RECOMMENDED for the node relaying to the rest of the network to take extra precautions. -Therefore Waku2 applies or will apply: +Therefore Waku applies or will apply: - DOS protection through request rate limitation on the service itself. - message rate limiting via [17/WAKU2-RLN-RELAY](https://rfc.vac.dev/waku/standards/core/17/rln-relay), applied via network membership subscription. From ed4e6465d641efff9ad93d38fbf1ad2d0995f633 Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Thu, 20 Jun 2024 14:34:39 +0200 Subject: [PATCH 04/10] Changed SERVICE_UNAVAILABLE to NO_PEERS_TO_RELAY according to review arguments --- standards/core/lightpush.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index a779074..d3c702f 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -53,12 +53,11 @@ If they are unable to do so for some reason, they SHOULD return an error code in |--------|------|------| | SUCCESS | 200 | Successfull push, response's relay_peer_count holds the number of peers the message is pushed. | | BAD_REQUEST | 400 | Wrong request payload. | -| NO_PEERS_TO_RELAY | 404 | Service node has no relay peers. | | PAYLOAD_TOO_LARGE | 413 | Message exceeds certain size limit, it can depend on network configuration, see status_desc for details. | | UNSUPPORTED_TOPIC | 421 | Requested push on pubsub_topic is not possible as the service node does not support it. | | TOO_MANY_REQUESTS | 429 | DOS protection prevented this request as the current request exceeds the configured request rate. | | INTERNAL_SERVER_ERROR | 500 | status_desc holds explanation of the error. | -| SERVICE_UNAVAILABLE | 503 | Lightpush service not available | +| NO_PEERS_TO_RELAY | 503 | Lightpush service not available as node has no relay peers. | > The list of error codes are not complete and can be extended in the future. From 1278f84f0ec1d41b522ee430550318a44a55b814 Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Fri, 21 Jun 2024 15:49:42 +0200 Subject: [PATCH 05/10] Update standards/core/lightpush.md Co-authored-by: Ivan FB <128452529+Ivansete-status@users.noreply.github.com> --- standards/core/lightpush.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index d3c702f..c998016 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -1,5 +1,5 @@ --- -title: WAKU2-LIGHTPUSH +title: WAKU-LIGHTPUSH name: Waku Light Push editor: Zoltan Nagy contributors: From b2fd96ad68fa1207dd3871874538993afe650cec Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Sat, 22 Jun 2024 01:19:21 +0200 Subject: [PATCH 06/10] Wrap up with last grammar check and explanation of relay_peer_count field. --- standards/core/lightpush.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index c998016..9ef8c79 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -16,7 +16,7 @@ previous version: `/vac/waku/lightpush/2.0.0-beta1` [19/WAKU2-LIGHTPUSH](https:/ ## Motivation and Goals Light nodes with short connection windows and limited bandwidth wish to push messages to other nodes in the Waku network to request message services. -A common use case is to request that service node to publish the message to a `11/WAKU2-RELAY` pubsub topic. +A common use case is to request that the service node publish the message to an `11/WAKU2-RELAY` pubsub-topic. Additionally, there is sometimes a need for confirmation that a message has been received "by the network" (here, at least one node). @@ -29,7 +29,7 @@ syntax = "proto3"; message LightPushRequest { string request_id = 1; - uin32 request_type = 10; // 10 Reserved for future `request_type`. Currently RELAY is only available service. + uin32 request_type = 10; // 10 Reserved for future `request_type`. Currently, RELAY is the only available service. optional string pubsub_topic = 20; WakuMessage message = 21; } @@ -38,14 +38,15 @@ message LightPushResponse { string request_id = 1; uint32 status_code = 10; // non zero in case of failure, see appendix optional string status_desc = 11; - uint32 relay_peer_count = 12; + uint32 relay_peer_count = 12; // number of peers, message is successfully relayed to } ``` ### Message Relaying -Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`. Depending on the network configuration, user may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). +Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`. Depending on the network configuration, the user may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). If they are unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. +Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity. ### Examples of possible error codes @@ -57,9 +58,9 @@ If they are unable to do so for some reason, they SHOULD return an error code in | UNSUPPORTED_TOPIC | 421 | Requested push on pubsub_topic is not possible as the service node does not support it. | | TOO_MANY_REQUESTS | 429 | DOS protection prevented this request as the current request exceeds the configured request rate. | | INTERNAL_SERVER_ERROR | 500 | status_desc holds explanation of the error. | -| NO_PEERS_TO_RELAY | 503 | Lightpush service not available as node has no relay peers. | +| NO_PEERS_TO_RELAY | 503 | Lightpush service is not available as the node has no relay peers. | -> The list of error codes are not complete and can be extended in the future. +> The list of error codes is not complete and can be extended in the future. ## Security Considerations From 6127e7a360d269aa3042b153a0f5b92402b1844b Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Sat, 22 Jun 2024 01:24:40 +0200 Subject: [PATCH 07/10] rename UNSUPPORTED_TOPIC to UNSUPPORTED_PUBSUB_TOPIC --- standards/core/lightpush.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index 9ef8c79..52c5bd2 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -45,7 +45,7 @@ message LightPushResponse { ### Message Relaying Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`. Depending on the network configuration, the user may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). -If they are unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. +If the node is unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity. ### Examples of possible error codes @@ -55,7 +55,7 @@ Once the relay is successful, the `relay_peer_count` will indicate the number of | SUCCESS | 200 | Successfull push, response's relay_peer_count holds the number of peers the message is pushed. | | BAD_REQUEST | 400 | Wrong request payload. | | PAYLOAD_TOO_LARGE | 413 | Message exceeds certain size limit, it can depend on network configuration, see status_desc for details. | -| UNSUPPORTED_TOPIC | 421 | Requested push on pubsub_topic is not possible as the service node does not support it. | +| UNSUPPORTED_PUBSUB_TOPIC | 421 | Requested push on pubsub_topic is not possible as the service node does not support it. | | TOO_MANY_REQUESTS | 429 | DOS protection prevented this request as the current request exceeds the configured request rate. | | INTERNAL_SERVER_ERROR | 500 | status_desc holds explanation of the error. | | NO_PEERS_TO_RELAY | 503 | Lightpush service is not available as the node has no relay peers. | From 103b6fccf0578864107df5e3c738af706716b64d Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Wed, 26 Jun 2024 14:05:52 +0200 Subject: [PATCH 08/10] Made relay_peer_count field optional --- standards/core/lightpush.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index 52c5bd2..9994953 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -38,7 +38,7 @@ message LightPushResponse { string request_id = 1; uint32 status_code = 10; // non zero in case of failure, see appendix optional string status_desc = 11; - uint32 relay_peer_count = 12; // number of peers, message is successfully relayed to + optional uint32 relay_peer_count = 12; // number of peers, message is successfully relayed to } ``` @@ -47,6 +47,7 @@ message LightPushResponse { Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`. Depending on the network configuration, the user may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). If the node is unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity. +The field `relay_peer_count` may not present or has the value zero in case of error or in other future use cases, where no relay is involved. ### Examples of possible error codes From b53d9627dd90b1c5e73a515d858627e1882dafef Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Fri, 28 Jun 2024 02:56:37 +0200 Subject: [PATCH 09/10] Apply suggestions from code review Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com> --- standards/core/lightpush.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index 9994953..23aab32 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -29,7 +29,7 @@ syntax = "proto3"; message LightPushRequest { string request_id = 1; - uin32 request_type = 10; // 10 Reserved for future `request_type`. Currently, RELAY is the only available service. + // 10 Reserved for future `request_type`. Currently, RELAY is the only available service. optional string pubsub_topic = 20; WakuMessage message = 21; } @@ -44,10 +44,13 @@ message LightPushResponse { ### Message Relaying -Nodes that respond to `LightPushRequest` MUST either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`. Depending on the network configuration, the user may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). +Nodes that respond to `LightPushRequest` SHOULD either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic` +or perform another requested service. +Services beyond [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) are as yet underdefined. +Depending on the network configuration, the lightpush client may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). If the node is unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity. -The field `relay_peer_count` may not present or has the value zero in case of error or in other future use cases, where no relay is involved. +The field `relay_peer_count` may not be present or has the value zero in case of error or in other future use cases, where no relay is involved. ### Examples of possible error codes From 7536fb69fb50c2345f9275824746a5d178f93804 Mon Sep 17 00:00:00 2001 From: NagyZoltanPeter <113987313+NagyZoltanPeter@users.noreply.github.com> Date: Fri, 28 Jun 2024 03:23:05 +0200 Subject: [PATCH 10/10] Formatting, added semantic breaks for better readability --- standards/core/lightpush.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/standards/core/lightpush.md b/standards/core/lightpush.md index 23aab32..75585e1 100644 --- a/standards/core/lightpush.md +++ b/standards/core/lightpush.md @@ -15,7 +15,7 @@ previous version: `/vac/waku/lightpush/2.0.0-beta1` [19/WAKU2-LIGHTPUSH](https:/ ## Motivation and Goals -Light nodes with short connection windows and limited bandwidth wish to push messages to other nodes in the Waku network to request message services. +Light nodes with short connection windows and limited bandwidth wish to push messages to other nodes in the Waku network to request message services.
A common use case is to request that the service node publish the message to an `11/WAKU2-RELAY` pubsub-topic. Additionally, there is sometimes a need for confirmation that a message has been received "by the network" (here, at least one node). @@ -44,13 +44,17 @@ message LightPushResponse { ### Message Relaying -Nodes that respond to `LightPushRequest` SHOULD either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic` -or perform another requested service. -Services beyond [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) are as yet underdefined. -Depending on the network configuration, the lightpush client may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)). -If the node is unable to do so for some reason, they SHOULD return an error code in `LightPushResponse`. -Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity. -The field `relay_peer_count` may not be present or has the value zero in case of error or in other future use cases, where no relay is involved. +Nodes that respond to `LightPushRequest` SHOULD +- either relay the encapsulated message via [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) protocol on the specified `pubsub_topic`
+- or perform another requested service. + `Services beyond [11/WAKU2-RELAY](https://rfc.vac.dev/waku/standards/core/11/relay) are as yet underdefined.` + +Depending on the network configuration, the lightpush client may not need to provide `pubsub_topic` ([WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)).
+ +If the node is unable to perform the request for some reason, it SHOULD return an error code in `LightPushResponse`.
+ +Once the relay is successful, the `relay_peer_count` will indicate the number of peers that the node has managed to relay the message to. It's important to note that this number may vary depending on the node subscriptions and support for the requested pubsub_topic. The client can use this information to either consider the relay as successful or take further action, such as switching to a lightpush service peer with better connectivity.
+>The field `relay_peer_count` may not be present or has the value zero in case of error or in other future use cases, where no relay is involved. ### Examples of possible error codes