[Epic] Waku Relay scalability in the Browser

[fryorcraken]

Problem

See https://forum.vac.dev/t/waku-v2-scalability-studies/142/9?u=fryorcraken for original post

tl;dr:

1. Browser nodes do not connect to each other with the currently available transport protocols (tcp, websocket).
2. Browser nodes do not advertise themselves via the currently available discovery protocols (static list, DNS Discovery, discv5).
3. If browser nodes were to advertise themselves, because of the ephemeral nature of a browser tab being opened, they would likely to poorly contribute to the Waku Relay network.

Proposed Solutions

0. Make Relay Production Ready

• bug: inconsistent messages on eth-pm examples.waku.org#199
• investigate alternative to relay pings/why we need them #1349

1. Enable browser to browser connection

• browser-to-browser connection using WebRTC:
  • WebRTC Exploration #20
  • Waku Socket (better name pending) #681
  • WebRTC for Waku #1181
• browser-to-node connection using WebTransport?

Ref libp2p/specs#220

2. Peer Exchange "Push"

Once browser-to-browser connection is possible, then browser need to advertise themselves in way that works for short live nodes.

• Peer exchange push RFC
• Implement it 34/WAKU2-PEER-EXCHANGE #910
• More dogfooding Dogfood peer-exchange curation in web-chat example #1309

3. Waku Browser Extension

• Scope and create a PoC that uses browser-to-browser connection
• Scope and create a PoC that uses a local/user control service node to access the Waku network

Notes:

• usage of the extension should be pseudo-transparent to the developer
• Waku apps with a browser such as Status could provide an interface equivalent to the extension

[weboko]

Weekly update

• achieved: draft of direct browser-browser RTC example feat: add direct relay-rtc example examples.waku.org#260
• next: improve the example (connection re-usage), work on contentTopic based RTC example

[fryorcraken]

Need to review this:

1. new transport protocols (webrtc browser<>server, webtransport) are likely to be used for Waku scalability in general so that browser nodes can connect to status desktop nodes
2. relay in the browser is more for a privacy focused item, probably better handled in 2024. It is also a very watched/requested topic, so it could somehow fall under making js-waku relevant for the projects using it

For now, let's continue on the current work wich aims to chip a PoC that run Waku Relay over WebRTC to other node. Once done, we can review the work we want to do this year.

[weboko]

Weekly update:

• achieved: complete PoC of Waku Relay over WebRTC using circuit relay
• next: pause this to prioritize Waku Network milestone

[danisharora099]

As a part of this epic, we should also track work around looking into implementing other more reliable NAT traversal techniques by libp2p like:

• autonat (https://github.com/libp2p/specs/tree/master/autonat)
• circuit-relay v2 (https://github.com/libp2p/specs/blob/master/relay/circuit-v2.md)

Both of these have support for js-libp2p in browser and might help with NAT traversal, along with WebRTC

[fryorcraken]

Icebox'd, see waku-org/pm#50 (comment)