Hi everybody,
yes I am indeed not a fan of opening thousands of ports within one NIP.
starryxzy summarized it perfectly in the Matric channel:
1. The Misleading Nature of NIP
The current NIP lacks a neutral stance, emphasizing only the positive aspects of this decision while rarely mentioning potential negative impacts. Since operators cannot fully understand all the implications involved, there seems to be no reason to vote against it.
2. The Misleading Nature of Port Descriptions
Binding specific ports to specific services in the narrative is fundamentally flawed. You can justify opening thousands of ports based on gaming requirements, but we have no way of knowing whether this simultaneously opens permissions for hundreds of other unintended services. Except for privileged ports, there is virtually no one-to-one mapping between ports and services.
To some extent, this answers Konstantin’s question: it’s not about which ports carry exceptionally high risk, nor is it about whether we should open ports for WhatsApp specifically—rather, it’s that we fundamentally don’t know what we’re actually allowing through.
3. Current Port-Opening Policy Lacks Security Logic
We’ve turned port-opening into a “dependent variable” of user growth and user demand. Clearly, the more users there are, the more services they use, and the more ports need to be opened. Port-opening doesn’t reflect security principles—instead, it appears to be a milestone tracking user growth and increasing demands.
Another self-contradiction we exhibit is that we’re actively soliciting opinions everywhere about which ports should (not must) be opened—as if our use of a whitelist isn’t a security strategy, but rather a sign of lack of imagination. It’s as though we simply don’t know what other ports should to be opened and require others to enlighten us.
4. Asymmetrical Operator Attitudes
First, there’s an inherent structural flaw: we allow mixnet nodes to decide the port policy for exit nodes (through voting). For mixnet nodes, this is a decision-making process that carries no direct risk for them. However, given the limited number of mixnet nodes, this hasn’t yet had a significant impact.
Second, only a minority of operators actively pay attention to their own node situation and the broader NYM ecosystem; most simply follow “herd behavior.” This is most evident in NIP-5 and NIP-6. In the NIP-5 example, when 57% of nodes completed voting, the final outcome was still unpredictable—we still didn’t know whether the new quorum threshold would settle at 15% or 20% (At that moment, the gap might only be several hundred thousand to over a million tokens.). It wasn’t until the 20% option gained a slightly noticeable advantage due to some unexpected factors (2-4%) that it won overwhelmingly, with final votes for 20% being twice those for 15%. This is clearly not a rational outcome.
The 57% refers to the proportion among nodes that actually voted, not the proportion of all nodes in the network. In NIP-5, over half of the nodes didn’t cast any votes at all.
5. Official Expectations in Voting
Claiming that the official team had no expectations regarding voting outcomes is simply dishonest. If this were a genuine need, having a vote rejected would mean some staff member would need to face users and explain that their request has been denied—and that’s not easy work, even setting aside the question of potential user attrition.
Through various interactions, the operator will sense the team’s expectations, and this will inevitably influence the final result.
6. The Core Contradiction
However, this inconvenience—a necessary consequence of abuse prevention—is an inherent trade-off built into the current system to support sustainable development of decentralized VPNs. Because decentralized VPN operators aren’t large enough in scale, they lack any bargaining power—providers can even terminate service without notification. If each node generates 10% monthly profit, single node can afford service termination at most once a year before falling into losses. Not to mention other potential legal issues.
Exit policy whitelisting should imply the principle of “no opening unless necessary,” where “necessary” means the threshold for changing rules should be very high, rather than a series of resolutions being initiated and passed at high frequency.
If we cannot decline user requests and honestly tell users what additional benefits a decentralized VPN offers compared to centralized VPNs, and what they might lose, we cannot resolve this contradiction.
I personally am not opposed to opening ports, and I believe most operators share this view—but with the prerequisite that these decisions must genuinely enhance the community’s overall interests, and that the process itself be necessary and deliberate. However, our current logic on the port-opening issue is extremely crude, or arguably doesn’t exist at all. I believe this point is equally indisputable.
**What I’ve stated above is simply a factual observation—it should not be viewed as an attack on any individual.
**
—-
This said, the vote has concluded and there isn’t much we can do. I am considering starting a “negative NIP” to have those ports closed again. It simply doesn’t make any sense to open thousands of proxy ports for one specific service that was requested by one single user…
Thanks Wunderbaer
Hermes Stakepool Germany