App icon

Help for IRCD Server/Simulator


IRCDSS is an IRCD server and simulator for the Windows OS (Windows 7 or later) that supports IPv6, SSL/TLS and Unicode®. It enables you to do the following:

  • Test IRC clients without going online to an external network.
  • Join predefined test channels with simulated users that JOIN, PART, issue CTCP ACTIONs, and chat on topics simulated by a Markov chain text generator.
  • Learn how to use your IRC client by practicing any IRC commands without making yourself a nuisance on an external network, where you might get kicked, banned or even K-lined.
  • Try IRC operator functions that are rarely available to ordinary IRC users.
  • Try channel management using channel operator status.
  • Run a local IRC network with real chat channels by running IRCDSS on a local machine, without the need to deal with the installation and configuration issues of a Linux® IRCD.

The acronym "IRCDSS" represents the following:

Internet Relay Chat
Daemon, which is a type of background process on Linux® systems,
equivalent to Windows Services.
Server - a program that provides functionality for one or more client programs via internet sockets,
on a Windows platform.
Simulator - this software simulates the functionality of the Linux® IRCD server software,
as well as the actions of simulated users,
while running as an ordinary program on a Windows platform.

IRCDSS is free software for general use.

IRCDSS is designed to mimic the behaviour of commonly used IRC server networks so as to be compatible with existing IRC client software and to be representative for test purposes. Ultimately, it derives from the original work of Jarkko Oikarinen who created the original IRCD software in 1988. Consequently, it relies strongly on the core internet request-for-comments documents that describe the IRC protocol: RFC 1459, RFC 2810, RFC 2811, RFC 2812, and RFC 2813, along with popular extensions such as relational parameters for LIST, host hiding and login-on-connect.

IRCDSS supports named channels and allows the use of channel prefixes '&', '#', '+' or '!', with functionality implemented for '+' channels that limit the use of channel modes.

IRCDSS is a standalone server which does not support server-server links. This means that it is perfectly good for running test networks and small local networks, and is not susceptible to the problems of synchronising multi-server networks such as net splits. Neither does it need an overarching network management setup to control multiple servers.

IRCDSS supports IPv4 and IPv6 transparently, in other words, you can connect to the same server with a client using either protocol.

IRCDSS supports Unicode® by translating between internet octets treated as containing UTF-8 encoding, and internal representations of Unicode® text, thus supporting any IRC client that provides the same support.

IRCDSS supports SSL/TLS connections as supported by OpenSSL version 1.1.1b (26 Feb 2019), which includes TLSv1.3.

IRCDSS version 1.3 was upgraded to OpenSSL 1.1.1h. Version 1.1.1 is a Long Term Support version, which will be supported until 2023-09-11.



Getting Started


Unpack and run the installer (setup.exe). If you have a previous installation it might say "Select whether you want to repair or remove IRCDSS", or display a message asking you to use "Add or remove programs" to remove the old version. If there is an old version, it is best to use the Uninstall Programs feature of the Control Panel, or search "Add or remove programs" from the Windows prompt, to remove the old version.

Follow the instructions to install IRCDSS. Normally the default settings for install location and "install for everyone" should be OK.

You should then be able to run IRCDSS either from a desktop icon or a Start menu program link that refers to "IRCD Server/Simulator".

It is recommended that the 32 bit and 64 bit versions should not both be run at the same time as they use the same APPDATA files. However, running one only at a time should be OK.

If the installation or uninstallation fails part way through, it may be possible to rectify the problem by restarting Windows and then try the installation or uninstallation again.

Starting a server

Select the main menu command "IRC/Start Server (Non-SSL/TLS)", or "IRC/Start Server (SSL/TLS)". There should now be a listing in the listview control on the left and some debug lines in the edit box on the right. The server is now running and should be ready to take connections via the IP address of the computer that is running it. You will need a separate IRC client to connect to the server and begin testing or chatting. If the client is on the same computer, you can connect to "localhost" or "::1", otherwise you need to connect to the computer's IP number or hostname as seen from the other computer.

Your client connection must be made using either a non-SSL/TLS or SSL/TLS mode to match the mode that the server was started in, and connect to the corresponding port for that mode (as set by the "IRC/Server Port and SSL/TLS settings" dialog).

The running app appears initially with an empty servers listview on the left, and a text window on the right, with an adjustable vertical divider between them. The screenshot shows an active server running and listed in the listview, with one client connection. The listview columns show the following information:

  • No. - the number of the server in the list
  • Service - type of service, i.e. IRC
  • Port - port the server listens on
  • Address - <NULL> means server will accept connections from any local or remote client
  • No. of listening sockets - should be one for each protocol available
  • SockType - TCP
  • Family - PF_UNSPEC (IPv4 or IPv6 allowed)
  • No. of connected sockets - shows number of clients connected
  • SSL/TLS - shows "Yes" for an SSL/TLS server, and "No" for a non-SSL/TLS server

The text window shows debugging and status information. The types of information shown can be controlled using the options on the Server Logging Options dialog.

