The IRCop Guide: Privileges, Commands, and Responsibilities

I got my first O-line in 1999 on a small Italian network running ircu. The admin gave me a two-sentence briefing: "Here's your password. Don't break anything." I promptly /killed someone who was annoying me in a channel, which caused a cascade of drama that took three days to resolve. Twenty-four years later, I've given O-lines to dozens of people, and I always brief them more carefully than I was briefed. Being an IRCop is a position of trust, not a trophy. Here's everything I wish someone had told me before handing me the keys.

What an IRCop Actually Is

An IRC operator (IRCop, oper) is a user with elevated privileges on an IRC server or network. The name is sometimes confused with channel operators (people with @ in a channel). They are completely different things. A channel operator manages one channel. An IRCop manages the server infrastructure.

IRCops can see things normal users can't: connection notices, link traffic, user IPs behind cloaks. They can do things normal users can't: disconnect users, ban IP ranges, change server configuration at runtime. On most networks, IRCops are volunteers who donate their time to keep the network running.

The IRC protocol defines the OPER command in RFC 2812. When you successfully authenticate as an oper, the server sets user mode +o on your nick. Other users can see you're an oper (your WHOIS shows "is an IRC operator" or similar). Some networks hide oper status from non-opers using configuration options.

Being an oper does not make you a channel operator in any channel. Oper status and channel modes are separate systems. An oper can override channel modes (depending on configuration), but doing so without good reason is considered abuse on every network I've been part of.

The /oper Command and Authentication

To become an oper, you send the OPER command with your oper name and password:

/oper myopername mypassword

If authentication succeeds, you receive user mode +o and (on most IRCds) a set of snomasks for server notices. The server logs the oper-up event.

The oper credentials are configured server-side. In UnrealIRCd:

# unrealircd.conf
oper marco {
    class opers;
    mask *@trusted-host.example.net;
    password "$argon2id$v=19$m=65536,t=3,p=4$...";  # Hashed
    operclass netadmin;
    swhois "is a Network Administrator";
    vhost "staff.mynetwork.net";
};

In InspIRCd:

# inspircd.conf

Key configuration points:

mask/host — Restricts which hostmasks can use this oper block. Even if someone steals your password, they can't oper up from a different host. Always set this. Use your BNC's hostmask or a cloaked vhost.

password hashing — Never store oper passwords in plaintext. UnrealIRCd supports argon2id and bcrypt. InspIRCd supports bcrypt, SHA-256, and HMAC-SHA256. Generate hashed passwords with the IRCd's built-in tool:

# UnrealIRCd
./unrealircd mkpasswd argon2id

# InspIRCd
./inspircd --mkpasswd bcrypt

Kill, K-Line, G-Line: The Enforcement Toolkit

These are the tools opers use to deal with abuse. Each has a different scope and permanence.

/KILL — Forcibly disconnects a single user. The user can immediately reconnect. KILL is for immediate disruption — a user is flooding right now, or a compromised account is actively attacking. It's a bandage, not a cure.

/kill baduser :Flooding the network
# User sees: "You have been killed by marco (Flooding the network)"
# User can reconnect immediately

/KLINE — Server-level ban. Bans a hostmask from connecting to this specific server. Does not affect other servers on the network. Duration can be temporary or permanent.

# Ban a hostmask for 24 hours
/kline +1d *@evil-host.example.com :Abuse

# Permanent kline
/kline *@evil-host.example.com :Persistent abuse

# CIDR kline
/kline +7d *@192.168.1.0/24 :Botnet range

/GLINE — Network-wide ban. Same as KLINE but propagated to all linked servers. Requires higher oper privileges. Use sparingly — a wrong GLINE affects users across the entire network.

# Network-wide ban for 7 days
/gline +7d *@*.compromised-isp.net :Network-wide ban - botnet

# Gline with CIDR
/gline +30d *@10.0.0.0/8 :Blocking private ranges

/ZLINE — IP-based ban. Blocks an IP or range before the user even completes registration. More efficient than KLINE for floods because the connection is dropped before the server processes a full handshake.

# Block a single IP
/zline +1d 203.0.113.42 :DDoS source

# Block a range
/zline +7d 203.0.113.0/24 :DDoS source range

/SHUN (UnrealIRCd-specific) — Silences a user or hostmask. They stay connected but can't send messages or join channels. Useful when you want to monitor someone without disconnecting them.

/shun +1d *@spammer-host.net :Spam investigation

The escalation ladder I follow: KILL first to stop immediate damage. If they reconnect and continue, KLINE the hostmask. If they shift to different servers, GLINE. If they use multiple IPs from the same range, ZLINE the CIDR block. Match the scope of the ban to the scope of the abuse.

Snomasks: Seeing What Others Can't

Server notice masks (snomasks) control which internal server events you see. When you oper up, the server typically sets a default snomask. You can adjust it.

# Set specific snomasks
/mode marco +s +cCkfje

