1 |
User modes |
2 |
---------- |
3 |
|
4 |
The Atheme core knows the following user modes: |
5 |
|
6 |
+i invisible, only tracked for use by modules |
7 |
+o IRC operator |
8 |
|
9 |
Some protocol modules recognize additional user modes. |
10 |
|
11 |
User modes are stored in user_t.flags together with other state information. |
12 |
|
13 |
Channel modes |
14 |
------------- |
15 |
|
16 |
The following types of channel modes exist: |
17 |
|
18 |
A ban-like (list) |
19 |
B simple, with parameter both when set and unset |
20 |
C simple, with parameter only when set |
21 |
D simple, no parameter |
22 |
E prefix |
23 |
|
24 |
Modes of type E are characterized both by a letter and by a special |
25 |
character to be prefixed to a nick (or UID). |
26 |
|
27 |
The Atheme core knows the following channel modes: |
28 |
|
29 |
A +b channel ban |
30 |
B +k channel key (password) |
31 |
C +l user limit |
32 |
E +o (@) channel operator |
33 |
E +v (+) voice |
34 |
|
35 |
Protocol modules can define more modes of types A (ircd->ban_like_modes), |
36 |
C (ignore_mode_list), D (mode_list) and E (status_mode_list, |
37 |
prefix_mode_list). |
38 |
|
39 |
The mode_list should contain at least +i, +m, +n, +s and +t with the |
40 |
standard values. |
41 |
|
42 |
The Atheme core has special treatment for the following extended channel modes: |
43 |
A ban exception ircd->except_mchar |
44 |
A invite exception ircd->invex_mchar |
45 |
D permanent channel ircd->perm_mode |
46 |
E halfop ircd->uses_halfops, ircd->halfops_mode, ircd->halfops_mchar |
47 |
E channel protection ircd->uses_protect, ircd->protect_mode, ircd->protect_mchar |
48 |
E channel founder ircd->uses_owner, ircd->owner_mode, ircd->owner_mchar |
49 |
|
50 |
Ban exceptions are assumed to allow matching users in through bans but not |
51 |
through invite-only. Invite exceptions are assumed to allow matching users in |
52 |
through invite-only but not through bans. If one "exception" mode does both, |
53 |
put it both in ircd->except_mchar and ircd->invex_mchar (e.g. Nefarious). |
54 |
If multiple modes fulfill the same function but with different matching (e.g. |
55 |
+b and +d bans in hyperion), use a custom next_matching_ban(). |
56 |
|
57 |
The different types of modes are stored as follows: |
58 |
A channel_t.bans |
59 |
B channel_t.key |
60 |
C channel_t.limit, channel_t.extmodes |
61 |
D channel_t.modes |
62 |
E chanuser_t.modes |
63 |
|
64 |
channel_t.key and channel_t.extmodes are smalloc/sstrdup'ed strings and are |
65 |
NULL if the mode is not set. |
66 |
|
67 |
Channel mode locks |
68 |
------------------ |
69 |
|
70 |
Mode locks are stored as follows (only simple modes can be mlocked): |
71 |
B mychan_t.mlock_key |
72 |
C mychan_t.mlock_limit, mychan_t metadata private:mlockext |
73 |
D mychan_t.mlock_on, mychan_t.mlock_off |
74 |
|
75 |
Key/limit mlocked off are stored as CMODE_KEY/CMODE_LIMIT flags in |
76 |
mychan_t.mlock_off. Key/limit mlocked on do not use CMODE_KEY/CMODE_LIMIT |
77 |
flags. |
78 |
|
79 |
Modes of type D can be marked oper-only with ircd->oper_only_modes. This |
80 |
prevents users without chan:cmodes privilege from changing those modes in |
81 |
mode locks. The other modes in the mlock can be changed and the oper-only |
82 |
modes will remain untouched. |
83 |
|
84 |
The format of private:mlockext is a space-separated sequence of |
85 |
<modechar><value>. If the value is empty, that mode is mlocked off. Modes |
86 |
which are not mentioned are not mlocked. The metadata entry is only present |
87 |
if any ignore_mode_list modes are mlocked. |
88 |
|
89 |
Mode lock checks are scheduled in a sophisticated way to avoid annoying |
90 |
redundant mode changes showing up while still keeping the modes correct, in |
91 |
all supported ircds: |
92 |
- on creation of a channel and on TS changes (these often clear all simple |
93 |
modes), mark the channel registration MC_MLOCK_CHECK |
94 |
- on an incoming mode change, if the channel registration is marked |
95 |
MC_MLOCK_CHECK or the mode change altered simple modes, check the mode |
96 |
locks; prefixed nicks on SJOIN/FJOIN/NJOIN do not count as mode changes, |
97 |
but simple modes on SJOIN do |
98 |
- on creation of a channel, if it is possible that no mode changes (according |
99 |
to the previous item) are sent for this channel, check mode locks right away |
100 |
(this is done by faking an incoming mode change "+") |
101 |
- when a channel is registered or the mode locks are changed, check the |
102 |
mode locks right away |
103 |
- when kicking a user because of mlock +i and the channel is not +i yet, check |
104 |
the mode locks right away |
105 |
- on any mode lock check, clear MC_MLOCK_CHECK if it is set |