DALnet
Compromise for XFLAG HIDE_MODE_LISTS
XFLAG HIDE_MODE_LISTS
I guess this feature is supposed to prevent evasion, but it gives the user no recourse about who to contact. Maybe a good middle ground would be to show them any bans that affect them, but hide the actual mask and just show them who set it.
Something like:
#help <hidden> set by [email protected] (Wed Jan 01 11:58:56 2020)
If we want to let users contact channel ops about bans, I think we should add a /complain (or /ChanServ COMPLAIN) feature that will let them contact the channel ops.
i.e. "/ChanServ COMPLAIN #channel I got banned and I'm innocent, please help ASAP!"
Kobi.
(I don't object to the proposed compromise, as long as it doesn't show the actual ban, I'm fine with it)
I think he means that +b and mode channel can't be seen by none op's or opers
The scenario to make it harder for flooder's to know which ips are banned.
If we want to let users contact channel ops about bans, I think we should add a /complain (or /ChanServ COMPLAIN) feature that will let them contact the channel ops.
i.e. "/ChanServ COMPLAIN #channel I got banned and I'm innocent, please help ASAP!"
I don't like this because people can be banned from unregistered channels and then we're back where we started. And it also would probably require them to have a registered nick, which many of the people needing help do not have.
Edit: I realized what you're going to say ... XFLAG can't be set on unregistered channels. Still, I feel this belongs in ircd more than in services.
How would this help the user? Just to determine who set the ban?
Yes, we get a lot of traffic in #help and #operhelp from people who are banned and have no idea how to proceed. At least we could guide them through how to find out who banned them, etc. with this.
How would this help the user? Just to determine who set the ban?
I see benefits to users in both approaches.
An abridged ban list would mean that the user needs to take some personal responsibility and contact the op that banned them, (hopefully) involving a grownup conversation. It enables a "Self Help" approach with no services dependancy, but if the op isn't online any more, or they were banned by ChanServ or a channel bot, then the user reaches a dead end. At this point it's "Wait it out, or register a nick and memo the founder", which can take a significant time with some users.
/ChanServ COMPLAIN or similar gets around not being able to contact whoever banned you, but presumably wouldn't work for non-registered nicknames. Perhaps a hostmask could be matched with an active ban to allow it to work with non-registered nicknames, this might be prone to abuse though. If a registered nick is a requirement, then memoing the founder is an option already.
/Arfie
Valid points. The determination that needs to be made is how much of an IRCD problem we want this to be or do we just push it down to services. If this is a DALnet only problem to solve, I'd prefer the latter.
If this is a DALnet only problem to solve, I'd prefer the latter.
Doesn't this issue (or at least challenge around poor visibility/experience for a user) potentially exist for anyone that implements the HIDE_MODE_LISTS functionality on any network? In that case it would make sense to include the mitigating functions in the IRCD.
Yup, that's what I'm thinking as well so any remediation needs to be implemented within Bahamut. This then leaves he /CS COMPLAIN option out. Displaying the bans that apply to the user only would give them a path for resolution.
How about a built-in WHY command... '/why channel', keep access away in /mode if xflag is set. Possibly return -server.dal.net- You are banned from channel, the following bans match you: -server.dal.net- * [email protected], set by xyz -server.dal.net- * [email protected], set by xyz
Perhaps add in another XFLAG... NOWHY to either disallow the why command on channel and/or limit information sent to user via why command. Simple why am I banned from channel? Perhaps also add in notification to those in relay channel of why command being used to let active ops possibly get in touch with the user to help if the person who placed the ban is offline or idle.
For users who might use it to try to flood the ops, place a limit in time for when the why command could be used again.
