feat: parameterizable number of connections per IP

[richard-ramos]

Description

Matches waku-org/nwaku#2323

[status-im-auto]

Jenkins Builds

Click to see older builds (1)

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	a231905	#1	2024-01-04 20:34:24	~1 min	nix-flake	📄log

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	1252174	#2	2024-01-08 16:10:08	~1 min	nix-flake	📄log
✔️	0640af7	#3	2024-01-08 19:02:33	~1 min	nix-flake	📄log

[chaitanyaprem]

LGTM, left a minor comment.

[kaichaosun]

The IP based rate limit seems better apply to store (maybe also relay) protocol, as it mostly deploys in a server.
For other protocols, when used in client app like status, the user usually behind a NAT or VPN, which means same IP assigns to many users. Wondering what's the best practice for such scenarios?

[chaitanyaprem]

The IP based rate limit seems better apply to store (maybe also relay) protocol, as it mostly deploys in a server. For other protocols, when used in client app like status, the user usually behind a NAT or VPN, which means same IP assigns to many users. Wondering what's the best practice for such scenarios?

Here the limit is for any peer that is connecting to the node ir-respective of the protocol involved. This is to ensure that someone doesn't spawn too many peers in order to attack a node or mislead/coerce a node.

Wrt your query of nodes running behind a NAT or VPN, it is still fine. Because there would be other nodes in the network you can connect to as long as the network is sufficiently decentralized and has lot of nodes. This just prevents from more than n nodes with same IP connecting to same peer.