You can right click on a server listview row to bring up a popup menu, which has an "End" command that will stop the server.


Back to Top

Basic IRC concepts

"IRC" stands for Internet Relay Chat. It enables people to chat to multiple other people in managed, topic related channels "live" via the internet by sending text messages from their computers.

IRC chat is conducted by entering lines of text which are relayed to the other users in the channel. Action commands can be used to change the display format along the lines of "<nickname> does something".

IRC clients usually provide additional commands for convenience, that are prefixed with a '/' and are translated to the relevant IRC protocol. For example, you would type "/whois <nickname>" for information about a particular user.

IRC Clients also add useful client-to-client protocol facilities such as the ability to chat and transfer files directly, bypassing the server.

User Nick names

Each user on a network has their own unique nickname. This is often limited to 9 characters, but some networks allow more - often 15. The nickname is what is normally used to identify you in a channel. You may have a separate username for logging in to account services.


IRC operators (IRCops) manage the IRC servers. Channel operators (chanops) manage individual channels on an IRC network.


Users can join a channel using the JOIN command and can send and receive messages which are displayed in the channel for all users to see. Users can join multiple channels, and discover what channels are active using the LIST command.

Channel names begin with a channel prefix, which is the character '#', '&', '+' or '!'; the '#' form is the most common and means that the channel is available on all servers in the network. '&' channels are restricted to the local server, and '+' channels are preset to mode 't' and their modes can not be changed. As IRCDSS is standalone, there is no practical distinction between '#', and '&' channels.


Modes, specified by single letters, allow various characteristics of users and channels to be modified. For example, users can set the 'i' mode to make themselves "invisible", and the 'x' mode to hide details of their internet host. Channels can have modes set such as 't' to limit topic changes to channel operators, 'b' to add a ban mask to prevent nuisance users from joining, and users with mode 'o' have channel operator status. For further details, see the MODE commands in Commands

Back to Top

Main Menu



Shuts down all servers and closes the app.


Start Server (Non-SSL/TLS)

Starts an IRC server to listen on a configured port (defaulting to 6667).

Start Server (SSL/TLS)

Starts an IRC server to listen on a configured port (defaulting to 6697) for connections secured by SSL/TLS protocols.

Stop All Servers

Stops all running servers. A server can also be stopped by right clicking on the row in the servers listview, and clicking "End".

Server Logging Options

Opens a dialog to modify server logging options.

The text window shows debugging and status information. The types of information shown can be controlled using the following options on the Server Logging Options dialog:

  • Show data file loads - data files used by the server for predefined channels, except #Test
  • Show server events - messages about events from the server socket
  • Show server stops - server shutdown events
  • Show received messages (except PONG) - data received from clients
  • Show parsed messages - separated components of client messages
  • Show received PONG messages - client replies to periodic PING messages
  • Show Markov text generator fails - errors that occasionally occur due to failure to construct suitable text, which can usually be ignored.
  • Show SSL/TLS debug messages - verbose information about SSL/TLS connections

In addition, error messages are always shown, although this should be a rare occurrence, in which case a bug report containing the details would be appreciated.

Server Port and SSL/TLS Settings

Opens a dialog to select the ports to listen on, and additional SSL/TLS settings as follows (SSL/TLS settings do not apply to a non-SSL/TLS server):

  • Port (non-SSL) - This is the port that a non-SSL server will listen on.
  • Port (SSL) - This is the port that an SSL/TLS server will listen on.
  • Use software generated certificate: Instead of using server certificate files, a self-signed certificate and key are generated in memory by the application;
  • Verify peer: Check this for the server to reject a connection from a peer client if it supplies an invalid certificate
  • PEM certificate password: If your private key is encrypted, you need to supply its password. PEM encoding is used for various X.509 files which contain ASCII (Base64) encoded data, whose file extensions may be .PEM, .CRT, or .KEY. No password is required for the demo certificates supplied with the program.

Server SSL/TLS Certificate file settings

Opens a dialog to allow the file names of the Trusted CA Certificates file and the server certificate and key files to be changed.

These files are kept in the application-specific %APPDATA% folder, and sample files are installed when the app is first run. You can replace these files with your own versions with the same names, or with different names alongside the originals. This dialog allows you to change the file names used so that you can select a different set of certificate files. The %APPDATA% folder can be opened in Windows Explorer using the "Open %APPDATA% location in Explorer" button.

The three files are as follows:

  • Trusted CA certificates file: A store of trusted public Certification Authorities (CA) used to validate client certificate digital signatures.
  • Server certificate file: The server's certificate which a client may use to identify the server and validate against its own trusted CA store. Note that the demo certificate supplied is signed by a demo CA, which is not a public CA.
  • Server key file: The private key file used in conjunction with the server certificate. You should ensure that its location is only accessible to trusted personnel. The demo key file should only be used for private testing and evaluation. For operational use you would generate your own certificate and private key, have your certificate signed by a public CA, and keep your private key under tight security - it is not disclosed to the public CA.

For further information, see the section on SSL/TLS.

SSL/TLS software certificate settings

