Discussion: Arbitrary mode support

[thommey]

This is an issue to keep track of design decisions/open question/postponed tasks for arbitrary mode support in Eggdrop. The parsing was done in #1872 and now allows us to write actual supporting code.

Goals

• pushmode/add_mode() should be able to send all valid modes with an optional argument
• all modes are tracked internally properly according to 005 isupport info (e.g. PREFIX=(qaohv)~&@%+ CHANMODE=eIbq,k,flj,ACFHLMOPQTcgimnprstz).
• The mode types are:
  • list-type modes (ebIq, ban-type masks as parameter)
  • key-type modes (k, parameter on set/unset)
  • limit-type modes (flj, parameter on set only)
  • flag-type modes (imnprst.., no parameter)
  • prefix-type modes (qaohv, set on nicknames with a corresponding non-alphanumeric prefix char)
• module API stays compatible through accessor functions that set legacy struct fields (e.g. set_mode(chan, 'l', "12") also sets chan->maxmembers=12)
• bind mode triggers for all valid mode changes
• new generic list-mode tracking, +beI could be folded into it later, but that's not a goal of this step
• channel mode and prefix mode tracking is however going to be unified

Implementation details

• chan_t.modeflags is a new uint64_t bitfield to track a-zA-Z0-9 (62 bits), compressing it would be of little benefit
• chan_t.modeargs is a new char *[62] storing the argument for a-zA-Z0-9 if needed (wastes space for non-flag modes)
• chan_t.modelists is a new struct field to track new list modes (q)
• opchars is removed from the code with a deprecation warning if it is being set in the config, it never worked right to begin with
• the outgoing mode queue in chanset_t.cmode is changed to instead have a list of modes and their arguments that should be set (from pushmode/add_mode), flushes when full or after timeout or after flushmode
• the old outgoing mode queue is removed, I cannot imagine anything relying on it in the module API
• drive-by fix for supporting more than 6 modes per line (we never actually supported that, oops)
• prefix modes get a modechar 'o', a prefixchar '@' and a rank (1..8) so we can see that admin is higher than op, but I have no idea what to do with that information yet

Design decisions

• existing prefix functionality remains focused on op/halfop/voice (bitch, stopnethack, flood-deop, protectops, ...)
• there is no new chattr flag to automatically assign new prefixes (+a autoop sticks with +o only)
• botisop, isop, etc. only check the actual 'o' flag, not "o or higher"
• there is logic to see who can set which modes, but I have no clue if this is correct (the rule is roughly: highest prefix can unset/set highest prefix and all lower ones - every other one can only set/unset lower ones except for 'o' which can set/unset 'o')
• WHO/WHOX is kept as authoritative prefix source, not names
• we try to negotiate the multi-prefix CAP automatically unless disabled so WHO shows all prefixes
• only up to 8 prefixes are supported (can be changed to 16 or 32 easily, the limit is the rank)
• the chanmode channel setting accepts arbitrary strings and is parsed as-needed when 005 isupport is known
• getchanmode returns modes in arbitrary order (might be backwards incompatible if that was relied upon)
• the last known isupport string is fully saved to the userfile and loaded before connecting to the ircd so we have a reasonable default (from the last connection)

Tcl commands

• chanmodeinfo <letter>
• isprefix/wasprefix alongside isop/wasop/isvoice/wasvoice
• isprefixatleast for rank-based prefix check e.g. isprefixatleast o is true for admins
• chanmodelist to access generic list modes (q)

[thommey]

Open questions:

• What do we do with the information that ~q > &a > @o?
• Who can set which modes on a channel?
• Do we need chattr flags to auto-assign prefixes to users other than @o/%h/+v?

[thommey]

Todo: Expose mode parsing for Tcl (so the initial MODE after JOIN can be split if needed)

[vanosg]

I'll start with the Tcl commands. In my head, we're matching symbol characters against mode characters (@ is o, + is v, etc). We're also going to want to store every mode character the user has (so a ~q user will have 'qaohv' all assigned to them in the meberlist, not just q).

