New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix mapping status modes owner/admin/etc to op in TS6 #7

cooper opened this Issue Jun 23, 2016 · 4 comments


None yet
2 participants

cooper commented Jun 23, 2016

I need to consider how I want to handle +qah/etc. forwarding to TS6 servers like charybdis which do not support these statuses.

We cannot assume that anyone with +q or +a or any mode higher than +o has +o in addition to whichever other statuses they have. Therefore it seems essential that a mode change of +q actually translates to +o. It must also be handled properly such that +qo does not translate to +oo and so on.

The question is whether it makes sense to do the opposite, i.e. to translate -o to -q—making ops on charybdis as powerful as owners on juno—or to instead immediately reverse the mode deop if done remotely by someone with a lower status. A third option would be to ignore +q and friends entirely on charybdis, which is the current behavior. The problem with doing that is that some channel actions require ops at a local level and may be ignored by charybdis.

I could also consider making it configure how you want this to behave:

  1. Translate -o to -q
  2. Reverse remote deops from servers without higher statuses
  3. Ignore the existence of these modes altogether

Of course, all of this can be avoided by disabling juno's extra status modes.

@cooper cooper self-assigned this Jun 23, 2016


This comment has been minimized.


cooper commented Jun 23, 2016

Also, this currently happens:

[ircd::server] convert_cmode_string(): converted +qo 0c 0c ( to +o 000AAAAAC 000AAAAAC (

The +q is weeded out but the parameter remains. This is bad.

@cooper cooper added bug ts6 labels Jun 23, 2016


This comment has been minimized.

jlu5 commented Jun 23, 2016

The most common way to deal with this is to just ignore the +qah entirely if the target doesn't support it. The reason why services set +qo and +ao instead of plain +q/+a is probably for compatibility for clients/bots that don't care about extended op statuses.


This comment has been minimized.


cooper commented Jun 23, 2016

I was worried that some commands are ignored if you're not op, even remotely. Maybe I'm thinking wrong.

cooper added a commit that referenced this issue Jun 25, 2016

fixed several issues with translation to servers lacking certain mode…
…s, particularly with channel status. the new behavior is to remove and forward without the unknown modes and their parameters, if any. #7

This comment has been minimized.


cooper commented Jun 25, 2016

decided to do what @GLolol said and remove unknown modes and their parameters, forwarding on without them

@cooper cooper closed this Jun 25, 2016

@cooper cooper modified the milestone: v11 Jun 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment