Opened 10 years ago

Last modified 8 years ago

#9490 new defect

+a IRC Not reconized.

Reported by: dbdii407 Owned by: elb
Milestone: Component: IRC
Version: 2.5.7 Keywords:
Cc:

Description (last modified by dbdii407)

I find it creepy that pidgin recognizes everything BUT +a. I created an icon for it (just change the owner (+q) flag color to red) and used it on xChat and it looks nice. Is there a patch to make Pidgin recognize +a or is there plans to add it in on a later release? thanks

Change History (8)

comment:1 Changed 10 years ago by darkrain42

  • Component changed from unclassified to IRC
  • Owner changed from rekkanoryo to elb

comment:2 follow-up: Changed 10 years ago by elb

  • Status changed from new to pending

+a is a nonstandard mode. We cannot support it without knowing what it is, and then support will depend on how reasonable it is.

Let us know what +a is, whether it takes an argument (and what that argument is), and what ircd supports it, and we can make a decision.

comment:3 in reply to: ↑ 2 Changed 10 years ago by dbdii407

  • Description modified (diff)
  • Status changed from pending to new

Replying to elb:

+a is a nonstandard mode. We cannot support it without knowing what it is, and then support will depend on how reasonable it is.

Let us know what +a is, whether it takes an argument (and what that argument is), and what ircd supports it, and we can make a decision.

comment:4 Changed 10 years ago by dbdii407

  • Description modified (diff)

"+a is a nonstandard mode." HAHA! Haven't heard that one. +a is in InspIRCd and UnrealIRCd (popular) and some other ones i'm sure.

+a (Protected/Admin?) lies between +q and +o Can only be kicked by +q (or other +a's depending on the server's config) Of course it takes an argument. /mode #channel +a <user(s)>

It lives in Atheme and Anope also. Anope: SOP Atheme: +a flag

comment:5 follow-up: Changed 10 years ago by elb

If you haven't heard it, then you simply haven't spent much time around IRC. The standards (such as they are), are RFC 1459 and RFCs 2810 through 2813. RFC 2811 describes +a as a channel mode, but it has a completely different behavior from what you are describing, and does not take an argument. That said, most IRC daemons are wildly nonstandard, and these documents fail to describe many behaviors which are even somewhat common. It is rather egregious to coopt a mode letter which is actually described in the standard, though.

It is also interesting to note that these particular daemons use +q for a purpose contrary to several other popular IRC daemons.

The fact that you claim that this mode "lives" in other servers, but give a different behavior for it, leads me to believe that perhaps you are looking for a different level of "support" for +a than Pidgin is likely to provide. You should still be able to set and lift +a with /mode, users having +a set simply will not be marked in the channel list.

What marker character is given in the NAMES list to users having +a set?

comment:6 in reply to: ↑ 5 Changed 10 years ago by dbdii407

The default charater for this channel status (+a) is &. It works just like any other channel status +qohv

comment:7 Changed 10 years ago by ins3

I also find it annoying when Pidgin fails to recognise +a user modes. At the very least &-nicks should be displayed as channel operators.

comment:8 Changed 8 years ago by N00D135

I felt I must contribute to this thread, so here goes.

I run an IRC network myself, which has the full modeset PREFIX=(qaohv)~&@%+ this is sent on connect to any irc client connecting, so thusly Pigdin can read this information and then set the correct modes on usernames, if the PREFIX=(qaohv)~&@%+ line is _always_ read in and interpreted, any new irc modes which pop up (such as !y as inspircd has with the operprefix module) this simply means your IRC Client can deal with and cope with any modesets sent.

The server support section is sent via Numeric 005, thusly: 20:13:45 -> {irc_server_name} {005} { [usernickname] [MODES=12] [CHANTYPES=#] [PREFIX=(qaohv)~&@%+] [CHANMODES=beI,kfL,lj,psmntirRcOAQKVCuzNSMTG] CASEMAPPING=ascii] [EXTBAN=~,cqnr] [ELIST=MNUCT] [are supported by this server] }

Provided you write your client to read in numeric 005 and then parse the details specified after PREFIX= into any usermodes as above, youre IRC client will then support any usermodes the server sends out, plus they are always sent in Highest>Lowest order, ~ being highest operator, in this case.

For instance if you download mschat, that only supports @%+ out of the box, so ~& users appear below the rest, and you cannot use menus on the names, as it gives a ~user: not found message, because they wrote thier client based entirely from the RFC's which only actually state @+ as specific channel usermodes, ~&% modes were added more recently, but when the RFC's were written only @+ existed.

Please feel free to contact me if you need further explanation, I'd be happy to help you, But if you do read in the 005 numerics and act upon the PREFIX= part, Your IRC Client will then be 100% compatible with any IRC server in existance, of course if you do not get a 005 reply (I've not seen many which do not send this info across) but for those which do not send the information to pigdin, I'd assume PREFIX=(qaohv)~&@%+ in all cases and then you know you are protected against non-existant modes.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!