| 1 |
adx |
30 |
User Mode +g Documentation |
| 2 |
|
|
|
| 3 |
|
|
Hybrid 7 includes a new and power feature that all users can take advantage |
| 4 |
|
|
of to help prevent flooding and unwanted messages. This new feature is |
| 5 |
|
|
invoked by setting user mode +g. When a client is set +g, that user will |
| 6 |
|
|
be in "Caller ID" mode. Any user that messages a +g client will receive |
| 7 |
|
|
a numeric saying that they are in +g (server side ignore) mode. The target |
| 8 |
|
|
client (who is set +g) will also receive a numeric saying that so and so |
| 9 |
|
|
messaged them, and that they are in +g mode. |
| 10 |
|
|
|
| 11 |
|
|
The target of the message will only receive one notification per minute, from |
| 12 |
|
|
any client, in order to help prevent flooding. The sender will NOT have the |
| 13 |
|
|
rate limit, and will receive a numeric saying the target is in +g mode every |
| 14 |
|
|
time they send a message. Note that this behavior is similar to the way AWAY |
| 15 |
|
|
messages are done. |
| 16 |
|
|
|
| 17 |
|
|
There are numerous benefits for both opers and regular users, including the |
| 18 |
|
|
ability to stop spambot messages from ever reaching your client, stopping |
| 19 |
|
|
private message and CTCP floods, and being able to sit on IRC in privacy. |
| 20 |
|
|
|
| 21 |
|
|
There is also a softer variation of +g named +G, which allows people you see |
| 22 |
|
|
on your channels talk to you. In other words, messages from users/spambots |
| 23 |
|
|
sitting on no common channels with you are automagically blocked. |
| 24 |
|
|
|
| 25 |
|
|
One question that arises is how to message specific users, while blocking |
| 26 |
|
|
out everyone else. The command ACCEPT is your answer. To add a user to |
| 27 |
|
|
your accept list, issue the raw command ACCEPT <nick>,<nick>,<nick>,... |
| 28 |
|
|
|
| 29 |
|
|
You will not receive a reply from the ACCEPT command if it is successful, |
| 30 |
|
|
only if an error has occured. There are three possible errors, shown by |
| 31 |
|
|
numerics: |
| 32 |
|
|
|
| 33 |
|
|
ERR_ACCEPTFULL (456): :irc.server 456 client :Accept list is full |
| 34 |
|
|
- This is sent when an accept list is full. |
| 35 |
|
|
ERR_ACCEPTEXIST (457): :irc.server 457 client target :already exists |
| 36 |
|
|
- This is sent when a client tries to add a user to the accept list |
| 37 |
|
|
that already exists there |
| 38 |
|
|
ERR_ACCEPTNOT (458): :irc.server 458 client target :doesn't exist |
| 39 |
|
|
- This is sent when a client tries to remove a user from their accept |
| 40 |
|
|
list who is not on the accept list. |
| 41 |
|
|
|
| 42 |
|
|
That user will now be able to send messages to your client until the |
| 43 |
|
|
association is broken. |
| 44 |
|
|
|
| 45 |
|
|
Associations break in one of the following situations: when an accepted user |
| 46 |
|
|
QUIT's (or is on the other side of a split), you QUIT, or the accepted user |
| 47 |
|
|
changes their nick. The reason why a remote user's nick change will remove |
| 48 |
|
|
them from your accept list is so that you cannot track a user after they |
| 49 |
|
|
changed their nick. |
| 50 |
|
|
|
| 51 |
|
|
Viewing the accept list is also very easy. Issue the raw command ACCEPT *. |
| 52 |
|
|
Removing a user from your accept list is also simple. Issue the command |
| 53 |
|
|
ACCEPT -<nick>. |
| 54 |
|
|
|
| 55 |
|
|
Sample Session |
| 56 |
|
|
|
| 57 |
|
|
The easiest way to see how this works is by experiencing it. Seeing a sample |
| 58 |
|
|
session can help understand what goes on though. |
| 59 |
|
|
|
| 60 |
|
|
Client Hwy-LL is set +g initially. |
| 61 |
|
|
Client Hwy101 wants to message Hwy-LL |
| 62 |
|
|
|
| 63 |
|
|
Note that some clients may have to use /quote ACCEPT instead of /accept. |
| 64 |
|
|
|
| 65 |
|
|
-- |
| 66 |
|
|
|
| 67 |
|
|
Client Hwy101: /msg Hwy-LL hi |
| 68 |
|
|
Hwy101 will see: -Hwy-LL- *** I'm in +g mode (server side ignore). |
| 69 |
|
|
-Hwy-LL- *** I've been informed you messaged me. |
| 70 |
|
|
|
| 71 |
|
|
Hwy-LL will see: Client Hwy101 [wcampbel@admin.irc.monkie.org] is messaging |
| 72 |
|
|
you and you are +g |
| 73 |
|
|
|
| 74 |
|
|
The sender will receive the numeric from the target of the message, while |
| 75 |
|
|
the recipient will receive the numeric from the server. |
| 76 |
|
|
|
| 77 |
|
|
-- |
| 78 |
|
|
|
| 79 |
|
|
If Hwy101 sends another message to Hwy-LL (before the minute expires), he will |
| 80 |
|
|
see: -Hwy-LL- *** I'm in +g mode (server side ignore). |
| 81 |
|
|
and will not receive the second numeric |
| 82 |
|
|
|
| 83 |
|
|
Hwy-LL will NOT see any numeric. |
| 84 |
|
|
|
| 85 |
|
|
-- |
| 86 |
|
|
|
| 87 |
|
|
Hwy-LL now wishes to see messages from Hwy101 and SpamBot |
| 88 |
|
|
|
| 89 |
|
|
Client Hwy-LL: /accept Hwy101,SpamBot |
| 90 |
|
|
|
| 91 |
|
|
Neither side will be told of the change in the accept list, Hwy-LL should |
| 92 |
|
|
presume that the accept was successful if no error occurs. |
| 93 |
|
|
|
| 94 |
|
|
Now Hwy-LL can see messages from Hwy101 and SpamBot without any blockage. |
| 95 |
|
|
If Hwy101 was also set +g, then he would have to issue /accept Hwy-LL |
| 96 |
|
|
before he would be able to see messages from Hwy-LL. |
| 97 |
|
|
|
| 98 |
|
|
-- |
| 99 |
|
|
|
| 100 |
|
|
Hwy-LL now wants to see who is on his accept list. |
| 101 |
|
|
|
| 102 |
|
|
Client Hwy-LL: /accept * |
| 103 |
|
|
|
| 104 |
|
|
Hwy-LL will see: |
| 105 |
|
|
irc.server 281 Hwy-LL Hwy101 SpamBot |
| 106 |
|
|
irc.server 282 Hwy-LL :End of /ACCEPT list |
| 107 |
|
|
|
| 108 |
|
|
The replies are in numeric form to help parsing by scripts. |
| 109 |
|
|
-- |
| 110 |
|
|
|
| 111 |
|
|
Hwy-LL realises he added a spambot to his list, and wants to remove it, and |
| 112 |
|
|
allow messages from services |
| 113 |
|
|
|
| 114 |
|
|
Client Hwy-LL: /accept -SpamBot,services |
| 115 |
|
|
|
| 116 |
|
|
Hwy-LL will now only accept messages from Hwy101 and services. |
| 117 |
|
|
|
| 118 |
|
|
-- |
| 119 |
|
|
|
| 120 |
|
|
The nicks to be added can be in ANY order, however you cannot add or remove |
| 121 |
|
|
AND list. |
| 122 |
|
|
/ACCEPT x,y,-z,f,-a would be acceptable. |
| 123 |
|
|
/ACCEPT x,y,-z,* would ignore the * and generate an invalid nick |
| 124 |
|
|
response. |
| 125 |
|
|
|
| 126 |
|
|
Like Dalnet and Undernet's SILENCE system, the accept list only exists while |
| 127 |
|
|
you are connected to IRC. In order for you to have the same accept list |
| 128 |
|
|
every time you come onto IRC, you must put the accept commands into your |
| 129 |
|
|
client's auto-perform, or manually issue the commands each time. |
| 130 |
|
|
|
| 131 |
|
|
This system may seem similar to the SILENCE system, but it is actually a |
| 132 |
|
|
reverse SILENCE. SILENCE ignores certain users and allows the rest. Mode |
| 133 |
|
|
+g ignores all users except certain ones (on your accept list.) Both systems |
| 134 |
|
|
have their place, but the mode +g in Hybrid 7 is what the developers thought |
| 135 |
|
|
would be most useful for clients. |
| 136 |
|
|
|
| 137 |
|
|
The goals of this user mode is to provide protection from flooding and |
| 138 |
|
|
spamming, and to provide users with a means to keep their privacy. |
| 139 |
|
|
|
| 140 |
|
|
We hope that these goals are obtained. |
| 141 |
|
|
|
| 142 |
|
|
-- |
| 143 |
|
|
W. Campbell |
| 144 |
knight |
31 |
$Id$ |