View Issue Details

IDProjectCategoryView StatusLast Update
0006603unrealircdpublic2026-01-11 18:34
ReporterChris_dc Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0006603: Granular command control for SHUN (Stealth/Shadow-Shun support)
DescriptionHi,

I’m reaching out to request an enhancement to the current SHUN implementation. After some discussion in #unreal-support and comparing notes with other IRCds, it seems that UnrealIRCd is currently missing a critical tactical feature for modern network moderation: Shadow "Shunning".
The Problem: "The Ban-Evader Feedback Loop" - Currently, an UnrealIRCd shun is very "loud." If a shunned user tries to JOIN a channel, the command is blocked.

For persistent ban-jumpers and trolls, this is an immediate signal that their current identity (IP/Fingerprint) is burned. Their reaction is predictable:

- They notice they can't join.
- They immediately disconnect.
- They change their IP (VPN/Proxy/Tor) and return within seconds.
- The current system essentially "trains" the abuser to rotate their IP faster.

The most effective way to handle these users is to let them think their connection is working, while silently neutralizing their impact. We want them to JOIN channels successfully (so they stay on their current IP) and PART/QUIT normally and type messages that are silently dropped (the "void").

As long as the user believes they are still "in," they won't switch their IP. This keeps them contained and makes the moderator's life much easier.
This isn't a new concept; InspIRCd has had this solved for years via their shun module configuration. They use an enabledcommands directive:

enabledcommands="ADMIN OPER PING PONG QUIT JOIN PART"
notifyuser="no"

This allows admins to decide exactly how "invisible" the shun should be.

It would be ideal to have a similar granular control in the set block or a specific shun block:

set {
    options {
        shun-allowed-commands { "JOIN"; "PART"; "QUIT"; "PING"; "PONG"; };
        shun-notify-user no;
    }
}

Addressing Concerns (because it was mentioned on #unreal): During the discussion, it was mentioned that allowing JOIN could lead to join-flooding. However, UnrealIRCd already has excellent anti-flood and rate-limiting modules. Join-flooding should be (and already is) handled by those layers, rather than being a hardcoded side-effect of a shun. And, of course, backward Compatibility: The default could remain as it is now, so no existing setups break.

By making shuns configurable, we gain a powerful psychological tool against trolls. Instead of a "Hard Wall" that triggers an IP-switch, we get a "Silent Void" that keeps the abuser busy and localized.
3rd party modules

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2026-01-11 18:34 Chris_dc New Issue