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