[Milestone] Waku Relay and Discv5 in a Hostile, Restricted or Subpar Online Network

[chair28980]

Milestone:

Summary

Proceed with a multi-client analysis of Waku Relay's performance in a somewhat online hostile or subpar network and the ability for a relay node to remain connected when said network:

• Hackathon with poor internet connectivity
• prevent incoming connections
• Usage of proxy or VPN to access Internet
• Mix of WAN/LAN configuration.
• Usage of IPV6

Note: Bluetooth, network mesh and internet outage are not in the scope of this milestone.

Justification

Epics

• research:
• js-waku: research usage of http in jslibp2p
• nwaku:
• go-waku:
• QA:
• Docs:
• Eco-Dev:

[weboko]

We observed this happening in ETH India with thousands of participants not being able to reliably sending data over Waku.
Primary problem was - many hotspots in the area.

From js-waku perspective I don't see it being actionable as the link between local router and a device was not stable itself.
The only way to mitigate it could be switching from WebSocket connection and using REST in a new way:

• enabling long polling on REST;
• building adaptors to use REST interchangeably with WebSocket in js-waku codebase;

Another way of improving it could be pushing towards adoption of Relay in browser and adding bluetooth support 😄

[fryorcraken]

Note the comment above is actualyl for #137

I split the milestone because browser is more urgent.

There is another path which would be to run a nwaku node in such network and ensure that this node advertise a dialable multiaddr to the WAku network so that the browser node could find this local node via peer exchange.