10/Waku2: Update #661
10/Waku2: Update #661
Conversation
content/docs/rfcs/10/README.md
Outdated
| This is because during the direct connections peers utilize `PeerID` to identify each other, | ||
| therefore the service obtained in the protocol is linkable to the beneficiary's `PeerID` (which counts as PII). | ||
| For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics. | ||
| For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics(`contectTopic`). |
There was a problem hiding this comment.
I assume topics refers to contentTopic .
| This property indicates that no adversary can flood the system (i.e., publishing a large number of messages in a short amount of time), either accidentally or deliberately, with any kind of message i.e. even if the message content is valid or useful. | ||
| Spam protection is partly provided in `11/WAKU2-RELAY` through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) provided for by GossipSub v1.1. | ||
| At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score. | ||
| As such, subscribers are not re-identifiable from their subscribed topic IDs (`pubsub_topic`) as the entire network is linked to the same topic ID (`pubsub_topic`). |
There was a problem hiding this comment.
I am assuming topic IDs refers to pubsub_topic .
There was a problem hiding this comment.
Thanks for this. Approving as these changes are definitely an improvement. However, this RFC in general needs quite an extensive content review as it's outdated in many respects. Particularly we want to get rid of the "v2" qualifier for Waku. "Waku v1" is simply a legacy version of the protocol that's not in use anymore. For the sake of clarity of this document I don't think now is the time to change this yet, though.
content/docs/rfcs/10/README.md
Outdated
|
|
||
| (a) gossip domain | ||
| (b) discovery domain | ||
| (c) req/resp domain | ||
| (c) request/reply domain |
There was a problem hiding this comment.
I think we're trying to be consistent about calling this request/response domain
content/docs/rfcs/10/README.md
Outdated
| @@ -138,7 +143,7 @@ In addition to `/vac/waku/*` protocols, Waku v2 MAY directly use the following l | |||
| /ipfs/ping/1.0.0 | |||
| ``` | |||
|
|
|||
| for liveness checks between peers, or to keep peer-to-peer connections alive. | |||
| For liveness checks between peers, or to keep peer-to-peer connections alive. | |||
There was a problem hiding this comment.
This line is part of the sentence
Waku v2 MAY directly use the following protocols:
.... for liveness checks,
... with protocol IDs .... as basic means for capability discovery
so should not be capitalised or end with a full stop.
content/docs/rfcs/10/README.md
Outdated
| We plan to introduce a new Vac capability discovery protocol with better anonymity properties and more functionality. | ||
|
|
||
| # Transports | ||
| We plan to introduce a new Vac capability discovery protocol with better anonymity properties and |
There was a problem hiding this comment.
| We plan to introduce a new Vac capability discovery protocol with better anonymity properties and | |
| We plan to introduce a new Waku capability discovery protocol with better anonymity properties and |
Vac no longer accurate
| This property indicates that no adversary can flood the system (i.e., publishing a large number of messages in a short amount of time), either accidentally or deliberately, with any kind of message i.e. even if the message content is valid or useful. | ||
| Spam protection is partly provided in `11/WAKU2-RELAY` through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) provided for by GossipSub v1.1. | ||
| At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score. | ||
| As such, subscribers are not re-identifiable from their subscribed topic IDs (`pubsub_topic`) as the entire network is linked to the same topic ID (`pubsub_topic`). |
Co-authored-by: Hanno Cornelius <[email protected]>
There was a problem hiding this comment.
Thank you :). As Hanno said, this is an improvement, and it is ready to merge.
However, we need a follow up addressing deeper content issues along the lines of logical linking (language and refs to other specs), checking that specs build on each other in a logical way.
This level of depth is required for all the Waku RFCs we should overhaul.
And, as Hanno said, parts are outdated and need to be updated.
Might make sense to get back to /10 once the other RFCs have been updated.
|
Continue discussion: vacp2p/rfc-index#21. The RFC process has been changed separating raw specs and the draft/stable specs into different repositories. |
Updating 10/Waku2