Using the Network
To access the freenode IRC servers, you'll first need an IRC client. Text clients include irssi, WeeChat, and ERC. Graphical clients include XChat, Smuxi, and Quassel for Unix and GNU/Linux, and mIRC for Windows. There is also the freenode webchat. Packages for various IRC clients may be included on your operating system install CDs and links to web sites for the client software can be found here.
Once you have a client, you'll need a server. You can simply use chat.freenode.net to reach our main rotation of servers; or, you can find a more geographically-local server here.
After you've obtained your client and the name of a server, you may still need a bit of help in getting connected. Take a look at this tutorial or this IRC primer on irchelp.org, which contains a variety of other useful information as well.
Channel and nick registration
freenode provides nickname and channel registration services. These should be used to avoid disagreements about nickname use and to maintain clear operational control of channels. You must register your nickname to register a channel or to be added to its access list. If you'd like to register a channel here, remember that we are a special purpose network devoted to peer-directed projects. Please remember to take a look at our on-topic policy before registering your channel.
For general information on nickname or channel registration services, use "/msg nickserv help" or "/msg chanserv help". For specific information on registration, use "/msg nickserv help register" or "/msg chanserv help register".
Channel access management (flags)
We strongly suggest that you avoid configuring your channel to "auto-op". Use the chanserv "op" command to obtain channel operator status only when needed. This will help to keep your channel temperature low and reduce conflicts.
Help us support your channel in emergencies by adding channel staff to your channel access list via "/msg chanserv flags #channelname [nick] [access]". The [nick] must either be a registered nick or a valid hostmask, and [access] should be a series of flags, as defined in "/msg chanserv help flags". Flags of +voAti are customary, and sufficient to allow opping and deopping, as well as some other maintenance tasks. Staff can be given access by providing [nick] as "*!*@freenode/staff/*".
The use of a system called "templates" can help to simplify the system of flags. See "/msg chanserv help template" for more information.
User and channel modes
The user and channel modes listed below are to be treated differently to the flags described above. The modes below are set using the "/mode" command: either "/mode <nickname> +w" or "/umode +w" for user modes, and "/mode #channel +i" for channels.
Channel modes can also be set with the help of ChanServ's MLOCK feature. Consult "/msg ChanServ HELP SET MLOCK" for more details.
The following is a list of ircd-seven user
modes, some additional information about them is available by sending '/help umode' to the server:
|+D (deaf)||This prevents you from receiving channel messages. You will probably not want to set this in most cases.|
|+g (callerid)||You can set this umode to prevent you from receiving private messages from anyone not on a session-defined whitelist. We would suggest only using this user mode if you have problems with volumes of spam via private message. The content of the whitelist can be controlled using the /accept command. When a user not on the whitelist attempts to contact you, you will receive a notice informing you of the fact and you can then use /accept user to speak to them. Users can be removed from the whitelist using /accept -user. Finally, /accept * will print the whitelist.|
|+i (invisible)||This prevents you from appearing in global WHO/WHOIS by normal users, and hides which channels you are on. It is strongly recommended that you set this user mode, and it is now enabled by default.|
|+Q (no forwarding)||This user mode prevents you from being forwarded to another channel because of channel mode +f (see below) or by a ban (see +b below). Instead of being forwarded to another channel, you'll be given a message as to why you could not join.|
|+R (block unidentified)||This user mode prevents users who are not identified to nickserv from sending you private messages. It is suggested that you might want to temporarily set this user mode if you suffer problems with unidentified users sending you unwanted messages.|
|+w (see wallops)||This user mode lets you see the wallops announcement system. Important network messages will be sent out via global notices; this is only for non-critical announcements and comments which may be of interest.|
|+Z (connected via SSL)||You will have this user mode if you connect to freenode using SSL.|
The following is a list of ircd-seven 1.0 channel modes, some additional information about them is available by sending '/help cmode' to the server.
|+b (channel ban)||
Bans are used to prevent users from joining a channel.
Passing '/mode +b' alone will return a list of bans and can be used by any user. Actually
setting bans is restricted to channel operators. Users matching bans are unable to join
the channel or knocking on it (see below). If the banned user is already in the channel,
they will be prevented from speaking and from changing nicks in there, unless +v.
On freenode, bans can take one of two main forms. The most common form
is +b nick!user@host. The wildcards * and ? are allowed, matching zero-or-more
and exactly-one characters, respectively. The masks will be trimmed to fit
the maximum allowable length for the relevant element.
Bans set on IP addresses will apply even if the affected user joins with a resolved or spoofed hostname. CIDR is supported in bans, like *!*@10.0.0.0/8. This is most useful with IPv6.
ExtbansThe second form (extban) is +b $type or +b $type:data. 'type' is a single character (case insensitive) indicating the type of match, optionally preceded by a tilde (~) to negate the comparison, while 'data' depends on type. Potential types are a, r and x.
Channel forwards in bansThe suffix "$#channel" can be appended to any of the above bans masks to cause a user to be forwarded to #channel. The ban setter will only be able to set this ban if they are an op in #channel, or if #channel has channel mode +F set. In this case, in all situations where the user would previously have been told they could not join, they will instead join the channel named in the ban mask and be sent a 470 numeric describing the forward.
|+C (block CTCPS)||This mode blocks the sending of CTCP commands to whole channels.|
|+c (color filter)||This mode activates the colour filter for the channel. This filters out bold, underline, reverse video, beeps, mIRC colour codes, and ANSI escapes. Note that escape sequences will usually leave cruft sent to the channel, just without the escape characters themselves.|
|+e (ban exemption)||This mode takes one parameter of the form nick!user@host, with the usual wildcards (including extban parameters), which overrides +b and +q bans for all clients it matches. This can be useful if it is necessary to ban an entire ISP due to persistent abuse, but some users from that ISP should still be allowed in. For example: /mode #channel +be *!*@*.example.com *!*email@example.com|
|+f (forward on uninvited)||
This feature is specified with some channel name
#foo. When specified on a +i channel (invite-only), users who try
to join the channel and are not in the invite-only exemption list (+I) are
automatically sent to channel #foo. Clients receive a 470 numeric
message which lists the original and the target channels. Clients
will also be forwarded if +j is set and the join throttle is exceeded.
An operator can only set mode +f #channel2 if they are an op in #channel2 or if #channel2 has mode +F set (see below).
An operator can only use ChanServ's MLOCK feature with +f if they have access flag +s in both channels, or if the channel to be forwarded to is +F and they have +s in the original channel.
|+F (enable forwarding)||This mode can be set by any channel operator to allow operators in other channels to set bans to forward clients to their channel, without requiring ops in it (see +b, above).|
|+g (allow anybody to invite)||With this mode set, anybody in the channel is allowed to invite others (using the /invite command) to the channel. If this mode is not set, /invite is limited to channel operators. With this mode set, any client in the channel can affect who can join around modes such as +i, +j, +l or +r.|
|+i (invite-only)||No client can join this channel unless they are listed in the invite exemption list (+I) or are invited by someone through the /invite command.|
|+I (invite-only exemption)||This mode takes one parameter of the same form as bans. Matching clients do not need to be invited to join the channel when it is invite-only (+i). Unlike the INVITE command, this does not override +j, +l and +r. Only channel operators can see +I changes or request the list (/mode +I).|
|+j (join throttling)||This mode takes one parameter of the form n:t, where 'n' and 't' are positive integers. Only 'n' users may join in each period of 't' seconds. Invited users can join regardless of +j, but are counted as normal. It is highly recommended that your channel use this mode to prevent aganist bot attacks (observe the average join rate of your channel and pick a good value for +j). If you also use +f (see above), you can forward users who are throttled to another channel (e.g. ##overflow).|
|+k (channel password)||This mode sets up a channel password. To enter the channel, you must specify the password on your JOIN command. Keep in mind, modes locked with ChanServ's MLOCK command can be seen by anyone recreating the channel (this includes keys).|
|+l (join limit)||Specified with a numeric value, this mode limits the number of users who can join your channel.|
|+L (large ban/exempt/invex lists)||This mode, which can only be set by freenode staff, allows a channel to have longer than normal ban, exempt, and invex lists.|
|+m (moderated)||When a channel is set +m, only users with +o or +v on the channel can send to it. This mode does not prevent users without +v or +o from changing nicks.|
|+n (prevent external send)||Users outside the channel may not send messages to it.|
|+p (paranoid)||When set, the KNOCK command cannot be used on the channel to request an invite, and users will not be shown the channel in WHOIS replies unless they are on it. Unlike on some ircds, +p and +s can be set together.|
|+P (permanent channel)||This mode may only be set by freenode staff. Once set, the channel will not be deleted when it becomes empty. Additionally, the +b, +e, +I and +q lists have higher capacity to make channel forwarding easier. NOTE: Permanent channels can still be erased by catastrophic network failures.|
|+q (quiet user)||This mode works like +b (ban user), but instead simply quiets the user. We encourage channels to use quiets in place of bans wherever possible. The list of quiets is separate from the list of bans and can be viewed using '/mode #channel +q'.|
|+Q (block forwarded users)||Users will not be able to be forwarded (see +f above) to a channel with +Q.|
|+r (block unidentified)||This mode prevents users who are not identified to NickServ from joining the channel. Users will receive a server notice explaining this if they try to join. '/mode +q $~a' can be used to prevent unregistered users from speaking in channel while allowing them to join (old +R behaviour).|
|+s (secret channel)||This channel will not appear on channel lists or WHO or WHOIS output unless you are on it.|
|+t (only ops can change topic)||When +t is set, only channel operators may modify the topic of the channel. This mode is recommended in larger, more public channels to protect the integrity of the topic.|
|+z (reduced moderation)||When +z is set, the effects of +b, +q, and +m are relaxed. For each message, if that message would normally be blocked by one of these modes, it is instead sent to all the users who are currently set +o (channel operator). This is intended for use in moderated debates.|