]>
Commit | Line | Data |
---|---|---|
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 $ |