chore: make the ip colocation parameter configurable

[Ivansete-status]

Background

It is interesting to make the IP colocation parameter configurable when the nwaku works behind a reverse proxy.

https://github.com/waku-org/nwaku/blob/master/waku/node/peer_manager/peer_manager.nim#L387-L390

Details

N/A

Acceptance criteria

The colocation parameter can be configured and disabled when set to 0.

[filoozom]

For some context: we're using a reverse proxy setup for our Waku nodes, which I would say is industry standard for most web (HTTP / WS) applications. This allows us to re-use the port for multiple services, manage certificates, do high availability / fail-over, etc.

The side-effect of this is that every connection originates from the IP of the reverse proxy, effectively reducing the maximum total connections to 5.

One step further to fix this issue would be to use the X-Forwarded-For header to see which IP the connection originated from. This would then be set by the proxy before forwarding the connection. This is a standard used by many applications that require the end-user's IP to be known while still being compatible with proxies. However, we can also do rate-limiting on our proxy, and I'd argue that the limit of 5 should be configurable anyways. For example, currently it's not possible to use Waku with more than 5 open tabs, which could be an issue in the long run or for automated tests for example.

So basically the proposed solution would be sufficient for our needs.

[Ivansete-status]

Weekly Update

• achieved: making ip colocation parameter configurable. If set to 0, the IP colocation limit is not applied.

[vpavlin]

Just a note from architecture perspective - what is the point of using Waku if the nodes are running on a single cluster behind a central proxy? I am trying to wrap my head around this and whether using p2p protocols this way is actually significantly beneficial to the network itself, for the users or devs.

What is the particular "use case" for Waku in this setup?

[filoozom]

what is the point of using Waku if the nodes are running on a single cluster behind a central proxy?

That's not (at least necessarily) the point. You can just use a reverse proxy to handle certificates, rate limiting, authorization and many other things. It can also be more practical depending on what infra you are running. On Kubernetes you can use CertManager, so maybe that's not a good example, but on Nomad it becomes difficult to manage Let's Encrypt certificates automatically for example. Certificates in particular are the use case we need it for. But each node has its own reverse proxy and its own Waku node, so there's no loss in decentralization.

Reverse proxies are also useful to be able to reuse port 443. This can be useful for a variety of scenarios like firewalling and networks that heavily block traffic to "unknown" ports.

For certain use cases it might also be useful to have a more consistent store, as Waku doesn't handle synchronizing, in which case a high available node might be useful. We haven't used it in this scenario, but I could imagine having several Waku nodes with a central Postgres database that would serve consistent data over the filter protocol. Of course, this would be quite centralized, but I guess it could be a middle step towards indexing services or for applications that rely on stable data.

[vpavlin]

🤦 right, sorry, my brain did not visualize the setup properly:) Obviously the problem happens with a single proxy per Waku node where the node sees the proxy IP as a source for all connections (which you said, but it did not translate correctly in my head). Gotcha

Yeah, the HA store node is definitely an interesting use case.

Pardon my ignorance, let's blame the 2023 for it! I'll think more before typing in 2024...

[mfw78]

This is also applicable for the dappnode case as well where dappnode can handle the SSL certification acquisition and proxying to the underlying waku node.