The following is copied from http://freenode.net/using_the_network.shtml The content on this page is theirs, it is copied verbatim for the purposes of reference only, I hold no copyright, claims or control over this material at all.
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 ouron-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 registering a nick, see theFAQ. Specifics on registering a channel are discussed on the blog.
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 flags. The nick must either be a registered nick or a valid hostmask, and flags 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 /modenickname +w or /umode +w for user modes, and /mode #channel +i for channels. Modes are unset using – instead of +, e.g. /mode #channel -i.
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. If your client implements its own help command, you may need to /quote help umode or /raw help umode.
| D (deaf) | This prevents you from receiving channel messages. You will probably not want to set this in most cases. (It is used by services.) |
| g (caller-id) | 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 enabled by default. |
| +l (see locops) | This umode lets you see the locops announcement system. Important network messages will be sent out via global notices; this is only for server-specific (unlike wallops, see below) non-critical announcements and comments which may be of interest. freenode staff are unlikely to send locops. |
| 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 channel modes. Some additional information about them is available by sending /help cmode to the server. If your client implements its own help command, you may need to /quote help cmode or /raw help cmode.
| b (channel ban) | Bans are used to prevent users from joining a channel. Sending /mode #channel +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 knock 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 voiced (+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 cloaked hostname. CIDR is supported in bans, like*!*@10.0.0.0/8. This is most useful with IPv6. EXTBANSThe second form (called extban) is +b $type or +b $type:data. Thetype is a single character (case insensitive) indicating the type of match. It is optionally preceded by a tilde (~) to negate the comparison. The data depends on extban type. Potential types are below:
CHANNEL FORWARDS IN BANSThe suffix $#channel can be appended to any of the above ban 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 (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 sometimes leave cruft sent to the channel, just without the escape characters themselves. | ||||||||||
| C (block CTCPS) | This mode blocks the sending of CTCP commands (other than /meactions) to whole channels. | ||||||||||
| e (ban exemption) | This mode takes one parameter, just like ban (above). Wildcards and extbans can be used, like ban. Ban exemption matches override +b and +q bans for all clients it matches, allowing the exempted user to join/speak as if they were not banned. 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 +bee *!*@*.example.com *!*someuser@host3.example.com $a:JohnDoe would block all users from example.com, while still allowing someuser from host3 and JohnDoe to join. | ||||||||||
| f (forward on uninvited) | This mode takes one parameter, a channel name. Users who cannot join the channel (because of +i, +j, +r, etc.) are instead sent to the channel given in +f. For example, /mode #channel1 +if #channel2would cause any users trying to join the channel and who are not in the invite-only exemption list (+I) to be sent to #channel2 instead. Clients receive a 470 numeric message which lists the original and the target channels. 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, invitations may only be sent by 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 or/msg ChanServ INVITE #channel 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 (with /mode #channel +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. You can use this mode to prevent 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 invite exemption lists. | ||||||||||
| m (moderated) | When a channel is set +m, only users who are opped or voiced on the channel can send to it. This mode does not prevent users without voice or op 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. 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. The user can join, but cannot speak in the channel or change nicks whilst in the channel. 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 #channel +q $~a can be used to prevent unregistered users from speaking in channel while allowing them to join. | ||||||||||
| s (secret channel) | This channel will not appear on channel lists or WHO or WHOIS output unless you are on it. | ||||||||||
| S (SSL-only) | Only users connected via SSL may join the channel while this mode is set. Users already in the channel are not affected. | ||||||||||
| 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. |