So the commands I would be interested in (find better names for them, I don't know what to call them:
getuserflags $nick returns {q a o h v} for a user with the q flag
findseniormode $nick1 $nick2 returns the user that has a higher flag assignment than another
hasuserflag $nick q returns a 1 or a 0 if the user has the flag

I think we want to keep the voice/halfop/op construct hardcoded in as 'this is what we support', but leave the other flags out of Tcl commands (ie, no 'isadmin') because those flags tend to be more dynamic.

And we hold the arb mode flags in a registry/bitmask, where mask[0] is +, mask[4] is a, mask[5] is q (or whatever the modes presented by the server are, and we just check where that flag is and what its higher/lower than.

[thommey]

I would add the following Tcl commands (naming discussion out of scope):

chanmodeinfo letter
returns the type of mode the given letter is on this network (after connection and raw 005 isupport only). The valid types are: "list", "key", "limit", "flag", "prefix"
example: [chanmodeinfo o] == "prefix"; [chanmodeinfo n] == "flag"; [chanmodeinfo l] == "limit"
returns "" for unknown modes

isprefix prefix nick channel
equivalent to isop/isvoice. returns 1 if the given nickname on the channel possesses the prefix or 0 otherwise. mode chars are valid as well as prefix chars.
example: [isprefix @ Geo #eggdrop] == 1; [isprefix o thommey #eggheads] == 1
throws an error on invalid channel or when nickname is not present on the channel

wasprefix prefix nick channel
equivalent to wasop/wasvoice. see isprefix, necessary in bind mode calls after the mode is already processed, example:

bind mode - "% -o" test
proc test {nick host hand chan mc victim} {
  if {[wasprefix @ $victim $chan]} {
    putlog "actually deopped"
  } else {
    putlog "pointless mode change sent by server"
  }
}

isprefixatleast prefix nick channel
returns 1 if nickname is on the channel and has the given prefix (letter or prefix char, see isprefix), or a higher one
example: PREFIX=(qaohv)~&@%+ and user has q (owner): [isprefixatleast @ thommey #eggdrop] == 1

chanmodelist modechar channel
equivalent to chanbans. returns the list of mask-type modes set in the given list mode
example: [chanmodelist q #chan] == {*!*@*.aol.com thommey!thommey@aol.com 27}

I don't understand the point of "findseniormode $nick1 $nick2".
Good point about "getuserflags", I need that as well (not sure whether to return {o v h} or {@ % +} or maybe {ovh @%+}).

My most pressing open question is: What do we do internally with the information that ~q > &a > @o?

[vanosg]

I don't understand the point of "findseniormode $nick1 $nick2".

If I want to know who has more rank in a channel, I can compare two nicks and it will tell me which one is higher- perhaps useful for scripts to check if an op is allowed to kick an admin, etc

My most pressing open question is: What do we do internally with the information that ~q > &a > @o?

This is what I poorly tried to describe as a bitmask... as I write this out fully, maybe an array is better suited, but you be the implementation judge. So, writing it out, you have a prefix_info struct that holds information about a prefix char. the struct maps ~ to q, and assigns it a rank of 0; it & to a with a rank of 1, etc.

typedef struct {
    char mode;
    char prefix;
    int rank;
} prefix_info_t;

and then

struct prefix_info_t prefixes[32];

to make an array of structs (its small enough I don't think a linked list is needed, and also I hate linked lists because I am dumb and always mem leak them)

When you get 005, you load each mode/prefix pair into the struct array with the appropriate rank (load q/~/0 for the first entry, a/&/1 for the second, etc to tell you q is more than a. And then write two helper functions foo_find_by_prefix(~) and foo_find_by_mode(q) that iterate the array to find the matching struct.

This keeps the more ambiguous/nonstandard modes that are above o/@ dynamic and current because we read them from 005, and don't have some preconfigured per-server setting we need to maintain as developers. Because we're not adding in eggdrop modes to match those above-op modes (right? RIGHT?) everything stays out of the userfile and scripts work cross-server even if modes are different.

[vanosg]

Following the spirited discussion in channel and the issues of understanding what modes can to what to other modes, I'd like to suggest we break this down into chunks. Sprints, if you will :)

Step 1, populate out a data structure that captures and tracks 005 mode declarations. Looking at #1872 I think some of this is done, but I didn't see the ranking added (slot 1 > slot 2 > slot 3 .....). So maybe make sure we have a data structure that holds everything we need.

Step 2, build out Tcl commands that expose that information to scripts- more to help us think through the possible use cases and what data is of interest to make available, rather than being a necessary next technical step

Step 3, begin to parse multi-prefix from NAMES, WHO, and WHOIS.

Step 4, figure out how Eggdrop handles enforcement with all these levels. This is the fun part.

But the main point is lets gets some easy quick wins on the user mode stuff first. I think #1872 covered a lot of the other stuff, we just need to expose it for those that want to use it. Get the quick wins, commit to develop, and then use that to continue building out the harder parts, rather than trying to do it all in a single PR