||Parses a raw IRC message into an object (see section 2.3 of RFC 2812). This
returns an object with the following fields:
rawMessage The initial message string received without any processing.
command A string that is the command or response code.
params An array of strings for the parameters. The last parameter is
stripped of its : prefix.
origin The user's nickname or the server who sent the message. Can be
a host (e.g. irc.mozilla.org) or an IPv4 address (e.g. 18.104.22.168)
or an IPv6 address (e.g. 3ffe:1900:4545:3:200:f8ff:fe21:67cf).
user The user's username, note that this can be undefined.
host The user's hostname, note that this can be undefined.
source A "nicely" formatted combination of user & host, which is
<user>@<host> or <user> if host is undefined.
tags A Map with tags stored as key-value-pair. The value is a decoded
string or undefined if the tag has no value.
There are cases (e.g. localhost) where it cannot be easily determined if a
message is from a server or from a user, thus the usage of a generic "origin"
instead of "nickname" or "servername".
aData The raw string to parse, it should already have the \r\n
stripped from the end.
aOrigin The default origin to use for unprefixed messages.
||This contains the implementation for the basic Internet Relay Chat (IRC)
protocol covered by RFCs 2810, 2811, 2812 and 2813 (which obsoletes RFC
1459). RFC 2812 covers the client commands and protocol.
RFC 2810: Internet Relay Chat: Architecture
RFC 2811: Internet Relay Chat: Channel Management
RFC 2812: Internet Relay Chat: Client Protocol
RFC 2813: Internet Relay Chat: Server Protocol
RFC 1459: Internet Relay Chat Protocol
||This implements the IRC Client Capabilities sub-protocol.
Client Capab Proposal
RFC Drafts: IRC Client Capabilities
Note that this doesn't include any implementation as these RFCs do not even
include example parameters.
||This implements the Client-to-Client Protocol (CTCP), a subprotocol of IRC.
REVISED AND UPDATED CTCP SPECIFICATION
||This contains an implementation of the Direct Client-to-Client (DCC)
A description of the DCC protocol
||This implements the echo-message capability for IRC.
When enabled, displaying of a sent messages is disabled (until it is received
by the server and sent back to the sender). This helps to ensure the ordering
of messages is consistent for all participants in a channel and also helps
signify whether a message was properly sent to a channel during disconnect.
||Object to hold the IRC handlers, each handler is an object that implements:
name The display name of the handler.
priority The priority of the handler (0 is default, positive is
isEnabled A function where 'this' is bound to the account object. This
should reflect whether this handler should be used for this
commands An object of commands, each command is a function which
accepts a message object and has 'this' bound to the account
object. It should return whether the message was successfully
handler or not.
||This implements the ISUPPORT parameters for the 005 numeric to allow a server
to notify a client of what capabilities it supports.
The 005 numeric
RFC Drafts: IRC RPL_ISUPPORT Numeric Definition
||This contains an implementation of the multi-prefix IRC extension. This fixes
a protocol level bug where the following can happen:
foo MODE +h
foo MODE +o
bar JOINs the channel (and receives @foo)
foo MODE -o
foo knows that it has mode +h, but bar does not know foo has +h set.
||There are a variety of non-standard extensions to IRC that are implemented by
different servers. This implementation is based on a combination of
documentation and reverse engineering. Each handler must include a comment
listing the known servers that support this extension.
Resources for these commands include:
||This implements SASL for IRC.
||This implements server-time for IRC.
||This attempts to handle dealing with IRC services, which are a diverse set of
programs to automate and add features to IRCd. Often these services are seen
with the names NickServ, ChanServ, OperServ and MemoServ; but other services
do exist and are in use.
Since the "protocol" behind services is really just text-based, human
readable messages, attempt to parse them, but always fall back to just
showing the message to the user if we're unsure what to do.
||The supported formatting control characters, as described in
If a string is given, it will replace the control character; if null is
given, the current HTML tag stack will be closed; if a function is given,
it expects two parameters:
aStack The ordered list of open HTML tags.
aInput The current input string.
There are three output values returned in an array:
The new ordered list of open HTML tags.
The new text output to append.
The number of characters (from the start of the input string) that the
||This implements the WATCH and MONITOR commands: ways to more efficiently
(compared to ISON) keep track of a user's status.
MONITOR (supported by Charybdis)
WATCH (supported by Bahamut and UnrealIRCd)