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.
