Allow disabling of Relay

[neekolas]

This is a change request

Problem

The Waku Relay protocol will send every message on the pubsub topic (which in most Waku implementations contains every message on the network) over the wire to every connected Relay node. With even a modest amount of traffic this can overwhelm less capable devices. Particularly mobile. The network requirements for running Relay nodes on the server side also limit the number of active Relay connections per node to 12 before pruning kicks in. An app with even a few dozen concurrent browser users could overwhelm the network.

Now that js-waku supports the Waku Filter protocol, it is possible to run as a light node without relay. Messages would be retrieved using Store and Filter, and outbound messages would be sent via LightPush.

What we need is a mechanism to safely disable Relay without impeding the functionality of the other Waku protocols.

This would lead to a much more scalable network and a much more performant experience in mobile browsers.

Proposed Solutions

While it may be tempting to try and modularize Waku, so that only required protocols are ever imported or instantiated, I don't think that is necessary to get 99% of the benefits of disabling Relay. All that seems to be truly required is a configuration that configures libp2p without pubsub when the node is created, that disables Relay Keepalive, but that maintains the ability to bootstrap the node with peers that accept all the other protocols. We would also want to throw an error when a message is attempted to be sent via Relay with this configuration option enabled.

An additional CreateOption like lightNode: true or relay: false would be all the configuration needed for a minimal implementation of this change.

Are there other considerations that prevent us from giving users the option to disable Relay?

The reason I am not particularly concerned with modularizing all of the protocols is simply that the dependency overlap is so large between them, that even if we were able to tree shake out all unused protocols (which would almost certainly require significant API changes to remove the dependencies from waku.ts) the difference in bundle size would be negligible. All of the protocols require libp2p and it's associated libraries...which are huge compared to the protocols themselves. So, I'm perfectly fine with having Relay imported so long as the subscription is never initialized and we can avoid the network overhead.

Notes

• This should help considerably with the scalability limitations listed here
• /cc @D4nte as we have discussed this change a little while ago

[neekolas]

While I'm happy to help with the implementation of this feature, I suspect the VAC team has better knowledge of the gotchas and potential edge cases of disabling such a core feature of Waku.

[D4nte]

I agree with the problem statement and proposed solutions, including the tree-shakeable comment. Current libp2p protocols have overlaps indeed, which make tree-shakeability not that worthy It may make more sense to ensure that waku message version 1 & 2 are tree shakeable.

I am currently updating js-waku to the latest libp2p lib. This changes the API a fair bit. I can then look into this once done.