ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/ermyth/doc/MODES
Revision: 1.2
Committed: Thu Jul 19 12:35:04 2007 UTC (16 years, 10 months ago) by pippijn
Branch: MAIN
CVS Tags: HEAD
Changes since 1.1: +0 -0 lines
State: FILE REMOVED
Log Message:
convert documentation to POD and use this for the website

File Contents

# Content
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