We agree that there are challenges to be solved to use Waku Relay in the browser in a scalable manner. These challenges also exist for other light nodes that share technical characteristics with the browser.
The recommendation is to use Filter + Light Push until solutions are implemented to make Relay scalable in the browser. Do note that Filter and Light Push come with security implications [1].
To paraphrase Waku v2 scalability studies - #5 by haelius
- Browser nodes do not connect to each other with the currently available transport protocols (tcp, websocket).
- Browser nodes do not advertise themselves via the currently available discovery protocols (static list, DNS Discovery, discv5).
- 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 Relay network.
Mobile node most likely share characteristics (1) and (2).
Here are potential solutions we will explore to remediate to the situation:
WebRTC
Solves (1).
Note: For a WebRTC handshake to happen, each party needs to communicate some signal data to the counterpart.
By integrating WebRTC in browser nodes, and enabling the transfer of signal data over Waku, then browser nodes would be able to connect to other browser nodes and hence remediate to the gossipsub mesh space depletion.
A browser node would still need to have a reliable connection to a service node to transfer the signal data to another browser node.
In terms of security implication, it may be acceptable to use light push + filter to transfer signal data as the service node would learn that said IP is attempting to setup a WebRTC connection but does not learn about the application usage of said IP.
Reviewing Waku v2 scalability studies - #6 by fryorcraken it would mean that a browser node would only need 1 or 2 Relay connections to service nodes and then connect to 4 other browser nodes via WebRTC to reach the recommended D value. Or potentially use Light Push + Filter to pass the signal data so most Relay connections could be to other browsers.
Peer Exchange “Push”
Solves (2).
A sister protocol of 34/WAKU2-PEER-EXCHANGE [2] where a browser node can push its ENR to a service node. This service node can then include this ENR to the next peer exchange response.
This would enable light clients to find each other.
Waku Browser extension
The solutions above do not resolve (3).
With WebRTC and a peer exchange push, it would take several rounds for a browser to connect to another browser and reach the recommended D value:
Actors:
- Alice (browser)
- Bob (browser)
- Carole (service node)
Steps:
- Alice connects to Carole
- Alice does a peer exchange request to Carole.
- Alice gets Bob’s details.
- Alice sends connection request over Waku to Bob (WebRTC signal data, over noise channel?)
- Bob responds with signal data
- Alice connects to Bob
Considering the number of round trip and the potential network latency, it could take in the order of several seconds for Alice to form a health gossipsub mesh.
By this time Alice might have decided to give up and close her browser tab.
A browser extension might remediate to this by taking the steps above upon starting the browser.
Meaning that while the browser is open, the Waku extension can setup connections and ensure that the node has a health gossipsub mesh before the user open the dApp.
This also helps with (2): While a user might open a dApp tab that needs Waku only for few minutes/seconds, their browser is likely to be opened most of the time.
In terms of UX, a user could be offered the following choice:
- No extension, dApp uses Filter + Light Push but it comes with privacy drawbacks
- No extension, dApp uses Relay but it takes time to setup the dApp when opening the tab
- Yes extension, maximize privacy + Waku is ready whenever the dApp is opened
The extension can use WebRTC to connect to other (browser) extensions.
While it is not possible to manage TCP extensions from a browser extension, it is possible to connect to a local REST API.
Meaning that the browser extension could connect to a local Waku node via the REST API to access the Waku network and provide it to the browser dApp.
The user could install a Waku node on their computer or a raspberry pi and leverage it when using a web dApp.
This is similar to connecting your Browser wallet extension to your own Ethereum node.
In term of UX, it adds a (4): Yes extension, Yes Waku service node: Run your own Waku service node, get rewarded, have an excellent connection to the Waku network and leverage it when using your favorite Waku web app.