Opens a dialog to allow the X.509 certificate attributes used when a software generated certificate is used to be selected.

An X.509 certificate contains a number of fields, amongst which the Subject field contains Relative Distinguished Name (RDN) attributes commonly used for identification.

  • CN: CommonName
  • OU: OrganizationalUnit (often left blank)
  • O: Organization
  • L: Locality
  • S: StateOrProvinceName
  • C: CountryName - a 2 letter ISO-3166 country code, e.g. US

The validity period is automatically set to a Not Before date of the present time, and a Not After time that is 365 days later.



Opens the About dialog, which shows the software version, Winsock version, application architecture, system information, build date, OS version, app developer's website, and credits

Help File

Opens the HTML help file in your default browser.

Back to Top


Clients communicate with the server by sending commands, which may or may not generate a reply (Client to server communication should be considered essentially asynchronous).

Each message from the client normally consist of a keyword command, such as the ones described below, which is followed by command parameters (limited to a maximum of fifteen) in a line oriented format. The normal delimiter character is an ASCII space character. A parameter prefixed by a colon (':') is considered to run to the end of the line, so that it may include embedded spaces.

Note that as IRCDSS is currently a standalone server that does not support server-server links, therefore commands and parameters that refer to other servers are not necessary and are not supported.

The syntax used to describe the command parameters follows that used in the IRC RFCs, and is described in "Augmented BNF for Syntax Specifications: ABNF" - RFC 2234.

Connection Registration Commands


PASS is optional but must be sent before sending the NICK/USER combination.

Parameters: <password>

Supports the login-on-connect (LoC) protocols, using one of the following forms sent in place of the <password> parameter:

Connect without usermode +x but not if login server is unavailable:
-x+! myUser myPassword

If '!' is specified, an incorrect user/password login will result in disconnection rather than connection to the server without user login.

Connect without usermode +x including when login server is unavailable:
-x myUser myPassword
Note: Same result as: -x-! myUser myPassword

Connect with usermode +x but not if login server is unavailable:
+x! myUser myPassword

Connect with usermode +x including when login server is unavailable:
+x myUser myPassword
NOTE: Same result as: +x-! myUser myPassword

If 'x' is not specified, defaults to "+x"

If '!' is not specified, defaults to "-!"

Alternative colon or space separator format:
!account:password   ← Note in this case there must be no delimiter after the '!'

The LoC protocol allows clients to log in during the connection process, equivalent to using the AuthServ command "AUTH <accountname> <password>".

Clients can often connect to IRC networks without needing a server password provided by PASS, or equivalently the password is simply unused. Login to an account managed by the AuthServ user/bot allows users to use the channel management services of ChanServ/X, such as typing "!OP" to get channel operator privileges when joining a channel where you have the appropriate rights.

IRC networks commonly require registration of AuthServ accounts via a separate website; for test purposes the AuthServ account is defined for IRCDSS by an "A" line in the Settings_M_N_O_P.conf file (see Settings Files).


Parameters: <nickname>. The <hopcount> parameter is not supported.

During login, if the nick already exists the server replies with a 433 message "Nickname is already in use" and the client should send another "NICK" command with an alternate nickname.


Parameters: <user> <mode> <unused> <realname>

Supplies the client user name, mode and real name during login. Identd checking is not currently supported - in line with this, the user name will be automatically prefixed by the tilde character "~" by the server.


Requests IRC operator status.

Parameters: <name> <password>

If the parameters match the nickname and password in the "O" line of the ircd.conf file, the client is registered as an IRC operator.

MODE (user)

MODE allows users to query and change the modes of a channel or user. The following describes the options applying to users:

Parameters: <nickname> *( ( "+" / "-" ) *<modes> )

A "+" sign before the mode letter sets the mode, a "-" sign removes the mode. This option persists for subsequent mode letters until the next sign character.

i - marks a user as invisible

o - operator flag (User may set -o, but not +o, unless they are IRC operators)

s - marks a user for receipt of server notices ("Obsolete")

w - user receives wallops

r - restricted user connection (User may set "+r", but "-r" will be ignored, unless they are IRC operators)

x - enable host hiding


Terminates the client session with the server, with an optional "quit message".

Parameters: [ <Quit Message> ]


Not implemented: Command used to disconnect server links.

Channel operation commands


Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] ) / "0"

Joins channels, which may be given as a comma delimited list of channels, with a second optional parameter containing a comma delimited list of channel keys. This message also accepts a special argument ("0"), which causes the user to part from all channels the user is currently a member of.


Parameters: <channel> *( "," <channel> ) [ <Part Message> ]

Parts from a channel or comma delimited list of channels, with a second optional parameter containing a parting message.

MODE (channel)

MODE allows users to query and change the modes of a channel or user. The following describes the options applying to channels:

Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )

A MODE command with only the <channel> parameter requests the currently set channel modes and channel creation time.

A MODE command including <modes> sets or requests channel modes depending on the mode letter and parameters present.

A "+" sign before the mode letter sets the mode, a "-" sign removes the mode. This option persists for subsequent mode letters until the next sign character.

