~ubuntu-branches/ubuntu/trusty/charybdis/trusty-proposed

« back to all changes in this revision

Viewing changes to doc/modeg.txt

  • Committer: Package Import Robot
  • Author(s): Antoine Beaupré
  • Date: 2011-11-10 23:07:37 UTC
  • Revision ID: package-import@ubuntu.com-20111110230737-kqo6qsglp5oh02hr
Tags: upstream-3.3.0
Import upstream version 3.3.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
                         User Mode +g Documentation
 
2
 
 
3
Support of this specification is indicated by the CALLERID token in
 
4
RPL_ISUPPORT (005).  This token takes an optional parameter, of the letter
 
5
of the user mode.  If no parameter is specified, the user mode is g.  A
 
6
typical token would be: CALLERID=g
 
7
The rest of this specification will assume the user mode is g, as
 
8
implemented in hybrid, ratbox and charybdis.
 
9
 
 
10
Hybrid 7 includes a new and power feature that all users can take advantage
 
11
of to help prevent flooding and unwanted messages.  This new feature is 
 
12
invoked by setting user mode +g.  When a client is set +g, that user will
 
13
be in "Caller ID" mode.  Any user that messages a +g client will receive
 
14
a notice saying that they are in +g (server side ignore) mode.  The target
 
15
client (who is set +g) will also receive a notice saying that so and so
 
16
messaged them, and that they are in +g mode.
 
17
 
 
18
The target of the message will only receive one notification per minute, from
 
19
any client, in order to help prevent flooding.  The sender will NOT have the
 
20
rate limit, and will receive a numeric saying the target is in +g mode every
 
21
time they send a message.  Note that this behavior is similar to the way AWAY
 
22
messages are done.
 
23
 
 
24
There are numerous benefits for both opers and regular users, including the
 
25
ability to stop spambot messages from ever reaching your client, stopping
 
26
private message and CTCP floods, and being able to sit on IRC in privacy.
 
27
 
 
28
One question that arises is how to message specific users, while blocking
 
29
out everyone else.  The command ACCEPT is your answer.  To add a user to
 
30
your accept list, issue the raw command ACCEPT <nick>,<nick>,<nick>,...
 
31
 
 
32
You will not receive a reply from the ACCEPT command if it is succesful,
 
33
only if an error has occured.  There are three possible errors, shown by
 
34
numerics:
 
35
 
 
36
   ERR_ACCEPTFULL (456): :irc.server 456 client :Accept list is full
 
37
     - This is sent when an accept list is full.
 
38
   ERR_ACCEPTEXIST (457): :irc.server 457 client target :already exists
 
39
     - This is sent when a client tries to add a user to the accept list
 
40
       that already exists there
 
41
   ERR_ACCEPTNOT (458): :irc.server 458 client target :doesnt exist
 
42
     - This is sent when a client tries to remove a user from their accept
 
43
       list who is not on the accept list.
 
44
 
 
45
That user will now be able to send messages to your client until the
 
46
association is broken.
 
47
 
 
48
Associations break in one of the following situations:  when an accepted user
 
49
QUIT's (or is on the other side of a split), you QUIT, or the accepted user
 
50
changes their nick.  The reason why a remote user's nick change will remove
 
51
them from your accept list is so that you cannot track a user after they
 
52
changed their nick.
 
53
 
 
54
Viewing the accept list is also very easy.  Issue the raw command ACCEPT *.
 
55
Removing a user from your accept list is also simple.  Issue the command
 
56
ACCEPT -<nick>.  
 
57
 
 
58
The ACCEPT command can be used whether or not +g is enabled at the time.
 
59
Setting -g does not clear the accept list.
 
60
 
 
61
Some users (in particular IRC operators and services) may be exempt from
 
62
CallerID, and able to message a +g user without being on their accept list.
 
63
 
 
64
Being on the accept list may allow a user to bypass more than +g (for example,
 
65
a +R user can use the ACCEPT command to receive messages from unidentified
 
66
users in charybdis).
 
67
 
 
68
                              Sample Session
 
69
 
 
70
The easiest way to see how this works is by experiencing it.  Seeing a sample
 
71
session can help understand what goes on though.
 
72
 
 
73
Client Hwy-LL is set +g initially.
 
74
Client Hwy101 wants to message Hwy-LL
 
75
 
 
76
Note that some clients may have to use /quote ACCEPT instead of /accept.
 
77
 
 
78
--
 
79
 
 
80
Client Hwy101:  /msg Hwy-LL hi
 
81
Hwy101 will see:  -!- Hwy-LL is in +g mode (server-side ignore.)
 
82
                  -!- Hwy-LL has been informed that you messaged them.
 
83
 
 
84
Hwy-LL will see:  -!- Hwy101 wcampbel@admin.irc.monkie.org is messaging you, and you have umode +g.
 
85
 
 
86
--
 
87
 
 
88
If Hwy101 sends another message to Hwy-LL (before the minute expires), he will
 
89
see:  -!- Hwy-LL is in +g mode (server-side ignore.)
 
90
and will not receive the second notice
 
91
 
 
92
Hwy-LL will NOT see any notice. This also applies if the second message comes
 
93
from a different user.
 
94
 
 
95
--
 
96
 
 
97
Hwy-LL now wishes to see messages from Hwy101 and SpamBot
 
98
 
 
99
Client Hwy-LL:  /accept Hwy101,SpamBot
 
100
 
 
101
Neither side will be told of the change in the accept list, Hwy-LL should
 
102
presume that the accept was succesful if no error occurs.
 
103
 
 
104
Now Hwy-LL can see messages from Hwy101 and SpamBot without any blockage.
 
105
If Hwy101 was also set +g, then he would have to issue /accept Hwy-LL
 
106
before he would be able to see messages from Hwy-LL.
 
107
 
 
108
--
 
109
 
 
110
Hwy-LL now wants to see who is on his accept list.
 
111
 
 
112
Client Hwy-LL:  /accept *
 
113
 
 
114
Hwy-LL will see:
 
115
  irc.server 281 Hwy-LL Hwy101 SpamBot
 
116
  irc.server 282 Hwy-LL :End of /ACCEPT list
 
117
 
 
118
The replies are in numeric form to help parsing by scripts.
 
119
--
 
120
 
 
121
Hwy-LL realises he added a spambot to his list, and wants to remove it, and
 
122
allow messages from services
 
123
 
 
124
Client Hwy-LL:  /accept -SpamBot,services
 
125
 
 
126
Hwy-LL will now only accept messages from Hwy101 and services.
 
127
 
 
128
--
 
129
 
 
130
The nicks to be added can be in ANY order, however you cannot add or remove
 
131
AND list.  
 
132
    /ACCEPT x,y,-z,f,-a would be acceptable.
 
133
    /ACCEPT x,y,-z,* would ignore the * and generate an invalid nick
 
134
                     response.
 
135
 
 
136
Like Dalnet and Undernet's SILENCE system, the accept list only exists while
 
137
you are connected to IRC.  In order for you to have the same accept list
 
138
every time you come onto IRC, you must put the accept commands into your 
 
139
client's auto-perform, or manually issue the commands each time.  
 
140
 
 
141
This system may seem similar to the SILENCE system, but it is actually a
 
142
reverse SILENCE.  SILENCE ignores certain users and allows the rest.  Mode
 
143
+g ignores all users except certain ones (on your accept list.)  Both systems
 
144
have their place, but the mode +g in Hybrid 7 is what the developers thought
 
145
would be most useful for clients.
 
146
 
 
147
The goals of this user mode is to provide protection from flooding and
 
148
spamming, and to provide users with a means to keep their privacy.
 
149
 
 
150
We hope that these goals are obtained.
 
151
 
 
152
Numeric replies
 
153
---------------
 
154
 
 
155
280 - RPL_ACCEPTLIST
 
156
--------------------
 
157
:<server> 280 <nick> <accepted1> <accepted2> ...
 
158
 
 
159
This numeric is used to indicate to a client the list of nicknames they are
 
160
accepting. At most 15 accepted nicknames may be included; if this is exceeded
 
161
multiple RPL_ACCEPTLIST must be sent.
 
162
 
 
163
281 - RPL_ENDOFACCEPT
 
164
---------------------
 
165
:<server> 281 <nick> :End of /ACCEPT list.
 
166
 
 
167
This numeric is used to indicate to a client the end of an accept list.
 
168
 
 
169
456 - ERR_ACCEPTFULL
 
170
--------------------
 
171
:<server> 456 <nick> :Accept list is full
 
172
 
 
173
This numeric is used to indicate to a client that their accept list is full
 
174
and one or more nicks could not be added.
 
175
 
 
176
457 - ERR_ACCEPTEXIST
 
177
---------------------
 
178
:<server> 457 <nick> <target> :is already on your accept list
 
179
 
 
180
This numeric is used to indicate to a client that the given nick was already
 
181
on their accept list.
 
182
 
 
183
458 - ERR_ACCEPTNOT
 
184
-------------------
 
185
:<server> 458 <nick> <target> :is not on your accept list
 
186
 
 
187
This numeric is used to indicate to a client that the given nick was not on
 
188
their accept list.
 
189
 
 
190
716 - ERR_TARGUMODEG
 
191
--------------------
 
192
:<server> 716 <nick> <target> :is in +g mode (server-side ignore.)
 
193
 
 
194
This numeric is used to indicate that a message (PRIVMSG) the client sent
 
195
could not be delivered because of CallerID restrictions. The <target>
 
196
parameter is the target user's nick.
 
197
 
 
198
717 - RPL_TARGNOTIFY
 
199
--------------------
 
200
:<server> 717 <nick> <target> :has been informed that you messaged them.
 
201
 
 
202
This numeric is sent after 716 if the target user was notified of the message.
 
203
 
 
204
718 - RPL_UMODEGMSG
 
205
-------------------
 
206
:<server> 718 <nick> <target> <user>@<host> :is messaging you, and you have umode +g.
 
207
 
 
208
This numeric is sent when a message (PRIVMSG or NOTICE) sent to the user is
 
209
blocked by CallerID, at most once per minute.
 
210
 
 
211
Problem: hybrid uses the following form instead
 
212
:<server> 718 <nick> <target>[<user>@<host>] :is messaging you, and you have umode +g.
 
213
which is ambiguous if the user may contain a [ and in the author's opinion ugly.
 
214
 
 
215
--
 
216
W. Campbell
 
217
updated by J. Tjoelker
 
218
$Id: modeg.txt 3556 2007-08-18 14:45:10Z jilles $