rfc/content/docs/rfcs/19
Aaryamann Challani 1e6b1b15b8
fix(48/RLN-INTEREP-SPEC): add to index, contributor fmt (#565)
* fix(48/RLN-INTEREP-SPEC): add to index

* fix(19/WAKU2-LIGHTPUSH): allow compilation
2023-01-12 16:00:09 +05:30
..
README.md fix(48/RLN-INTEREP-SPEC): add to index, contributor fmt (#565) 2023-01-12 16:00:09 +05:30

README.md

slug title name status editor contributors
19 19/WAKU2-LIGHTPUSH Waku v2 Light Push draft Oskar Thorén <oskar@status.im>
Daniel Kaiser <danielkaiser@status.im>

Protocol identifier: /vac/waku/lightpush/2.0.0-beta1

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

syntax = "proto3";

message PushRequest {
    string pubsub_topic = 1;
    WakuMessage message = 2;
}

message PushResponse {
    bool is_success = 1;
    // Error messages, etc
    string info = 2;
}

message PushRPC {
    string request_id = 1;
    PushRequest request = 2;
    PushResponse response = 3;
}

Message Relaying

Nodes that respond to PushRequests MUST either relay the encapsulated message via 11/WAKU2-RELAY protocol on the specified pubsub_topic, or forward the PushRequest via 19/LIGHTPUSH on a 44/WAKU2-DANDELION stem. If they are unable to do so for some reason, they SHOULD return an error code in PushResponse.

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.

Note that the above is currently not fully implemented.

Copyright

Copyright and related rights waived via CC0.

References