Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

12/WAKU2-FILTER: Update #119

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open

12/WAKU2-FILTER: Update #119

wants to merge 20 commits into from

Conversation

jimstir
Copy link
Collaborator

@jimstir jimstir commented Dec 26, 2024

An update of the 12/WAKU2-FILTER RFC. Some rearrange some sections, updated links and terms.

@jimstir jimstir requested a review from jm-clius January 17, 2025 14:57
Copy link
Contributor

@jm-clius jm-clius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, except for a few minor comments below. Feel free to merge once resolved. :)

which enables subscribing to messages that a peer receives.
This is a more lightweight version of [11/WAKU2-RELAY](/waku/standards/core/11/relay.md),
specifically designed for bandwidth restricted devices.
This is due to the fact that light-nodes subscribe to full-nodes and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This is due to the fact that light-nodes subscribe to full-nodes and
This is often used by lightweight nodes to subscribe to full Relay nodes and

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jm-clius As discussed prior, instead of using lightweight nodes, the suggested statement:
" This is often used by nodes with lower resource limits to subscribe to full Relay nodes and only receive the subset of messages they desire, based on content topic interest."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Sounds better!

Comment on lines 81 to 79
Any node running the `WakuFilter` protocol
i.e., both the subscriber node and the queried node are considered as an adversary.
Furthermore, we consider the adversary as a passive entity
that attempts to collect information from other nodes to conduct an attack but
it does so without violating protocol definitions and instructions.
For example, under the passive adversarial model,
no malicious node intentionally hides the messages
matching to one's subscribed content filter
as it is against the description of the `WakuFilter` protocol.
### Design Requirements

The following are not considered as part of the adversarial model:

- An adversary with a global view of all the nodes and their connections.
- An adversary that can eavesdrop on communication links
between arbitrary pairs of nodes (unless the adversary is one end of the communication).
In specific, the communication channels are assumed to be secure.
The effectiveness and reliability of the content filtering service enabled by the
`WakuFilter` protocol rely on the _high availability_ of the full nodes
as the service providers.
To this end, full nodes must feature _high uptime_
(to persistently listen and capture the network messages)
as well as _high Bandwidth_ (to provide timely message delivery to the light nodes).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove this entire section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants