[Milestone] Waku in the Browser on Unreliable Network

[chair28980]

Milestone: https://github.com/waku-org/pm/milestone/22

Summary

During Hackathon, venue network and Internet access can be limited or unreliable.
Hackers mostly build web apps during hackathons, using js-waku in the browser.

Acceptance Criteria

• Provide stable local environment to developers that might not have connection to the main network.
• Investigate and if possible improve connectivity to main network in harsh environments such as when wifi is not stable or websocket connection glitches.
  • try to find problematic points: 2g internet, bad wifi (on/off etc);
    • search for mitigation;
  • investigate ability to use HTTP transport in libp2p:
    • investigate if HTTP and long polling is possible;
    • implement if possible;

Justification

Poor first impression with Waku during hackathons can lead to lower adoption rate.

Epics

• js-waku: [Epic: js-waku] Waku in the Browser on Unreliable Network #156
• nwaku:
• go-waku:
• QA:
• Docs:
• Eco-Dev:

[weboko]

Only actionable point from js-waku side - waku-org/js-waku#1834

[fryorcraken]

Only actionable point from js-waku side - waku-org/js-waku#1834

What about:

• libp2p over http long polling, does it exist, would it help?
• Is the issue with websocket maintaining or establishing a connection? if it's maintaining, could [Milestone] Composing Waku Protocols to Improve Reliability #114 help?

[weboko]

There is another part that people in general might face similar issues because they have 2g internet or as in India - bad wifi.

Let's formalize this Milestone to be like:
Provide stable local environment to developers that might not have connection to the main network.
Investigate and if possible improve connectivity to main network in harsh environments such as when wifi is not stable or websocket connection glitches.

Than would mean it includes following sub streams of work:

• provide local dev environment:
  • feat: create helper for running docker locally js-waku#1834;
• investigate and measure current websocket transport:
  • try to find problematic points: 2g internet, bad wifi (on/off etc);
  • search for mitigation;
• investigate ability to use HTTP transport in libp2p:
  • investigate if HTTP and long polling is possible;
  • implement if possible;

[chair28980]

Scope signed-off EU-NA pm 2024-02-19.

[alrevuelta]

unsure about

investigate ability to use HTTP transport in libp2p:

and note that https://github.com/waku-org/waku-simulator might cover the

provide local dev environment:

[fryorcraken]

Also note that WebRTC Direct is soon to be available in nim-libp2p that could help.
WebRTC direct is tracked with https://github.com/waku-org/pm/blob/master/ROADMAP.md#fqdn-less-browser-connections

[chair28980]

Comment originally from #123 (comment) meant for this thread:

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]

@LordGhostX has also experienced connectivity issues, he should test any solution we provide.

[fryorcraken]

Milestone descoped for now. I'd suggest to "close as not planned". Cc @chair28980