Modes without parameters:

+i - channel is invite-only

+m - channel is moderated

+n - messages to channel from external clients are not allowed

+P - channel is permanent

+p - channel is private

+s - channel is secret ("p" and "s" may not both be set)

+t - Makes the topic settable only by chanops (the only mode allowed for '+' prefixed channels, which is preset)

Modes with parameters:

+b <ban mask> - set a ban mask (e.g. nick!user@host) which blocks users from joining the channel. Some clients may show a 'b' in the topic information / channel modes to indicate that a ban was set, but if you part and rejoin, the existence of a ban list is not normally reported so the 'b' will not persist.

+I <invite mask> - set an invite mask (formatted similar to ban mask) which automatically allows users to join an invite-only channel. Like ban masks, this sets up a list at the server and the 'I' may be shown in the topic information / channel modes until you part and re-join, depending on the client.

+k <key> - Set a channel key e.g. MODE #42 +k oulu [-k must give matching key]

+l <number> - channel is limited to <number> users maximum

Modes that apply to channel members for the specified channel only (these do not show as a channel mode):

+o <nick> - give <nick> channel operator status

+v <nick> - give <nick> voice status


Sets the topic for the specified channel. If there is no <topic> parameter given, the server replies with the current topic and the RPL_TOPICWHOTIME reply.

If the <topic> parameter is an empty string (i.e. using only the colon prefix), the topic for that channel will be removed.

Parameters: <channel> [<topic>]


Shows the nicks of all visible users on a channel, or a comma delimited list of channels.

Parameters: [ <channel> *( "," <channel> ) ]

If no <channel> parameter is given, a list of all channels and their occupants is returned, plus a list of users who are visible but not on a channel.

The <target> parameter is not supported.


Lists channels on the server.

Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]

If no parameters are given, all channels are listed.

A comma delimited list of channels may be given, in which case details of those channels are listed.

Alternatively a comma delimited list of relational parameters may be given in the following format:

>100 lists channels with >100 visible users
<10 lists channels with <10 visible users
C>15 lists channels that have existed for more than 15 minutes
C<30 lists channels that have existed for less than 30 minutes
T>45 lists channels whose topic was last set more than 45 minutes ago
T<60 lists channels whose topic was last set less than 60 minutes ago

Example: LIST <3,>1,C<10,T>0

The <target> parameter is not supported.


The INVITE command is used to invite a user to a channel. The parameter <nickname> is the nickname of the person to be invited to the target channel <channel>

Parameters: <nickname> <channel>

Inviting to a non-existent or invalid channel is not supported. In addition, for clients with IRC operator status, INVITE <nickname> will list the invited channels for user <nickname>.


Makes the user PART from a channel by force.

Parameters: <channel> *( "," <channel> ) <user> *( "," <user> ) [<comment>]

There MUST be either one channel parameter and multiple user parameters, or as many channel parameters as there are user parameters. An optional "comment" or reason parameter may be given.

Message sending commands


Sends a message to a nickname or channel that other users can see.

Parameters: <msgtarget> <text>

<msgtarget> may be a comma delimited list of recipients.


Sends a message to a nickname or channel

Unlike PRIVMSG, automatic replies (e.g. ERR_NOSUCHNICK, ERR_NOSUCHCHANNEL, ERR_NOTONCHANNEL, ERR_CANNOTSENDTOCHAN), are never sent in response to a NOTICE message, except for the ERR_NORECIPIENT, or ERR_NOTEXTTOSEND replies if parameters are missing.

Server queries and commands


Gets the "Message Of The Day" file from the server.

The <target> parameter is not supported.


Gets statistics about the size of the IRC network. The <mask> and <target> parameters not supported. This includes the number of users and invisible users, the number of servers (1 in this case), the number of operator(s) online, the number of channels formed, and the highest connection count.


No parameters are used. Checks the version of the server. As IRCDSS is currently a standalone server that does not support server-server links, the <target> server parameter is not supported.


Requests server statistics.

Parameters: [<query>]

Supported query parameters:
o - returns a list of each configured host, nickname and class from where users may become IRC operators (require IRC operator status)
u - returns a string showing how long the server has been up.

The <server> parameter is not supported.


Returns the ERR_DISABLED reply: "Disabled for security reasons".


Queries the local time from the server. The <server> parameter is not supported.


Not implemented: Command that requests a server to try to establish a new connection to another server.


Not implemented: Command used to find the route to specific server and get information about its peers.


Returns information about the administrator of the given server. This includes the replies:

RPL_ADMINME Server name from the ServerName field of the "M" line of ircd.conf
RPL_ADMINLOC1 Geographic description of server location from the GeoLocation field of the "M" line of ircd.conf
RPL_ADMINLOC2 Handle of administrator extracted from the YourEmail field of the "A" line of ircd.conf
RPL_ADMINEMAIL Administrative email contact for the server from the YourEmail field of the "A" line of ircd.conf


Returns information about the server, such as its description, when it was started, how long on line.

Service query and commands


