| 1 |
User mode 'g' documentation |
| 2 |
|
| 3 |
Since version 7, ircd-hybrid includes a new and powerful feature that all users |
| 4 |
can take advantage of to prevent flooding and unwanted messages. This new |
| 5 |
feature is invoked by setting user mode 'g'. When set, user will be in |
| 6 |
'Caller ID' mode. Any user that messages a +g client will receive a numeric |
| 7 |
saying that they are in +g mode (server side ignore). The target client will |
| 8 |
also receive a numeric saying that so and so messaged them and that they are in |
| 9 |
user mode 'g'. |
| 10 |
|
| 11 |
The target of the message will only receive one notification per minute, from |
| 12 |
any client, in order to prevent flooding. The sender will NOT have that rate |
| 13 |
limit and will receive a numeric saying the target is in user mode 'g' every |
| 14 |
time they send a message. Note that this behavior is similar to the way AWAY |
| 15 |
messages are done. |
| 16 |
|
| 17 |
There is also a softer variation of 'g', named 'G', which allows people you |
| 18 |
share channels with to talk to you. In other words, messages from users/ |
| 19 |
spambots sitting on no common channels with you are automatically blocked. |
| 20 |
|
| 21 |
One question that arises is how to message specific users, while blocking out |
| 22 |
everyone else. The command 'ACCEPT' is your answer. It takes comma-separated |
| 23 |
parameters of users to be added or removed, in the form of 'nick!user@host' |
| 24 |
mask. If only nick is specified, the IRCD will convert it to 'nick!*@*'. |
| 25 |
|
| 26 |
You will not receive a reply from the 'ACCEPT' command if it is successful, only |
| 27 |
if an error has occured. There are three possible errors, shown by numerics: |
| 28 |
|
| 29 |
ERR_ACCEPTFULL (456): :irc.example.net 456 user :Accept list is full |
| 30 |
- This is sent when the accept list is full. |
| 31 |
ERR_ACCEPTEXIST (457): :irc.example.net 457 user n!u@h :is already on your accept list |
| 32 |
- This is sent when a client tries to add a mask to their accept list that |
| 33 |
already exists there. |
| 34 |
ERR_ACCEPTNOT (458): :irc.example.net 458 user n!u@h :is not on your accept list |
| 35 |
- This is sent when a client tries to remove a mask from their accept list |
| 36 |
that is not there. |
| 37 |
|
| 38 |
Once user is accepted, your client will keep receiving messages from it until |
| 39 |
one of the following happens: user is manually removed from your accept list, |
| 40 |
you quit or they change their nick (if mask is based only on nick). |
| 41 |
|
| 42 |
Viewing the accept list is very easy. Issue 'ACCEPT *' or 'ACCEPT' without |
| 43 |
parameters. |
| 44 |
Removing a mask from your accept list is also simple. Issue 'ACCEPT -<mask>'. |
| 45 |
|
| 46 |
You can add and remove masks at once, but you can't request list. |
| 47 |
'ACCEPT x,y,-z,f,-a' would be acceptable. |
| 48 |
'ACCEPT x,y,-z,*' would add '*!*@*' mask to your accept list. |
| 49 |
|
| 50 |
Like DalNet and UnderNet's 'SILENCE' system, the accept list only exists while |
| 51 |
you are connected to IRC. In order for you to have the same accept list every |
| 52 |
time you come onto IRC, you must put the 'ACCEPT' command into your client's |
| 53 |
auto-perform, or manually issue the command each time. |
| 54 |
|
| 55 |
This system may seem similar to the 'SILENCE'system, but it is actually a |
| 56 |
reverse 'SILENCE'. 'SILENCE' ignores certain users and allows the rest. User mode |
| 57 |
'g' ignores all users except certain ones (on your accept list). Both systems |
| 58 |
have their place, but the user mode 'g' is what the developers thought would be |
| 59 |
most useful for clients. |
| 60 |
|
| 61 |
The goals of this user mode are to provide protection from flooding and |
| 62 |
spamming, and to provide users with a mean to keep their privacy. |
| 63 |
|
| 64 |
We hope that these goals are obtained. |
| 65 |
|
| 66 |
Sample session |
| 67 |
|
| 68 |
The easiest way to see how this works is by experiencing it. Seeing a sample |
| 69 |
session can help you understand what goes on. |
| 70 |
|
| 71 |
Client Hwy-LL is set +g initially. |
| 72 |
Client Hwy101 wants to message Hwy-LL. |
| 73 |
|
| 74 |
Client Hwy101: /msg Hwy-LL hi |
| 75 |
Hwy101 will see: :irc.example.net 716 Hwy101 Hwy-LL :is in +g mode (server side ignore) |
| 76 |
:irc.example.net 717 Hwy101 Hwy-LL :has been informed you messaged them. |
| 77 |
Hwy-LL will see: :irc.example.net 718 Hwy-LL Hwy101 :is messaging you, and you are umode +g. |
| 78 |
|
| 79 |
If Hwy101 sends another message to Hwy-LL (before the minute expires), he will |
| 80 |
see: :irc.example.net 716 Hwy101 Hwy-LL :is in +g mode (server side ignore) |
| 81 |
and will not receive the second numeric. Hwy-LL will NOT see any numeric. |
| 82 |
|
| 83 |
Hwy-LL now wishes to see messages from Hwy101 and SpamBot. |
| 84 |
|
| 85 |
Client Hwy-LL: /accept Hwy101,SpamBot |
| 86 |
|
| 87 |
Neither side will be told of the change in the accept list, Hwy-LL should |
| 88 |
presume that the accept was successful if no error occurs. |
| 89 |
|
| 90 |
Now Hwy-LL can see messages from Hwy101 and SpamBot without any blockage. If |
| 91 |
Hwy101 is also set +g, then he would have to issue /accept Hwy-LL |
| 92 |
before he would be able to see messages from Hwy-LL. |
| 93 |
|
| 94 |
Hwy-LL now wants to see who is on his accept list. |
| 95 |
|
| 96 |
Client Hwy-LL: /accept * |
| 97 |
|
| 98 |
Hwy-LL will see: :irc.example.net 281 Hwy-LL :Hwy101!*@* SpamBot!*@* |
| 99 |
:irc.example.net 282 Hwy-LL :End of /ACCEPT list. |
| 100 |
|
| 101 |
The replies are in numeric form to help parsing by scripts. |
| 102 |
|
| 103 |
Hwy-LL realizes he added a spambot to his list and wants to remove it, and |
| 104 |
allow messages from services. |
| 105 |
|
| 106 |
Client Hwy-LL: /accept -SpamBot,*!*@services.example.net |
| 107 |
|
| 108 |
Hwy-LL will now only accept messages from Hwy101 and services. |
| 109 |
|
| 110 |
W. Campbell |
| 111 |
$Id$ |