# Common snomasks (vary by IRCd):
# c = local client connections
# C = remote client connections (from linked servers)
# k = kills and klines
# f = flood detection
# j = junk/rejected connections
# e = errors
# n = network (server links, netsplits)
# s = general server notices
# o = oper-ups and oper-downs
# G = gline activity

On UnrealIRCd, the snomask letters differ from InspIRCd. Check your IRCd's documentation for the exact mapping.

What you see with snomasks enabled:

# Example server notices (UnrealIRCd)
*** Client connecting: marco (user@host) [192.168.1.100] {class}
*** Client exiting: spamuser (user@host) [Excess Flood]
*** K-Line added by marco on *@badhost.com (reason: Abuse) [expires in 24h]
*** Flood detected from user@host [target: #channel] [type: msg]
*** Server link: leaf.eu.mynet.org -> hub.mynet.org (synced in 0.3 seconds)
*** Netsplit: leaf.us.mynet.org split from hub.mynet.org

Snomasks are your radar. Without them, you're flying blind. I keep connection notices (c/C) disabled on large networks because the volume is overwhelming — hundreds of connect/disconnect messages per minute. I enable them temporarily when investigating a specific issue. Flood and kill notices stay on permanently.

Oper Types and Permission Tiers

Not all opers should have the same power. A helper who handles user support doesn't need GLINE access. A server admin who manages the infrastructure doesn't need to interfere with channels. Modern IRCds support granular oper classes.

UnrealIRCd uses operclass definitions:

# unrealircd.conf
operclass helper {
    permissions {
        client { see { ip; }; };
        self { opermodes; };
        channel { see { whois; }; };
    };
};

operclass local-oper {
    parent helper;
    permissions {
        client { kill; };
        server {
            kline { add; remove; };
        };
        channel { override { op; }; };
    };
};

operclass netadmin {
    parent local-oper;
    permissions {
        server {
            gline { add; remove; };
            zline { add; remove; };
            spamfilter { add; remove; };
            rehash;
        };
        channel { override { *; }; };
    };
};

InspIRCd uses type blocks:

# inspircd.conf

The hierarchy I recommend for a mid-sized network:

Promote slowly. Start everyone as a helper. After they've proven reliable for a few months, consider local oper. Global oper is for people who have demonstrated judgment under pressure. Net admin is for people you trust with the network's existence.

Oper Abuse and How to Prevent It

Oper abuse is the single most common cause of network death. I've seen it kill networks with thousands of users. An oper who uses their privileges to settle personal disputes, silence critics, or favor their friends destroys trust. Once trust is gone, users leave, and they don't come back.

Forms of oper abuse I've witnessed:

• Killing a user for being annoying in a channel (this was my mistake in 1999)
• Reading private messages using server-level snooping
• Overriding channel bans to rejoin after being kicked by channel staff
• Gline-ing someone during a personal argument
• Using IP visibility from WHOIS to dox or threaten users
• Creating backdoor oper accounts for friends

Structural defenses against oper abuse:

Logging. Log every oper action — kills, klines, glines, channel overrides. Make these logs accessible to all opers, not just the admin. Transparency prevents abuse.

# UnrealIRCd oper action logging
log {
    source {
        oper;
        kline;
        gline;
        kill;
        override;
    };
    destination {
        file "logs/oper.log" { maxsize 10M; };
    };
};

Written policies. Have a document that states what oper powers may be used for and when. "Opers don't interfere with channel management unless there's a network-level threat" is a good starting rule. Channel ops manage their channels. Opers manage the network.

Peer review. For non-emergency actions (permanent glines, spamfilter changes, adding new opers), require discussion in the staff channel before execution. Emergency actions (active flood, DDoS, abuse) can be taken immediately and reviewed after.

Separation of powers. The person who manages the physical servers should not be the only person who can manage the network. If a single person controls both the hardware and the oper accounts, there are no checks on their power.

The Responsibilities Nobody Talks About

Here's what the IRC operator role actually involves day-to-day, beyond the glamour of having a fancy WHOIS line:

User support. People lose their NickServ passwords. They get locked out by SASL. Their client can't connect over TLS. They don't understand why they were banned. You help them. Patiently. Even when they're hostile.

Conflict mediation. Channel owners fight with their ops. Users accuse each other of harassment. Someone claims they were unfairly banned. You listen to both sides, check logs, and make a judgment. Sometimes there's no right answer.

Emergency response. It's 3 AM and a botnet is flooding every channel. Or a netsplit isolated half the network. Or someone found an exploit in your IRCd version. You wake up, fix it, go back to sleep, and do your day job in the morning.

Saying no. "Can you op me in #channel?" No. "Can you see what IP that user has?" No, unless there's a legitimate abuse report. "Can you kill that user, they're being mean to me?" No, use /ignore. Saying no is a large part of the job.

Documentation. Write down your network's policies, procedures, and configurations. When you eventually step down (and you will — burnout is real), the next person needs to be able to continue without you.

Being an IRCop is volunteer work that demands professionalism. The people on your network trust you with their privacy and their community space. Take that seriously.