Not implemented: Command used to list services currently connected to the network and visible to the user.


Not implemented: Command used to deliver text messages to services. Note that special service users such as ChanServ, NickServ and AuthServ commonly respond to PRIVMSG (/msg in clients).

User based query commands


Parameters: [ <mask> [ "o" ] ]

Returns a list of user information which 'matches' the <mask> parameter. In the absence of the <mask> parameter, all visible (users who aren't invisible (user mode +i), or users who are on a common channel with the requesting client) are listed.

The same result can be achieved by using a <mask> of "0" or "*".

The <mask> parameter is matched against users' host, server, real name and nickname if the channel <mask> cannot be found. If the "o" parameter is passed, only operators are returned according to the <mask> supplied.

For wildcards, RFC2812 defines the use of two special characters: '?' to match one and only one character, and '*' to match any number of any characters. Wildcard matching requires leading and trailing wildcard characters to be given to find embedded character sequences.

A leading '!' inverts the matching logic. In addition, WHO #channel lists all names on a channel.


Shows information about each user that matches a <nickmask> parameter (without notifying the specified user).

Parameters: [<server>] <nickmask>[,<nickmask>[,...]]

Wildcards are allowed in the <nickmask> parameter. <server> is not currently supported. A comma delimited list of <nickmask>s may be given.


Shows information about a user who has quit.

Parameters: <nickname>

The <count> and <server> parameters are not supported, and previous nicknames prior to nickname changes will not be returned.

Miscellaneous commands


This removes a user from the network by causing the client-server connection to be closed by the server.

Only users with IRC operator status can use this command.

Parameters: <nickname> <comment>

<nickname> refers to the user to be disconnected,
<comment> gives the reason for the disconnection.


The server does not respond to a PING command. It is sent by the server to the client. If a connection fails to respond to a PING message within a set amount of time, that connection is closed.


Resets a timeout since the last PING sent to the client.

Clients must reply to PING messages from the server in the format "PING :message" by returning a message in the format "PONG :message". The "message" varies between IRC servers, but IRCDSS sends a random string of 10 digits for the registration PING, and uses the server name defined in the "M" line of ircd.conf (default for the regular PING.


This is a server-server command which is not implemented.

Optional feature commands


Enables a user to set an automatic reply string for any PRIVMSG commands directed at the user.

Parameters: [message]

With one parameter: set an AWAY message
With no parameters: remove the AWAY message


Not implemented: Command used by an operator to force the server to re-read and process its configuration file.


Not implemented: Command used by an operator to shutdown the server.


Not implemented: Command used by an operator to force the server to restart itself.


Command not implemented other than to send the ERR_SUMMONDISABLED reply "SUMMON has been disabled".


Command not implemented other than to send the ERR_USERSDISABLED reply "USERS has been disabled".


Not implemented: Command used to send a message to users who have the 'w' user mode.


The USERHOST command takes a list of up to 5 nicknames, each separated by a space character, and returns a list of information about each nickname that it found.


ISON takes a space-separated list of nicks. For each nickname in the list that is present, the server adds that to its reply string.

The only limit on the number of nicks that may be checked is that the combined length MUST NOT be too large as to cause the server to chop it off so it fits in 512 characters.

Parameters: <nickname>{<space><nickname>}

Back to Top

Simulated Users and Channels

IRCDSS has several built-in permanent channels which are populated by simulated users. To allow you to test your IRC clients in a channel with talk activity but without needing to join a live network, the users randomly "talk" in the channel. Each channel has a specific topic, and the text is generated by a Markov chain text algorithm, which generates random text based on the statistics of sample text input that gives the likelihood that one word will follow another word.

These channels also generate random user join, part and CTCP ACTION events. You can also try out various commands on the simulated users, such as KICK and MODE.

Built-in Channels

Channel Name
Special Features
Test channel
This channel has no text activity, JOINs or PARTs (A Markov data file is not required for this channel, therefore the log will display "Markov data file Test.dat was not found")
Chuck Norris Facts
All about Matt Groening's Futurama
Python Programming Language
About the Works of Shakespeare
About the Victorian novelist, Charles Dickens
About the Unicode® character coding system
Text in this channel includes special Unicode® characters

The screenshots below show how output from the simulation channels appears on an IRC client.

Back to Top

Service Users

Service users are built in users with certain special functions. All service users respond to SHOWCOMMANDS and HELP.

ChanServ (X)

Sets channel operator status when users join/create new channels.

The following commands are available:

OP / DEOP: Gives/Removes channel ops to/from a user.

If the last parameter is omitted the action is performed on the person requesting the command.

Syntax: OP / DEOP <#channel> [nickname]
or type !OP / !DEOP [nickname] in the channel.


Sends NOTICES about whether nicknames are registered or not.


Manages account logins.

The following commands are available:

AUTH: Log in to a user account.
Syntax: AUTH <accountname> <password>

Note that accountname and password are case sensitive.

UNAUTH: Log out of a user account.
Syntax: UNAUTH

INFO: returns information about your login status.
Syntax: INFO

PASS: changes your account password.
Syntax: PASS <old password> <new password>

REGISTER: registers an AuthServ account (IRC operators only). The email is included as part of the AuthServ registration process so as to be representative of common practice, but apart from storage in an "A" line of your Settings_M_N_O_P.conf file (see Settings Files) is not used. It does not have to be a real email address but must be valid in line with RFC 3696 (something like is perfectly OK).

Syntax: REGISTER <account> <password> <email>

Back to Top


The message of the day file, MOTD.txt, is kept in the %APPDATA% location \Roaming\CJSSoft\IRCDSS.

If the file is not there, IRCDSS copies a default file there. The contents of this file are sent to the client at login, or if the MOTD command is received. You can edit this file to your own requirements.

Back to Top

Config File

The configuration file, ircd.conf, is kept in the %APPDATA% location \Roaming\CJSSoft\IRCDSS.

If the file is not there, IRCDSS copies a default file there. The default file configuration should allow IRCDSS to work immediately with predetermined settings, but certain fields can be edited by the user to change IRCDSS settings.

If you intend to use IRCDSS as a working IRC server, be sure to change the "O" line password from its default to something more secure.

The first character of each line identifies the type of record. One line of each type "M", "A", "P", "Y", "I", and "O" is currently used. An example of the default file is:

# IRC configuration file for IRC server simulator Kingdom:6667:826A:
A:WinShoe Simulator::IRCDSSNet:

These lines are based on the definitions at:

The contents of the lines are defined as follows with their usage by IRCDSS shown in italics:

Server description

IRC server's name
Reported by TIME, ADMIN and used in prefix of numeric replies and various notices
Your internet IP (blank = use primary IP of host)
Geographic Location
Reported by ADMIN
Port the server listens for UDP pings to determine fastest link
"globally unique" ID made up of ISO-3166-1 3 digit country code + assignment from 'xxxxA' to 'xxxxZ', 'xxxx0' to 'xxxx9'

Administrative information

Organization, IRC dept.
e.g. Daemon <>
Reported by ADMIN
e.g. Client Server
Leave empty
Network name MUST be one word

Ports for connections

Leave blank to listen on all ip addresses of the machine
Leave empty or "*"
Leave empty
Listen on this port
Sets default non-SSL/TLS port for server
Unspecified options (leave empty)

Connection classes

Class number (increases with priority)
Ping frequency (in seconds)
Specifies server-client PING interval
Connect frequency (in seconds) (unused for client classes)
Maximum number of automatically initiated links in this class
Sendq in the format <x>.<y>; x defines sendq, y defines burst sendq (e.g. 1MB/20MB)
Maximum number of links from this [user@]host on the server (unused for server classes)
Maximum number of links from this [user@]host on the net (unused for server classes)

Client authorization

Target host address - accepts CIDR format
Password, which clients can be configured to send - optional
Target host name (e.g. *@*
Class defined by a Y line

Operator access

Host name operator may connect from
Reported by "STATS o"
Specifies password match for OPER <user> <password>
Nickname or user name from target host
Specifies user match for OPER <user> <password>, reported by "STATS o"
Class defined by a Y line
Reported by "STATS o"
Flags for activities (kill, connect, squit etc) - 'A' gives most possible permissions
Note: Password match is case sensitive, but Nickname match is case insensitive. Wildcards may be used for both in the "O" line - '*' or blank matches anything.

Back to Top

Settings Files

There are two types of settings files, saved by IRCDSS in the %APPDATA% location \Roaming\CJSSoft\IRCDSS. These are the server logging options settings, and the server settings files.

The Settings.conf file contains settings made by the Server Logging Options dialog and other settings dialogs, so that they can be restored for the next time IRCDSS is started. These settings affect the application as a whole.

The other settings file appears with a name such as "Settings_3_1_0_6667.conf"

The numbers appended to "Settings" indicate the configuration of a particular server used when you start the server using the menu "Start Server" command.

Settings file name options: Settings_M_N_O_P.conf

Meaning of numbers in filename:
M: ServiceType - refers to the IRC service, always = 3
N: SocketType - refers to the type of socket, always = 1 (TCP/IP)
O: Family - refers to the IP types supported, always = 0 for PF_UNSPEC which allows IPv4 or IPv6 connections
P: Port - The port that the server listens on, in the range [0-65535], set by the "P" line in the ircd.conf file

The server settings file contains settings lines identified by a letter in a similar way to the ircd.conf file, although the letters have a different meaning in this context.

A lines contain authorisation records for logins to AuthServ.

B lines contain ban records for the previous "C" line.

C lines contain channel data for permanent channels.

Channel data normally consists of a "C" line followed by any number of "B" lines, if the channel has any bans set.

This data is saved automatically by the application. "A" lines are saved by using a REGISTER command sent to special service user AuthServ. Channel data is saved when a channel is made permanent using the channel "P" mode.

Back to Top


The message of the day file, MOTD.txt, is kept in the %APPDATA% location \Roaming\CJSSoft\IRCDSS.

Settings files are also saved by IRCDSS in the %APPDATA% location \Roaming\CJSSoft\IRCDSS.

Windows uses the %APPDATA% folder for application-specific data (in a networked domain, it should also roam with the user profile).

These folders can be located by using the Start/Search box and entering %APPDATA%, then click on "Roaming" or "%APPDATA% File Folder" and explore from there.

You should find a subdirectory CJSSoft, and under that is a subdirectory IRCDSS containing the setup files

You might not be able to locate this folder in Explorer or the Browse dialog if you have the setting for hidden files not to be displayed. To make the hidden files visible, in Windows 7: Click on the Organize button in any Explorer folder, and then select "Folder and Search Options" from the menu, and then click the View tab, and select “Show hidden files and folders” in the list, or select the Start button, select Control Panel > Appearance and Personalization > Folder Options > View tab and under Advanced settings, select "Show hidden files, folders, and drives", and then select OK.

The %APPDATA% folder can also be opened in Windows Explorer using the "Open %APPDATA% location in Explorer" button in the Server SSL/TLS Certificate file settings dialog.

In Windows 8 and 10, the Explorer ribbon's View tab has an Options button which allows you to select "Show hidden files and folders".

Back to Top

Installation files

In Windows OS, by default, your application is installed on your System Drive, usually "C". 32 bit applications are installed under "C:\Program Files (x86)", and 64 bit applications are installed under "C:\Program Files". If your Windows OS is 32 bit, there will only be a "C:\Program Files" location which is for 32 bit applications only.

If you right click and select Properties for your application's desktop icon or Start menu link, the Properties dialog's Shortcut tab should show the installation location in the "Start in" box.

A default ircd.conf configuration file named ircd_def.conf, and a default MOTD.txt file named MOTD_def.txt is kept in the install directory where the IRCDSS executable was installed. These are copied to the %APPDATA% location only if the relevant file is not already there.

Back to Top

Running on a Virtual Machine

You can run IRCDSS on a virtual machine, and connect to it from your normal OS. This can be useful for testing between different operating systems, or to enable the use of a different IP rather than "localhost" when running on the same machine.

The following example assumes a PC with Windows 7 installed as main OS, and installing IRCDSS on a VirtualBox virtual machine running Windows 10.

Set the network setting for your virtual machine to "Bridged Adaptor" and enable it. Start up your virtual machine OS. Install IRCDSS on your virtual OS, and run a server as usual. Open a CMD window on the VM and type IPCONFIG to find out your virtual machine's adaptor's IP address (the first Ethernet adaptor listed is probably the right one to use, and not the tunnelling adaptor for the VM) and use that in place of "localhost" for the server address in your IRC client on the normal OS. (To connect from a client on the same VM, simply use "localhost").

Similar methods can be used to run IRCDSS on an older OS (in a virtual machine) than your current one.

To run IRCDSS on your normal OS (e.g. Windows 7) and connect to it from a client on your virtual machine, open a CMD window from the normal OS and type IPCONFIG to find out your computer's adaptor's IP address (this should be the one your computer uses on the local network, and not the one listed for the VirtualBox adaptor) and use that in place of "localhost" for the server address in your IRC client on the VM.

Back to Top


When you connect to a server using a "secure connection" the connection is set up to support encryption of your application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. TLS is the up-to-date version, although the older SSL name is often still used to refer to either method. For example, when you browse to a site starting with "HTTPS", the browser will set up a SSL/TLS connection.

A Certificate is used in conjunction with SSL/TLS connections to distribute a public key and other information about a client or server. Certificates can be digitally signed by a Certification Authority (CA). A CA is a trusted third party that has validated the originator's certificate. Most web browsers are distributed with a list of well-known CAs whose digital signatures may be automatically accepted. If a certificate's signature is not in the list of accepted CAs, the connection may be rejected, or the user may be offered a choice to accept or decline the connection.

Certificates in SSL/TLS follow the X.509 standard from the International Telecommunication Union. The format is defined in the documents RFC1422, RFC2459 and RFC5280, which apply to versions 1, 2 and 3 respectively.

X.509 v3 certificates include the following information:

  • Version
  • Serial Number
  • Algorithm ID
  • Issuer
  • Validity period, defined as a Not Before and a Not After time
  • Subject
  • Subject public key info
  • An optional Issuer Unique Identifier
  • An optional Subject Unique Identifier
  • Optional extensions
  • Certificate Signature Algorithm
  • Certificate Signature

From the point of view of the server, if a client offers a certificate (optional), it will be validated, and if the "Verify peer" option is enabled, the connection will be automatically rejected if the CA cannot be identified in the CA certificate store (default cacert.pem).

The server sends its certificate (default server_cert.crt) when a client initiates a secure connection. The client may choose to accept or reject it, depending on whether the certificate has a well-known CA signature. For the example files supplied, the CA is simulated, so if the client is set to verify the peer, or the user rejects a certificate with an unknown signature, the connection will not be accepted. You can override this behaviour by adding your CA.pem certificate to the client's CA certificate store, i.e. you are informing the client that this is an accepted CA.

If you use the software generated certificate option for the server, the server certificate files are not used, but a certificate and key are generated by the application. These are self-signed so the client must be able to accept self-signed certificates without a well-known CA.

Trusted CAs change over time, and you need to keep the CA certificate store up to date. One way of doing this is to download the cacert.pem file from which is a converted version of the Mozilla CA certificate store, licensed under the same license as the Mozilla source file: MPL 2.0.

Most IRC servers don't require a certificate from the IRC client. An example of when one would be required would be a private IRC network where users must sign up to the service and obtain a certificate before being allowed to connect. If a client-side certificate is not used, as is normal, the server should be set to not verify the peer, and it will therefore not need to refer to the CA certificate store.

IRC servers offering SSL/TLS connections may be encountered that have an out of date or self-signed certificate; their main objective being to offer a secure connection, without being concerned with offering a third party verified certificate. It is then up to the user to decide whether to accept this state of affairs.

Back to Top

Creating your own SSL/TLS certificates

A batch file CreateCerts.bat is included in the installation directory, under subdirectory "\Certificates", together with a set of pre-built certificates. To use this batch file to create new certificates, copy it to another folder with write permissions, and run it from the command line. You will need to have OpenSSL installed on your system.

The batch file is set up to create a set of demo certificates and related files using 32 bit OpenSSL (version 1.1.1). You may need to change the path to OpenSSL on your system, by changing the value of the pathToOpenSSL variable. Either 32-bit or 64-bit OpenSSL can be used, given the correct path.

To enable a client to trust your certificates, you can append the CA.pem file that is generated to the CA certificate store used by the client, but in conjunction with this, you must replace the demo server certificates in the %APPDATA% location with the ones generated by the batch file (or use the demo CA.pem file originally provided in "\Certificates").

The batch file also generates client_cert.crt and client_cert.key certificates that you can use with an SSL/TLS enabled IRC client. For the server to trust these certificates, you can append the relevant CA.pem file to the CA certificate file used by the client.

To generate a suitable working set of files, you must edit in your details, for example replacing the organisation and common name in "/O=Example Com/" with your own.

If you need a certificate signed by a recognised certificate authority, you can send the CSR files to a public certificate authority (CA).

Certificate files

File Name
A set of root certificates representing trusted public Certificate Authorities
Server certificate signed by the demo CA
Private key for the server
Certificate signing request for the server, containing the information required to request a certificate signed by a public CA.
Client certificate signed by the demo CA
Private key for the client
Certificate signing request for the client
Serial number file used when creating more certificates with the same CA (using the -CAserial option instead of -CAcreateserial).
CA Certificate for the demo Certificate Authority
Private key for the demo Certificate Authority
Certificate signing request for the demo Certificate Authority

Back to Top

Quick start guide for setting up a channel op

In the following, <nick> stands for your nickname.

1. Get IRCOP status (from client side, e.g. a server status window):

/OPER <nick> password

The parameters must match the nickname and password in the "O" line of the ircd.conf file.

2. Register an AuthServ account (you need to match the data in the A line contain the authorisation records for logins to AuthServ, see Settings Files):

/raw privmsg AuthServ register <nick> password

3. Log in to AuthServ:

/raw PRIVMSG AuthServ AUTH <nick> password

4. Request chanop status (in channel window)

!OP <nick>

5. Set voice mode

/mode #Test +v <nick>

6. Set i mode

/mode <nick> +i

Back to Top


IRCDSS does not harvest any personal information or send anything over the internet to third parties. Internet connections are limited to clients that you connect to make use of IRCD functions as described.

Back to Top


Bob Jenkins, "ISAAC random number generator" (public domain)

MD5 implementation by Alexander Peslyak (public domain). This is used for "+x" host hiding.

The OpenSSL Project: Website:, license: Apache License v2.0.

CA certificate store: cacert.pem, license: MPL 2.0

Quotes from Futurama, created by Matt Groening, are offered for the purpose of criticism and review through the medium of Markov chain text, which does not preserve the exact original text, but only represents a statistical analysis of word frequencies and combinations in the original text. The same applies to quotes concerning Chuck Norris, Dickens, Python, Shakespeare and Unicode®.

Back to Top

Trademark Policy and Bug Reports

Trademark Policy

Trademarks mentioned here include the following.

Any trademarks mentioned are recognised as being the property of their respective owners. If I have forgotten any that should be in this list, or if you notice any trademark cited incorrectly here, please let me know via the contact web page as described under "Bug Reports" below.


Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.


A registered trademark of Microsoft Corporation.
Microsoft Trademarks


Unicode® and the Unicode® Logo are registered trademarks of Unicode, Inc. in the United States and other countries.
The Unicode Consortium Name and Trademark Usage Policy


The OpenSSL trademark is a registered United States trademark of the OpenSSL Software Foundation.
OpenSSL Trademark Policy

Bug Reports

Feedback about your experience with this application, suggestions for improvements, and bug reports should any problems occur, are always welcome, and can be reported using the contact information form at

Back to Top