Waku in hostile network environment

[fryorcraken]

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:

• Qualify the network conditions in which Waku should operate
• Understand how could Waku operate in such conditions
• Identify the gaps to make it happen

Network conditions

Internet access is unreliable or non-existent. This can have several forms:

• Blocking specific protocols such as DoH
• Blocking network traffic on given ports, etc (ie, Great Firewall of China, source needed)
• Blocking access to specific servers, e.g. Play Store, App Store, Signal Server, etc
• Total blackout: Internet infrastructure down, energy grid down

Impacts on Waku

Running Waku Software

• No internet access means no way to run Waku in the cloud
• Electricity needed to run Waku node.

Distribution of Waku software

Without internet, Waku software cannot be downloaded from a remote node.

Peer discovery

• DNS Discovery
  • js-waku needs DoH to use DNS Discovery
  • All waku software needs access to specific domain name to use DNS Discovery
  • Nodes listed in DNS record needs to be reachable to bootstrap a Waku node

Peer communication

• Nodes need to be able to connect to each other to communicate.

Waku operation

How to mitigate the impacts listed above?

Running Waku software

Devices that could be used:

• Mobile phones: Android, iOS
• Raspberry Pi and other small computer, using portable energy source
• Laptop (has battery)

Physical communication capabilities:

• WiFi: hotspots, mesh(?)
• Bluetooth mesh
• NFC
• portable storage: sd card, usb key

Distribution of Waku software

How to facilitate distribution of Waku software in such conditions?

• Investigate how others do it (this is not Waku specific)
• Self-sufficient bundling:
  • provide pre-compiled packages
  • Single file packages
  • Docker images
  • Compilation: can a tar,gz file contain all needed code? Can compilation be done offline with standard tools?
  • pre-installed raspberry pi sd card
• Broad distribution
  • App stores
  • Alternative distributions (website, github)
  • Decentralized distributions (IPFS)

Peer discovery

• Local broadcast discovery mechanism (mDNS)
  • mDNS in the browser? (to be investigated)
• Predefined location for peers
  • e..g running a hostpot, a list of local network peer available at https://<hostpot>:8080/waku/peers
• Bluetooth mesh/discovery (to be investigated)
• NFC contact

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:

• Alice joins Bob's hotspot
• Alice connects to nodes in the networks
• Alice retrieves and cache messages from Bob's network
• Alice sends (new) messages to Bob's network

What to qualify:

1. How does Alice connects to nodes in the network?

• Browser-to-browser
  • WebRTC SDP-less connection (assume cert found via discovery)
• Browser-to-service
  • How to do wss without certificate generation?
  • User accepts self-signed cert first?
  • WebRTC direct?
• Mobile-to-mobile
  • Direct TCP connection? Can it work with Waku React Native? Or does it need to be built in Swift/Kotlin?

2. How does Alice retrieves messages from Bob's network?

• Would doing one store query to any node found on the network considered enough?
• Can we expect nodes in the network to run store?
  • raspberry pi that acts as wifi/bluetooth hotspot + nwaku node store would work
  • What about a bluetooth mesh only made of mobile phones?
  • Run store in the browser? Useless is browser-to-browser not possible in this environment
  • Run store in mobile app?
  • Store query over NFC?
  • Dump store on sd card/usb key

2. How does Alice sends messages to Bob's network?

• First, detect dupes from store query.
• Use relay and assume it forwards?
• If less than 6 peer detected in the network. connect to each peer and use light push?
  • implies light push server support for all peers (mobile, browser)

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

• [1] https://ooni.org/post/2022-iran-blocks-social-media-mahsa-amini-protests/

Future steps

• [ ] service node packaging
  • [ ] Already WIP: Docker, linux distri, etc
  • [ ] Raspberry pi sd card preconfigured as wifi+bluetooth hotspot
  • [ ] iOS/Android app to make a mobile phone a hotspot + service node

Assuming WiFi hotspots first (easier):

• [ ] Investigate bootstrapping without DNS Discovery
  • [ ] mDNS with service node running on the network
  • [ ] mDNS with only mobile/browser nodes on the network
  • [ ] Other strategy for browser nodes
• [ ] Investigate zero-conf/zero-boostrap hybrid peer connections
  • [ ] Browser-to-service: wss with self-signed? WebRTC Direct?
  • [ ] Browser-to-browser: WebRTC without SDP exchange https://github.com/libp2p/specs/pull/412/files
  • [ ] Mobile-to-mobile: TCP connection in React Native/Swift/Kotlin
• [ ] Robust message exchange strategies
  • [ ] Usage of Store/FT-Store in this context
  • [ ] Usage of Relay
    • [ ] To send/forward cached messages
    • [ ] In a network with < 6 peers

Alternative transport protocols:

• [ ] Bluetooth
• [ ] NFC

[fryorcraken]

Todo:

• spam
• actions on packaging

[fryorcraken]

Todo: mobile as hotspot/service node

[mfw78]

LoRa may be another potential communication layer to add to the considerations.

[Menduist]

NFC / Bluetooth

NFC is really slow, don't expect to make any meaningful data transfer with it: 424 kbit/s within a distance of approximately 10 centimeters. Bluetooth can work, and would be cool to have.

[fryorcraken]

Ok. NFC might only be interesting for peer discovery then. Still worth considering due to the challenge of browser peer discovery.

[fryorcraken]

LoRa may be another potential communication layer to add to the considerations.

Interesting, are LoRa modules common on mobile phones? RPi? (only had a brief look)

[fryorcraken]

Next action:

• reference existing issues
• create some new issues

ETA to do said action: post devcon

[fryorcraken]

ETA to do said action: post devcon

Current focus is on proving Waku scalability. This can be reviewed later in 2023.