]> 30 June 2001 Users guide for the dancer IRC server Andrew Suffield
asuffield@users.sourceforge.net
2001 Andrew Suffield Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation A copy of the license is included in the section entitled "GNU Free Documentation License".
Introduction This document describes how normal users can interact via the dancer IRC server. It is intended as a guide and reference for users and channel operators, specifically on the Open Projects network (OPN). This is not a beginners guide to IRC. For help with general IRC commands, visit www.irchelp.org. This document only extends to the things which are different in dancer, and channel management on OPN. OPN exists primarily to provide IRC hosting for opensource projects and things associated with them, along with all kinds of other community-oriented groups. Note that it is not primarily a chat network, and it is most definately not for pr0n/music/warez trading or cracker activities. It's IRC server has been designed to promote calm, reasoned discourse, in accordance with OPN philosophy. Changes Dancer is an ircd derived from hybrid, as used on efnet, but with a large number of things changed to make it better suit the openprojects centrally-maintained network. Additionally, OPN runs a full services implementation, which protects channels and nicks. Please work with services rather than using bots where possible. If you have a situation which services genuinly cannot handle, please tell us. If something is genuinely lacking, it might be added/changed (assuming it is in line with OPN philosophy). Regardless of it's hybrid origins, a rather large number of things have been added to dancer. Here is a (long) list of the things which are different: Server side flood control. Various kinds of floods can be detected and throttled by the server. Sufficiently large floods will cause a client to be dropped from the network. & and + channels are disabled. Only # channels are now supported. & channels are inappropriate for OPN, and + channels are largely ineffective. If you want to use a channel without ops, in the short term you can simply create it and deop yourself. If you want to run a long term channel without ops, you can ask the network administrators in #openprojects to mark it as a permanent channel. It will then be impossible to gain ops on the channel, effectively emulating a + channel. QUIT and PART reasons from users will be quoted with "s. This prevents a person from spoofing a server notice in their quit/part reason. These messages, as well as AWAY messages, will be stripped of all colour codes. Various desync issues are no longer present. In particular, a channel topic will no longer be lost to netsplits. If a user is set invisible (umode +i), then issuing a WHOIS on them will not show any channels they are on, except for ones which you are also on (effectively only showing places you can already see them). If you want to know what channels they are on, ask them! Remote WHOIS messages are forbidden, and also pointless. These are WHOIS messages where you either give a server name and a nick, or the same nick twice. Idle times will be shown in all WHOIS messages. If a user has identified with nickserv, this will be noted in their WHOIS. Server routing is no longer generally known. MAP is disabled, and LINKS will only return a list of servers, not how they are connected up. IRC operators are no longer visible. If you need assistance from network admin, go to #openprojects. [, \, ], and ^ will no longer be treated as the same characters as {, |, }, and ~ by the server. This affects channel names and nicks. Channel names may not contain colour codes or other control character junk. Channel mode (cmode) +c has been added. When set, colours, bold, underline, reverse video, ANSI escape sequences, flashing text, and beeps will all be filtered from channel traffic. cmode +q is a new form of ban. These "quiets" are used like bans, but they don't prevent a person from joining the channel, they merely prevent them from speaking on it. Quiets will show up in the banlist as normal, but the ban mask will be prefixed by a %. Channel forwarding, which can shift users between channels and set up antechamber models, and channels which never lose their ban lists, modes, or topics (even when empty) are available in special cases. If you have a really good reason to want this in your channel, contact OPN administration in #openprojects. For now, these features are restricted until it is fully understood what their consequences are. Various new user modes (umodes) are available, see the users section for full details. Users and umodes User modes (umodes) are set with the MODE command, in most clients either "/umode +i" or "/mode mynick +i". Here is a list of the ones which are available for general use: +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 umode. +w (see wallops) This umode lets you see the wallops announcement system. Important network messages will be sent out via global notices; this is only for individual channel announcements and anything else the network staff feel like saying to the world in general (moo!). +I (block invite) This umode prevents anybody from inviting you to a channel. It effectively limits you to public channels or to those you are on the invex lists for. (It can safely be used to block somebody who is invite flooding) +E (block unidentified) This umode prevents people who have not identified with nickserv from sending you private messages (they will be told their messages are bouncing). +C (block CTCP) This umode prevents you from receiving CTCP messages or sending CTCP replies. This will stop anybody from CTCP flooding you. Note that this only affects CTCP messages/replies to/from *you*; it won't stop you receiving channel CTCP, although it will block your response to them. Note that this will interfere with CTCP ACTION messages (/me), so it is not recommended it be used unless absolutely necessary. Channel management It is strongly recommended that channels be registered on OPN. To do this, become a channel operator somehow and "/msg chanserv register #channel password". You can access full online help for chanserv, as well as the other services, with "/msg chanserv help". The channel access list controls who can do what on the channel, and allows considerable flexibility. Use this rather than channel management bots, it's more reliable and avoids sillyness like IRC wars. Channel bans and quiets both prevent a person from talking on the channel, but it is recommended that you use quiets (+q) if you merely want to shut somebody up; bans are rather deprecated for this purpose and their semantics will change at some point in the future. Generally you should assume that a ban means you don't want the person on the channel, while a quiet means you don't want them saying anything. Please don't kick people, it's rarely necessary or appropriate, and it generates needless noise (as well as raising the channel temperature). Hybrid (and therefore dancer) provides ban exceptions. If you have problems from an ISP which allows users to trivially change their IP addresses then you may find yourself forced to place a ban on the entire ISP. This often catches legitimate users. Set ban exceptions just like normal bans, but with mode +e (/mode #channel +e nick!user@host). These users will then be exempt from bans. You can then ban by host, but allow specific users by nick, should you need to. Another system available is the channel invex list. A channel which is set +i is invite-only, but masks can be added to the invex list with mode +I in the same manner, and the people on the list will be able to join without being invited. Note that services cannot (at present) maintain invex or exception lists. If a person needs permanent access, then add them to the channel access list in chanserv with a level that gives them CMDINVITE access; then can then /msg chanserv invite #channel and chanserv will invite them. &fdl;