Waku in hostile network environment #140
Labels
milestone
Milestone issue with a subset of issues within a specific track
track:restricted-run
Restricted run track (Secure Messaging/Waku Product), e.g. filter, WebRTC
Problem
Waku aims to be censorship-resistant, enabling network participants to communicate without being censored by any actors, including
state actors.
During conflicts, authoritarian state actors can take down public infrastructure such as Internet access, DoH, etc [1] in a way to prevent people from communicating & organizing.
Several Waku protocols rely on Internet access to work (e.g. DNS Discovery, RLN), which brings the question on whether Waku could be used without internet.
The aim of this issue is:
Network conditions
Internet access is unreliable or non-existent.
This can have several forms:
Impacts on Waku
Running Waku Software
Distribution of Waku software
Without internet, Waku software cannot be downloaded from a remote node.
Peer discovery
Peer communication
Waku operation
How to mitigate the impacts listed above?
Running Waku software
Devices that could be used:
Physical communication capabilities:
Distribution of Waku software
How to facilitate distribution of Waku software in such conditions?
Peer discovery
https://<hostpot>:8080/waku/peers
Peer communication
In such scenario, it can be assumed that instead of running in one global network (the Internet), a Waku node will run a multitude of smaller network at various time (WiFi hotspots, NFC contact, bluetooth) and most likely remain offline most of the time.
How can we ensure the broadcast and transmission of messages in such conditions?
Because each network is separate and each peer is in a network only temporary, then every opportunity to exchange messages should be made.
High level:
What to qualify:
1. How does Alice connects to nodes in the network?
2. How does Alice retrieves messages from Bob's network?
2. How does Alice sends messages to Bob's network?
Other Considerations
Spam
Due to the lack of reliable internet connectivity, and hence access to the blockchain, RLN spam protection is less adequate, yes possible.
Access to the blockchain is needed to confirm members of the RLN groups, ie, being aware of insertions and deletions (slashing).
In a local network environment, a spammer would need to connect to the network to spam nodes. In the case of a public hotspot, a malicious agent could connect to the network and flood the nodes.
As users would be in the same area, it opens the door to in person authentication as a way to prevent spam.
Notes and links
Future steps
Assuming WiFi hotspots first (easier):
Alternative transport protocols:
The text was updated successfully, but these errors were encountered: