	FoxEye IRCD reference manual.

    Module "ircd" offers the RFC2810...2813 compliant IRC server. Note that
user mode 's' which is marked as obsolete neither refused nor broadcasted
to neighbour servers. Also it's remarcable that classes in FoxEye can have
more descriptive names not just numbers.
    Channel names are restricted a bit more than RFC2812 says. There is no
unprintable characters available in the names for channel at all, not only
^G (ASCII 7). Also there is a compilation option IRCD_STRICT_NAMES which
does a further restriction (see below).

    Two compilation options make new features: IRCD_USES_ICONV and
IRCD_MULTICONNECT. See descriptions below.


#define IRCD_USES_ICONV 1

    If you defined IRCD_USES_ICONV to non-zero value then server will have
 support for on-the-fly traffic conversion to different encodings. Traffic
 between servers will be encoded with CHARSET_8BIT by default. This define
 also enables IRCD_STRICT_NAMES which stricts nicks and channel names to be
 compatible with CHARSET_8BIT encoding.
    Encoding in which user connection is will be chosen in that order:
 - default encoding for IRCD listening port where user is connected;
 - default encoding for user's class (if set);
 - default encoding for user if he/she has individual record;
 - encoding given in "CHARSET" command.
    The server should send RPL_CODEPAGE reply each time connection encoding
 is set or changed.

      Command: PASS
   Parameters: see RFC2813

   Server version of this command can have new option flag "U" which changes
   encoding of traffic between servers to CHARSET_UNICODE which should be
   capable of full unicode characters range and should be compatible with
   CHARSET_8BIT encoding.

      Command: WHOIS
   Parameters: see RFC2812

   This command has now one more numeric reply if requested for local client:
   RPL_WHOISCHARSET which replies encoding which is used for communication
   with client in request.

      Command: CHARSET
   Parameters: [ <charset name> ]

   The CHARSET command can be used to query or change encoding of traffic
   between client and server. If parameter <charset name> is given then
   server will attempt to set enconding to that charset before returning
   name of charset which is used for user's connection.

   Numeric Replies:

           ERR_NOCODEPAGE                  RPL_CODEPAGE

   Example:

   CHARSET utf-8                   ; request to change connection encoding
                                   to "utf-8".

 Command responses (numeric replies):

       222    RPL_CODEPAGE
              "<charset> :is your charset now"

         - The server sends this as reply to successful CHARSET command
           and also upon successful registration.

       320    RPL_WHOISCHARSET
              "<nick> :charset is <charset>"

         - Returned for local client in reply to WHOIS command.

       468    ERR_NOCODEPAGE
              "<charset> :Invalid charset"

         - Returned to a client which is attempted to change connection
           encoding to some undefined charset name.


#define IRCD_MULTICONNECT 1

    If you defined IRCD_MULTICONNECT to non-zero value then server will
 have support for cyclic network scheme. When such scheme is allowed then
 any message may be received more than one time. Messages for joining and
 parting channels as well as the network as whole should not be considered
 as error if we got JOIN for user who already joined that channel and so
 on. Messages such as PRIVMSG cannot be resolved the same way so there is
 new category introduced: message identifier. Message identifier is some
 integer which is unique for a server (at least for sane period of time)
 so messages with the same identifier would be skipped when received yet
 again.
    Another problem introduced by cyclic scheme network is network
 delays. For example, see network scheme:

    Server A ----------- Server B
      |                    |
      +----- Server C -----+

 Let say, some client was on server A and disconnected so reconnected to
 server B but immediately disconnected. What we see on server C?

    Link to A             Link to B
    ---------             ---------
    QUIT Nick             (sending QUIT)
    (delay)               QUIT Nick
    (sending NICK)        NICK Nick
                          JOIN ...
    (sending QUIT)        QUIT Nick
    NICK Nick (delayed)
    JOIN ...
    QUIT Nick (delayed)

 In case non-cyclic network everything is OK, clients on server C will see
 QUIT then JOIN then QUIT. In case of cyclic network and some network
 delay long enough to get duplicates clients will see that JOIN + QUIT
 sequence twice. To avoid that problem server MUST send acknowledge to
 link partner for each message such as QUIT so another side would not do
 reaction on any delayed NICK, etc. messages until get the acknowledge
 back.


      Command: PASS
   Parameters: see RFC2813

   Server version of this command can have an option flag "I" which will
   inform link partner that this server can support cyclic network scheme
   so can receive and work on new messages specific to such scheme.

      Command: ISERVER
   Parameters: <servername> <hopcount> <token> <info>

   This message is identical to SERVER message (see RFC2813) but would
   introduce server which is capable to work with cyclic network scheme.

   The ISERVER message SHOULD NOT be sent to a server which is not
   capable to work with cyclic network scheme.

   This message SHOULD NOT be used to introduce new server by the server
   itself, i.e. on registration phase.

      Command: ITOPIC
   Parameters: <msgid> <channel> <topic>

   The ITOPIC message MAY come only from link to server which is capable
   to work with cyclic network scheme and SHOULD NOT come neither from
   server which is not capable to work with cyclic network scheme nor
   originated from some server which is not capable to work with cyclic
   network scheme nor from some service or user who is connected to such
   kind of server.  The ITOPIC message SHOULD NOT be sent neither to a
   server which is not capable to work with cyclic network scheme nor to
   any client.

   The ITOPIC command is used to change the topic of a channel.  If the
   <topic> parameter is not an empty string, the topic for that channel
   will be changed.  If the <topic> parameter is an empty string, the
   topic for that channel will be removed.  Parameter <msgid> is unique
   message identifier.

   Examples:

   :WiZ ITOPIC 651238 #test :New topic
                                   ; User Wiz setting the topic.

      Command: IMODE
   Parameters: <msgid> <nickname> *( ( "-" / "+" ) *<modes> )
               <msgid> <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )

   The IMODE message SHOULD NOT come neither from server which is not
   capable to work with cyclic network scheme nor originated from some
   server which is not capable to work with cyclic network scheme nor
   from some service or user who is connected to such kind of server.
   The IMODE message SHOULD NOT be sent neither to a server which is not
   capable to work with cyclic network scheme nor to any client.

   The IMODE message is a dual-purpose command in IRC similar to RFC2813
   message MODE.  It allows both usernames and channels to have their
   mode changed.  In difference with the MODE message the IMODE message
   have one more parameter <msgid> which is unique message identifier.

   Examples:

   :WiZ IMODE 4527 WiZ -o          ; User WiZ removed oper status from
                                   himself.

      Command: INUM
   Parameters: <msgid> <numeric> <target> *( <text> )

   The INUM message SHOULD NOT come neither from server which is not
   capable to work with cyclic network scheme nor originated from some
   server which is not capable to work with cyclic network scheme nor
   from some service or user.  The INUM message SHOULD NOT be sent to
   clients.

   The INUM message is used to send numeric replies to users on another
   servers in cyclic network scheme environment so numeric digits which
   are keyword for the nymeric reply is the second parameter of INUM
   message and there is also a parameter <msgid> which is unique message
   identifier.

   Examples:

   :irc.net INUM 72301 422 Romis :MOTD File is missing

      Command: ACK
   Parameters: <command> <target> ( <where> )

   The ACK message SHOULD NOT come neither from server which is not
   capable to work with cyclic network scheme nor originated from some
   server which is not capable to work with cyclic network scheme nor
   from some service or user.  The ACK message SHOULD NOT be sent to a
   client.

   The ACK message MUST be sent as reply to any QUIT, SQUIT, KILL, KICK,
   or PART message or to any NICK message which introduces change of
   client nickname.  Parameter <command> is type of message the ACK
   message is replied to.  Parameter <target> is the target of <command>
   (i.e. nick or server name).  Parameter <where> is present only in
   reply to KICK and PART message and is channel name where <target> was
   removed of.

   Examples:

   ACK SQUIT irc.jfi.org           ; ACK for SQUIT of irc.jfi.org.

      Command: IPRIVMSG
   Parameters: <msgid> <msgtarget> <text to be sent>

   The IPRIVMSG message MAY come only from link to server which is
   capable to work with cyclic network scheme and SHOULD NOT come neither
   from server which is not capable to work with cyclic network scheme
   nor originated from some service or user who is connected to such kind
   of server.  The IPRIVMSG message SHOULD NOT be sent neither to a
   server which is not capable to work with cyclic network scheme nor to
   any client.

   The message IPRIVMSG is just alike PRIVMSG but used between servers
   to send private messages between users, as well as to send messages to
   channels.  <msgtarget> is usually the nickname of the recipient of the
   message, or a channel name.  All recipient matching and numeric
   replies are the same as those for PRIVMSG message but only difference
   between those messages is the parameter <msgid> which is unique
   message identifier.

   Example:

   :Angel IPRIVMSG 981 Wiz :Are you here?
                                   ; Message from Angel to Wiz.

      Command: INOTICE
   Parameters: <msgid> <msgtarget> <text to be sent>

   The INOTICE message MAY come only from link to server which is capable
   to work with cyclic network scheme and SHOULD NOT come neither from
   server which is not capable to work with cyclic network scheme nor
   originated from some server which is not capable to work with cyclic
   network scheme nor from some service or user who is connected to such
   kind of server.  The INOTICE message SHOULD NOT be sent neither to a
   server which is not capable to work with cyclic network scheme nor to
   any client.

   The message INOTICE is just alike NOTICE but used between servers to
   send private messages between users, as well as to send messages to
   channels.  <msgtarget> is usually the nickname of the recipient of the
   message, or a channel name.  <msgid> is an unique message identifier.
   All recipient matching and numeric replies are the same as those for
   PRIVMSG message.

      Command: ISQUERY
   Parameters: <msgid> <servicename> <text>

   The ISQUERY message MAY come only from link to server which is capable
   to work with cyclic network scheme and SHOULD NOT come neither from
   server which is not capable to work with cyclic network scheme nor
   originated from some client who is connected to such kind of server.
   The ISQUERY message SHOULD NOT be sent neither to a server which is
   not capable to work with cyclic network scheme nor to any client.

   The ISQUERY message is just alike SQUERY but used between servers to
   send private messages from users to services.  <servicename> is the
   name of the service recipient of the message.  <msgid> is an unique
   message identifier.  All recipient matching and numeric replies are
   the same as those for PRIVMSG message.

   Examples:

   :WiZ ISQUERY 2310 irchelp@irc.fr :HELP privmsg
                                   ; User WiZ requested help from service
                                   irchelp@irc.fr.


#define TOPICWHOTIME 1

    If TOPICWHOTIME is defined then this feature which is present in many
 other servers is enabled. If it is enabled then server keeps track on
 who and when changed the channel topic and send that info along with the
 topic itself when user joins channel or sends query for the topic.

 Numeric reply:

       333    RPL_TOPICWHOTIME
              "<channel> <who> <time>"

         - Sent to client, <who> is the client (in form nick!user@host)
           who changed the channel topic last, and <time> is time when
           topic was changed last, in seconds since Epoch.


Meaning of letters in VERSION reply:

   E  - Opers can rehash server
   i  - Multiple encoding support is enabled
   J  - Opers can use /die
   K  - Opers can use /kill
   o  - Cyclic network scheme is enabled
   R  - Opers can restart server
   s  - Using local services is enabled
   S  - Local /summon is enabled
   T  - RPL_TOPICWHOTIME is enabled
   U  - Local /users is enabled
   W  - Opers will receive NOTICE on WHOIS on them
   6  - IPv6 supported
   8  - Any unicode chars in nick/channel are allowed


Transition from ircd.conf to foxeye configuration.

      A:line
   In the FoxEye all static configuration such as information from A:line
   lies in boot config.  So fields will be in config statements:
   2: set ircd-description-string XXXXX
   3: set ircd-admin-email XXXXX
   4: set ircd-admin-info XXXXX

      B:line
   The B:line isn't supported yet.

      c:line
   c:line is version of C:line which forces establishing connection with
   using Zlib compression.  This can be done in the FoxEye by defining
   char 'Z' in field 'flags' of hostmask - see 'C:line' description.  Note
   that you have to have 'ziplinks' module loaded to make this work.

      C:line
   To setup autoconnect to remote server you have to setup the individual
   client record for the server and set hostmask for it.  Hostmask format
   follows common hostmask rules:
   [ <ident> ] ":" <password> "@" <host> "/" <port> [ "%" <flags> ]
   i.e. it contains every field from C:line but also may contain extra
   field 'flags' which can be used to extent handshake (with Zlib for
   example).
   Client record for a server should have flag 'u' (UNSHARED) in network
   subrecord.  If you need to activate autoconnect for that server then
   also flag '*' (AUTO) should be set.
   Note that you cannot have in FoxEye mixed autoconnects with RFC2813
   servers and servers capable to work with cyclic network scheme.  Once
   you have one of RFC2813 servers autoconnected then no more connects
   will be tried.  So you can have many autoconnects to RFC2813 servers
   and have only one of them connected at the same time.  Or you can have
   as many as you need autoconnects to servers that are capable to work
   with cyclic network scheme simultaneously but none of RFC2813 ones.

      D:line
   There is no plain solution for that crossing yet.

      H:line
   To define servers which some server can introduce you have to set the
   'hub' subfield for individual client record for that server.  The 'hub'
   subfield may contain list of space separated server masks (wilcards are
   supported), any of which may be prepended with "!" to deny that mask
   from being introduced (see L:line).

      i:line
   i:line which is restricted version of I:line in the FoxEye should be
   configured the same way as it goes for I:line but such client record
   should have network subrecord with flag 'd' (DEOP, see documentation).

      I:line
   Host lines for classes are host records for the FoxEye's client records
   so for class '22' you can add hostmask for each desired I:line into your
   class' client record.  Formats follows common hostmask rules:
   <ident|"*"> [ ":" <password>] "@" hostmask
   Note that you can define either domain masks and IP masks.  If both IP
   and domain are defined then IP check follows domain check and IP check
   will be skipped if domain check found any matched class.  See also
   'Y:line' description.

      K:line
   K:line is special line to describe hostmask which are not allowed to
   connect.  In the FoxEye that can be done creating either named or
   unnamed client records with subrecord which have flag 'k' (DENY).
   Note that unnamed client record can have only one hostmask on it.  And
   also note that total number of either named or unnamed client records
   is limited approximately by 32 thousands each so probably the best way
   is to group hosts together if you have too much K:lines on your server.

      L:line
   To use L:line in the FoxEye you should use 'deny' notation for the hub
   subrecord, see 'H:line' description.

      M:line
   In the FoxEye all static configuration such as information from M:line
   lies in boot config.  So fields will be in config statements:
   2: set nick XXXXX
   3: set my-hostname XXXXX
   4: set ircd-description-string XXXXX
   5: [unused]

      N:line
   N:line is alike C:line but defines remote connection.  In the FoxEye
   password of remote server is stored in special subfield 'passwd' and
   can be changed by standard means.  For all other info see 'C:line'
   description.

      O:line
   In the FoxEye permissions are granted to users by setting flags to their
   personal client records' network subrecord appropriate way.  For Local
   IRC Operator you have to set flag 'h' (HALFOP) to them.

      o:line
   In the FoxEye permissions are granted to users by setting flags to their
   personal client records' network subrecord appropriate way.  For IRC
   Operator you have to set flag 'o' (OP) to them.

      P:line
   In the FoxEye each listening port should be configured in boot config
   using command 'ircd'.  See documentation for more info.  Example:
    ircd localhost/9995%S

      Q:line
   In the FoxEye's ircd module servers can be marked quarantined the same
   way as it is done for K:line'd users, i.e. by setting 'k' (DENY) flag
   on network subrecord for such server.

      S:line
   The S:line which allows services to connect can be done the same way
   as it is done for any other connect, i.e. setting the hostmask and
   the special subfield 'passwd' for such client.  The network subrecord
   for service should have flag 's' (SPEAK).

      U:line
   The U:line isn't supported as it is obsoleted these days.

      V:line
   The V:line isn't supported.

      Y:line
   Classes in the FoxEye ircd module are parameter lines for client records
   bound to network record.  If you have a record for network with name
   'ircnet' and want to define class '22' then you have to create client
   record '22' and define subrecord 'ircnet' in it.  Subrecord line will
   contain then five space separated numbers:
   - maximum number of links from this [user@]host on the server
   - maximum number of links from this [user@]host on the net
   - maximum number of links in this class (per I line)
   - ping frequency (in seconds)
   - sendQ for each client
   i.e. respectively 6th, 7th, 4th, 2nd,and 5th fields from Y:line.  Note
   that class name may be not just number but some more descriptive name.
   Also note that always there is some default class, parameters of which
   are defined in variable 'ircd-default-class'.
   Servers are not yet distinguished by classes (but network subrecord
   can be used for that purpose the same way in the future), servers have
   unlimited maximum number of links and sendQ, and ping frequency is
   defined in config variable 'ircd-serverclass-pingf'.


Special support for SSL connections.

   There is some support included if module that supports SSL ('openssl'
 usually) is enabled and activated on connection. The support includes:

   1. Usermode flag 'z' is added if SSL is active.

   2. Additional WHOIS numeric reply is added:

       336    RPL_WHOISSECURE
              "<nick> :is using encrypted connection"

         - Returned to client in reply to WHOIS command.
