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> |