| 1 |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| 2 |
<html> |
| 3 |
<head> |
| 4 |
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"> |
| 5 |
<title>IRC Services Manual - 1. About IRC Services</title> |
| 6 |
</head> |
| 7 |
|
| 8 |
<body> |
| 9 |
<a name=top></a> |
| 10 |
<h1 align=center>IRC Services Manual</h1> |
| 11 |
|
| 12 |
<h2 align=center>1. About IRC Services</h2> |
| 13 |
|
| 14 |
<p>1-1. <a href="#1">Introduction</a> |
| 15 |
<br>1-2. <a href="#2">Overview of IRC Services clients</a> |
| 16 |
<br>1-3. <a href="#3">IRC Services download site</a> |
| 17 |
<br>1-4. <a href="#4">IRC Services discussion forums</a> |
| 18 |
<br>1-5. <a href="#5">Credits and acknowledgements</a> |
| 19 |
<br>1-6. <a href="#6">Contacting the author</a> |
| 20 |
|
| 21 |
<p align=right><font size=-1><a href=index.html>Table of Contents</a> | |
| 22 |
<a href=2.html>Next section: About IRC Services</a></font> |
| 23 |
|
| 24 |
<p><hr> |
| 25 |
|
| 26 |
<a name=1></a> |
| 27 |
<h3>1-1. Introduction</h3> |
| 28 |
|
| 29 |
<p>IRC Services (also called just "Services" for short) is a system of |
| 30 |
services to be used with Internet Relay Chat networks. Services provides |
| 31 |
for definitive nickname and channel ownership, as well as the ability to |
| 32 |
send messages ("memos") to offline users, and gives IRC operators |
| 33 |
considerably more control over the network. |
| 34 |
|
| 35 |
<p>In particular, Services provides the following features to an IRC |
| 36 |
network: |
| 37 |
|
| 38 |
<p><ul> |
| 39 |
<li><b>Nickname management.</b> Services allows users to "register" |
| 40 |
nicknames, and will prevent users other than the registrant from using |
| 41 |
them. Services also maintains information about each registered nickname, |
| 42 |
including the last time the nick's owner was online as well as a URL and |
| 43 |
E-mail address that can be set by the user. |
| 44 |
|
| 45 |
<li><b>Channel management.</b> Like nicknames, Services allows users to |
| 46 |
register channels as well. A channel's owner can give privileges to other |
| 47 |
users of the channel, such as auto-opping or the ability to set various |
| 48 |
channel options, or conversely deny other users the ability to obtain |
| 49 |
channel operator privileges or even enter the channel altogether. Services |
| 50 |
will remember the topic on the channel even after the last user leaves, and |
| 51 |
can automatically set modes on the channel whenever a user joins it. |
| 52 |
|
| 53 |
<li><b>Messages to offline users.</b> Probably every IRC user has gone |
| 54 |
through the experience of waiting and waiting for someone to come online in |
| 55 |
order to pass a message along or ask a question. Services alleviates this |
| 56 |
with a "memo" system, allowing users to leave messages for other users even |
| 57 |
if the recipient is not online at the time; the recipient will be notified |
| 58 |
of the memo the next time they log on. |
| 59 |
|
| 60 |
<li><b>Centralized network control.</b> Services includes features which |
| 61 |
allow IRC operators greater control over the IRC network through a single |
| 62 |
point, and also defines multiple privilege levels for IRC operators with |
| 63 |
respect to Services itself. For example, IRC operators with sufficient |
| 64 |
privileges can use Services to set modes on any channel; it is also |
| 65 |
possible to ban users or groups of users from connecting to the network |
| 66 |
entirely, and such bans ("autokills" in Services terminology) will remain |
| 67 |
active even if a server, or Services itself, splits from the network. |
| 68 |
</ul> |
| 69 |
|
| 70 |
<p>Furthermore, each of these sets of features can be configured or |
| 71 |
disabled to match individual networks' policies. |
| 72 |
|
| 73 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
| 74 |
|
| 75 |
<p><hr> |
| 76 |
|
| 77 |
<a name=2></a> |
| 78 |
<h3>1-2. Overview of Services clients</h3> |
| 79 |
|
| 80 |
<p>Each of the major feature groups mentioned in <a href="#1">section |
| 81 |
1-1</a> above is controlled through a Services <i>client</i>, a nickname |
| 82 |
associated with that particular set of features. (These are often called |
| 83 |
"pseudoclients", since they are not true clients, like IRC programs used by |
| 84 |
humans, but conveniences to simplify access to Services' features.) These |
| 85 |
clients, as well as others which handle smaller areas of network control, |
| 86 |
are briefly described below; a more detailed discussion of each feature is |
| 87 |
presented in <a href=3.html>section 3</a>, while complete information on |
| 88 |
each of the commands used to control each client can be found in |
| 89 |
<a href=4.html>section 4</a>. |
| 90 |
|
| 91 |
<p><b>NickServ</b> handles registration and maintenance of nicknames. Its |
| 92 |
primary functions include: |
| 93 |
<p> |
| 94 |
<ul><li>registration and de-registration (dropping) of nicknames; |
| 95 |
<li>verification of nickname users, including password authentication, |
| 96 |
and removal (either automatically or upon request) of unauthorized |
| 97 |
users; |
| 98 |
<li>creation and deletion of nickname aliases (links), which allow a |
| 99 |
single user to own and switch between multiple nicknames which |
| 100 |
share settings; |
| 101 |
<li>control of nickname options, including security level (whether to |
| 102 |
require a password or simply check the user's username and |
| 103 |
hostname), associated URL and E-mail address, and what information |
| 104 |
to show or not show to other users; |
| 105 |
<li>recording of nickname usage information, including the nickname's |
| 106 |
last used time and the username and hostname of the nickname's last |
| 107 |
user; and |
| 108 |
<li>expiration of nicknames that have not been used in a certain period |
| 109 |
of time.</ul> |
| 110 |
|
| 111 |
<p>Services has the ability to send messages to users in multiple |
| 112 |
languages; a user who has registered their nickname can select from any of |
| 113 |
the supported languages (English, Dutch, French, German, Hungarian, |
| 114 |
Japanese, Russian, Spanish, and Turkish). A default language can also be |
| 115 |
configured for users who have not registered their nicknames or have not |
| 116 |
selected a specific language. |
| 117 |
|
| 118 |
<p>Furthermore, NickServ has the ability to verify E-mail addresses |
| 119 |
associated with nicknames, by sending an "authentication code" to the |
| 120 |
E-mail address and not allowing the owner any privileges associated with |
| 121 |
the nickname until the owner sends that authentication code back to |
| 122 |
NickServ. This feature can help maintain accountability of users for their |
| 123 |
actions on IRC by requiring a valid E-mail address at which the user of a |
| 124 |
nickname can be contacted if problems arise. |
| 125 |
|
| 126 |
<p><b>ChanServ</b> is to channels what NickServ is to nicknames; it handles |
| 127 |
registration and maintenance of channels on the IRC network. Its functions |
| 128 |
in large part mirror those of NickServ, and include: |
| 129 |
<p> |
| 130 |
<ul><li>registration and dropping of channels (a user who registers a |
| 131 |
channel is known as the channel's <i>founder</i>); |
| 132 |
<li>verification of channel users, through either direct password |
| 133 |
authentication or NickServ verification; |
| 134 |
<li>control of channel access and autokick lists (see below); |
| 135 |
<li>monitoring and adjustment of channel modes, including automatically |
| 136 |
giving channel-operator or voice privileges or "inviting" |
| 137 |
authorized users into invite-only channels; |
| 138 |
<li>control of channel options, such as preventing users from changing |
| 139 |
the topic or controlling the strictness with which channel modes |
| 140 |
and privileges are enforced, and setting a URL or E-mail address |
| 141 |
for the channel; |
| 142 |
<li>recording of channel usage information, including the last time a |
| 143 |
verified user was in the channel; and |
| 144 |
<li>expiration of channels that have not been used in a certain period |
| 145 |
of time. |
| 146 |
</ul> |
| 147 |
|
| 148 |
<p>One major difference between nicknames and channels is the <i>access |
| 149 |
list</i>. While nicknames may have an "access list" that lists addresses |
| 150 |
which NickServ will recognize as "allowed to use the nickname"—a |
| 151 |
feature that has little value if passwords are used as the primary means of |
| 152 |
verification—channel access lists play a much greater role, in that |
| 153 |
they control which users (nicknames) have what degree of access to |
| 154 |
(privileges in) the channel. The founder of a channel will always have |
| 155 |
full access to the channel, but the founder can, via the access list, |
| 156 |
designate other users who will receive a certain subset of channel |
| 157 |
privileges. For example, the founder might give privileges to some users |
| 158 |
to automatically receive channel operator (<tt>+o</tt>) status when they |
| 159 |
enter the channel; those users might then, in turn, designate other users |
| 160 |
to automatically receive voice (<tt>+v</tt>) status if the channel is |
| 161 |
moderated. Certain levels of access also allow users to use privileged |
| 162 |
ChanServ features, such as management of the "autokick list", explained |
| 163 |
below, or commands which remove channel bans on a user or invite the user |
| 164 |
into a channel. |
| 165 |
|
| 166 |
<p>Conversely, the <i>autokick list</i> (often referred to as the "AKICK |
| 167 |
list", from the name of the command—<tt>AKICK</tt>—which |
| 168 |
controls it) specifies users which are not to be allowed access to the |
| 169 |
channel at all. If a user joins a channel whose autokick list they are |
| 170 |
listed on, ChanServ will kick them out of the channel and set a channel ban |
| 171 |
which prevents them from entering again. Since a malicious user could |
| 172 |
easily enter using an unregistered nickname, channel founders (or other |
| 173 |
privileged users) can enter username/hostname masks as well as nicknames in |
| 174 |
the autokick list. |
| 175 |
|
| 176 |
<p>As channels are complex beasts, ChanServ features many options which |
| 177 |
control how the channel is managed; for example, ChanServ can be set to |
| 178 |
disallow any changes to the channel topic (if a user changes the topic, |
| 179 |
ChanServ will cancel the change by restoring the previous topic), or to |
| 180 |
prevent any users not explicitly entered in the access list from using the |
| 181 |
channel. ChanServ can also enforce a certain set of modes on a channel; |
| 182 |
for example, a channel which wants to stay hidden from casual users could |
| 183 |
use ChanServ to ensure that the <tt>+s</tt> (secret) mode is always set on |
| 184 |
the channel. |
| 185 |
|
| 186 |
<p>If the founder of a channel loses his nickname, whether by explicitly |
| 187 |
dropping it or by letting it expire, the channel will be dropped as well. |
| 188 |
If this should happen by accident, it can be difficult to restore all of |
| 189 |
the channel settings. To help avoid this problem, ChanServ allows channel |
| 190 |
founders to designate a <i>successor</i> for the channel. If the founder's |
| 191 |
nickname should ever be dropped or expire, then ChanServ will give the |
| 192 |
channel to the successor—making them the new founder of the |
| 193 |
channel—rather than dropping the channel. |
| 194 |
|
| 195 |
<p><b>MemoServ</b> handles storage and notification of <i>memos</i>, short |
| 196 |
messages between IRC users. Memos can be thought of as an intermediate |
| 197 |
stage between realtime chat and E-mail; they are sent and read in the same |
| 198 |
way as ordinary chatting, but can be sent even if the recipient is not |
| 199 |
online at the time, and the recipient can read the memos at his or her |
| 200 |
leisure. Memos are particularly useful for short messages for which it |
| 201 |
would not be worth the time to start up an E-mail client and type out a |
| 202 |
complete message, or for cases where the nickname of the recipient is known |
| 203 |
but the recipient's E-mail address is not (or the recipient does not have |
| 204 |
an E-mail address at all). |
| 205 |
|
| 206 |
<p>MemoServ's four main functions are <i>sending</i> memos, <i>listing</i> |
| 207 |
memos which have been received, <i>reading</i> memos, and <i>deleting</i> |
| 208 |
memos after they have been read. Users can also set memo options, which |
| 209 |
include whether to notify them of new memos when they log on and whether |
| 210 |
they should be able to receive memos at all, and can have memos |
| 211 |
automatically forwarded to an authenticated E-mail address. |
| 212 |
|
| 213 |
<p>In addition to memos between users, memos can also be sent to channels; |
| 214 |
such memos will be sent to all users with sufficient privileges on the |
| 215 |
channel. This type of memo can be used, for example, to inform channel |
| 216 |
operators about a problem user, or as a way for users to ask questions |
| 217 |
about the channel. |
| 218 |
|
| 219 |
<p><b>OperServ</b> provides access to the "network control" functionality |
| 220 |
of Services. Available only to IRC operators, OperServ allows: |
| 221 |
<p> |
| 222 |
<ul><li>broadcasts of messages to the entire network (global notices), as |
| 223 |
well as recording of news messages to be sent to users when they |
| 224 |
connect to the network; |
| 225 |
<li>control of modes in any channel, as well as the ability to kick any |
| 226 |
user from any channel; |
| 227 |
<li>banning certain users from the entire network (autokill list and |
| 228 |
S-lines, described below); |
| 229 |
<li>limiting the number of users which can connect from a single IP |
| 230 |
address, useful for preventing "cloning" (sessions), as well as |
| 231 |
making exceptions to those limits; |
| 232 |
<li>disconnecting all users from a given IP address; |
| 233 |
<li>preventing certain servers from connecting to the network |
| 234 |
("juping"); |
| 235 |
<li>setting global Services options; and |
| 236 |
<li>restarting or shutting down Services itself. |
| 237 |
</ul> |
| 238 |
|
| 239 |
<p>Many of these functions can, if misused, have disastrous effects for the |
| 240 |
entire network; thus, OperServ implements a privilege system to limit which |
| 241 |
IRC operators can use which functions. Four different privilege levels are |
| 242 |
defined: normal IRC operator, Services operator, Services administrator, |
| 243 |
and Services super-user (also known as "Services root", from the Unix |
| 244 |
tradition of using the username "root" for the system super-user). Normal |
| 245 |
IRC operators can use very few of the functions above, while the Services |
| 246 |
super-user has absolute control over Services and the IRC network. |
| 247 |
|
| 248 |
<p>Of particular note are the <i>autokill list</i> and <i>S-line</i> |
| 249 |
features, which are to the network as autokick lists are to channels; users |
| 250 |
in these lists will be prohibited from connecting to any server on the |
| 251 |
network, and will be disconnected immediately if they do connect. The |
| 252 |
difference between the two is what they prohibit; the autokill list |
| 253 |
prohibits certain combinations of username and hostname, much like autokick |
| 254 |
lists do, while S-lines, named after the commands used by a certain IRC |
| 255 |
server to implement them, prohibit nicknames, "real names", or IP addresses |
| 256 |
(IP address checking is only available with a few IRC servers). |
| 257 |
|
| 258 |
<p>OperServ also includes a separate client, by default called |
| 259 |
<b>Global</b>, which is used to send global (network-wide) notices and news |
| 260 |
messages to users. Many networks rename this client to the same name as |
| 261 |
their network; the name of the client (as well as all other Services |
| 262 |
clients) can be changed by editing the configuration file, as described in |
| 263 |
<a href="2.html#4">section 2-4</a>. |
| 264 |
|
| 265 |
<p><b>StatServ</b> is an additional client which monitors and keeps basic |
| 266 |
statistical information regarding network usage. It can be useful to |
| 267 |
check, for example, which servers are getting the most use, or whether |
| 268 |
certain servers have a tendency to split from the network frequently. |
| 269 |
|
| 270 |
<p><b>In addition</b> to the clients above, Services also has a built-in |
| 271 |
HTTP (web) server, which allows access to Services information (such as |
| 272 |
registered nickname and channel information and network statistics) without |
| 273 |
having to connect to the IRC network. See <a href="3.html#6">section |
| 274 |
3-6</a> for more information about the HTTP server. |
| 275 |
|
| 276 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
| 277 |
|
| 278 |
<p><hr> |
| 279 |
|
| 280 |
<a name=3></a> |
| 281 |
<h3>1-3. IRC Services download site</h3> |
| 282 |
|
| 283 |
<p>Development and maintenance of IRC Services has been discontinued. |
| 284 |
As of the writing of this manual, historical information can be found at |
| 285 |
<a href="http://achurch.org/services/"><tt>http://achurch.org/services/</tt></a>. |
| 286 |
|
| 287 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
| 288 |
|
| 289 |
<p><hr> |
| 290 |
|
| 291 |
<a name=4></a> |
| 292 |
<h3>1-4. IRC Services discussion forums</h3> |
| 293 |
|
| 294 |
<p>Two mailing lists were previously provided for discussion of Services: |
| 295 |
<i>ircservices</i>, for general discussion, and <i>ircservices-coding</i>, |
| 296 |
for technical issues. These mailing lists were disabled on January 1, 2010, |
| 297 |
but archives of the lists are available at the historical information site |
| 298 |
listed in <a href="#3">section 1-3</a> above. |
| 299 |
|
| 300 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
| 301 |
|
| 302 |
<p><hr> |
| 303 |
|
| 304 |
<a name=5></a> |
| 305 |
<h3>1-5. Credits and acknowledgements</h3> |
| 306 |
|
| 307 |
<p>Services is primarily the work of <a href="http://achurch.org/"><b>Andrew |
| 308 |
Church</b></a>, and was developed from early 1996 through 2009; a somewhat |
| 309 |
more detailed history can be found in <a href="tech/1.html#s3">section 1-3 |
| 310 |
of the technical manual</a>. However, many people have contributed ideas, |
| 311 |
bug reports, or other help to the project as well. Some of the more |
| 312 |
noteworthy contributors include: |
| 313 |
<ul> |
| 314 |
<li><b>Andrew Kempe</b> (session limiting and news systems, as well as |
| 315 |
maintenance and development of Services for versions 4.3 and 4.4) |
| 316 |
<li><b>Yusuf Iskenderoglu</b> (Turkish translation and many feature suggestions) |
| 317 |
<li><b>Martin Pels</b> (Dutch translation) |
| 318 |
<li><b>Elijah</b> (French translation) |
| 319 |
<li><b>Jacek Margos</b> and <b>Holger Baust</b> (German translation) |
| 320 |
<li><b>Janos Kapitany</b> and <b>Krisztian Romek</b> (Hungarian translation) |
| 321 |
<li><b>Alexander Zverev</b> (Russian translation) |
| 322 |
<li><b><RealCFC@chatfirst.com></b> (Spanish translation) |
| 323 |
</ul> |
| 324 |
Credit is given to all contributions in the |
| 325 |
<tt><a href="Changes">Changes</a></tt> and |
| 326 |
<tt><a href="Changes.old">Changes.old</a></tt> files in this directory, |
| 327 |
which detail all changes made in each version of Services. |
| 328 |
|
| 329 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
| 330 |
|
| 331 |
<p><hr> |
| 332 |
|
| 333 |
<a name=6></a> |
| 334 |
<h3>1-6. Contacting the author</h3> |
| 335 |
|
| 336 |
<p>The author may be contacted via E-mail at |
| 337 |
<tt><a href="mailto:achurch@achurch.org">achurch@achurch.org</a></tt> |
| 338 |
as of the writing of this manual. |
| 339 |
|
| 340 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
| 341 |
|
| 342 |
<p><hr> |
| 343 |
|
| 344 |
<p align=right><font size=-1><a href=index.html>Table of Contents</a> | |
| 345 |
<a href=2.html>Next section: About IRC Services</a></font> |
| 346 |
|
| 347 |
</body> |
| 348 |
</html> |
