freenode channel successor logic

gistfile1.md

Channel successor logic on freenode

(This covers what Atheme services as used on freenode will do if all founder (+F) accounts of a channel are dropped. It does not go into any staff policies on related matters. In particular, single-# channels have policies that services cannot reasonably implement¹ as they commonly involve talking to actual people.)

For single-# channels, the freenode-staff role account is always chosen as successor; normal channel successor logic does not apply in this case.

Otherwise, the "best" user will be selected from the channel's ACL according to the following criteria:

• They may not have the +b flag. This ensures AKICKed users will never inherit a channel.
• They need to be able to accomodate the channel registration; users who already have 30 channels registered cannot inherit a channel unless they have been granted the RegNoLimit flag.²
• They need to have at least a certain amount of access:
  • +S is primarily considered for this.
  • +R is required if no eligible users have the +S flag.
  • +f is required if no eligible users have the +S or +R flags.
  • +o is required if no eligible users have the +S, +R or +f flags.
  • If no eligible users have any of the above flags, no minimum level of access is required.
• The ACL is checked from the top to the bottom. If a second user with the required access is found, their channel access must be a strict superset of whoever was found first for them to be chosen as successor instead (+v and +o are considered to be the same as +vV and +oO for this purpose). If their level of access is exactly the same, the first user found is chosen unless the first user has not logged in for the last seven days while the second user has, in which case the second user is chosen.

These rules may seem complicated, but should follow most users' expectations.

Footnotes

1. True fact: Last time someone tried to implement strong AI for Atheme, Sigyn got jealous and tried to K-line OperServ.[citation needed] So I guess that's not happening.
2. The same goes for staff with the user:regnolimit privilege. Privileges are not directly exposed to non-staff users, however.