doc/modeg.txt

   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 $