| 1 |
pippijn |
1.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 |
