Following the inspiring Geminispace proposal by @Ch1ffr3punk, I would like to suggest making ports 6667 and 6697 available for the Nym community.
IRCv3 is a cool and Mixnet-friendly way to communicate, compared to centralized and bandwidth-heavy instant messaging platforms. It keeps the simplicity of classic chat, but adds modern essentials like SASL/CertFP authentication,message history, multi-client support, and native TLS encryption . It is lightweight by design and ideal for the latency profile of a mixnet.
Nym community members can run their own servers with minimal resources. Modern daemons like Ergo and InspIRCd make self-hosting straightforward and privacy-focused.
To see what modern IRC is all about, I encourage people to try an open source IRCv3 client like Goguma, Gamja, or WeeChat.
I believe IRCv3 would be a valuable addition to the Nym ecosystem alongside Geminispace. If you support this proposal, please share your feedback below.
If you look at the exit policy file, you’ll find this line:
#ExitPolicy accept *:6697 # IRC SSL (REJECT to AVOID Tor DNSBL)
It’s commented out, and the reason is written right there: Tor DNSBL.
When Tor exit nodes started getting used for IRC botnet command-and-control, IRC networks responded by blocklisting all Tor exit IPs.
Tor exit operators got banned from IRC en masse. The Nym team was right to be cautious, nobody wants to inherit that mess.
But here’s the thing: that problem is specific to Tor’s architecture, not to anonymity networks in general.
Tor is an open proxy. Anyone can use it for free, no questions asked, no credentials, no limit on how many circuits you spin up.
That’s exactly what made it attractive for botnet operators.
Nym works differently. Access requires zk-nym credentials ,you can’t just point thousands of clients at the network without tickets. The existing IP denylist (Spamhaus SBL/PBL) already blocks the known botnet infrastructure at the network level.
And this proposal is for port 6697 only, TLS-encrypted IRC. Port 6667, the plaintext port that botnet C2 traffic historically runs on, stays closed.
The Tor DNSBL concern is real. It just doesn’t apply here.
I wrote a longer piece explaining what IRCv3 actually brings to the table,for anyone who wants context on why this protocol is worth routing over a mixnet.
The article covers capability negotiation, SASL EXTERNAL (certificate auth,no password in transit), STS (IRC’s equivalent of HSTS), message tags,server-side CHATHISTORY with configurable retention, and MONITOR for presence without polling.
The argument at the end is the relevant one for this community: IRCv3 is implementable, auditable, self-hostable, and federates without a central authority.
A client that speaks IRCv3 is a few thousand lines of code and a TCP socket, no SDK, no binary protocol, no platform dependency.
i’m very happy if you take in consideration my NIP.
I’m running an Ergo IRCv3 instance already accessible via a Tor hidden service.
The goal of this NIP is to enable the same access path over Nym instead.
Ergo handles TLS natively on 6697.
If the NIP discussion is easier with a single port, I’d suggest limiting the request to 6697 only and dropping 6667 entirely , plaintext IRC over a mixnet doesn’t make sense anyway.
Happy to provide test endpoints or run a live demo if that helps the decision.
Great news that NIP-12 passed and that the NTM side already shipped.
I noticed PR #6855 merged on June 24th adds IRCv3TLS (6697) to the NTM allowlist alongside EufyTLS and FiveMGameServer.
I’m testing an IRCv3-over-Nym client that goes through nym-socks5-client (Network Requester path), and as of today the public exit policy at https://nymtech.net/.wellknown/network-requester/exit-policy.txt is still showing v1.9.0, 20th May 2026, with #ExitPolicy accept *:6697 still commented out.
Since NTM and the Network Requester exit policy are separate systems , could you confirm whether the exit-policy.txt update is still pending, and if there’s an ETA? Happy to help test as soon as it’s live. I have a working client ready to go (nirc, tested end-to-end over a direct TLS connection, just waiting on the mixnet leg).
Quick guess in case it helps: PR #6855 seems to have only updated the NTM allowlist, not the
exit-policy.txt itself, might be two separate pipelines that need syncing.
No rush, I’ll keep an eye on the .txt and report back once 6697 goes live. Client’s ready to go
whenever it is.
