View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001853 | unreal | ircd | public | 2004-06-01 21:34 | 2004-06-11 21:23 |
| Reporter | aquanight | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Platform | X86 | OS | Windows | OS Version | XP Professional |
| Summary | 0001853: Some modes block user talking, but not nick changing? | ||||
| Description | I've noticed that some channel channel mode (like +m) will prevent users from talking but not from using /nick... -Under +m, users without voice can still change nicks. -Under +b ~q, affected users can still change nicks. A good example if this actually occured once in #unreal-support (this is the relavent part from log): [10:48:49] * RoTTen is now known as how-can-i-take-quiz [10:49:31] * how-can-i-take-quiz is now known as RoTten [10:50:03] <+aquanight> I definately think we need +m == +N for non-+v users [10:50:32] <+Noia[away]> lol -- Snip a temporary connection failure -- [10:55:28] <@eggy> aquanight: I agree [10:55:39] <@eggy> its anoying when they nick surf when the cannot talk +b ~q has this behavior as well. I've noticed that in DALnet, basically any time a user cannot talk (on any channel), they cannot change nicks. Currently (AFAIK) Unreal only has this for full bans and +N. What do you think? | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0003302 | resolved | Suggestion: If someone can't talk, they can't nickchange either |
|
|
Hmmm makes sense, saw this a while back, but.. is there a real benefit for it as compared to the difficulty of implementing it? (Mind you, shouldnt be too hard.) |
|
|
Well, I guess I just don't see the point. Consider: I'm in #celebchat, where a very famous celebrity is visiting. However, they don't want people flooding, and there will be children in the channel, so they don't want you to talk in the channel, so the channel is +m and users are -v. Instead, you /msg questionbot My Question is blah blah blah? Then, the question is added to a queue. Now, since this is a big celebrity, hundreds of questions were asked, and I've been waiting several hours for my question to be answered. Somewhere in the 3 hours I've been waiting so far, I decide to change my nickname. But, I'm -v in a +m channel. So now I get "you cannot change your nickname while -v in a +m channel." Now I have two options: 1.) Leave #celebchat, change my nick, and rejoin 2.) Just keep my current nick There is a problem with #1 though. When you leave the channel, your question is removed from the queue! So if I leave, I have to wait *at least* another 3 hours just to get back to where I already was! So that means, I can't change my nickname until my question is answered. And that could be another 5 hours! So basically, because +m -v blocks nick changes, I'm unable to change my nickname. I really don't see the benefit. It seems to cause more harm than good to me... |
|
|
Well, yeah, that one instance can be a major headache, but then why not code the bot to *not* remove questions from the queue (aside from the fact of assuming that asker might not be back to hear the answer, but in that case someone who's there can PM it when s/he does come back). So yeah, but what about the +b ~q thing though? If at least that is changed, one could use that as an alternate form of moderating (i.e. set +b ~q:*!*@*). (Through syzop's RegExcept module (?) or setting services AutoVoice privilege to 0 (Epona/Anope/IRCServices), you could emulate +M as well through ~q.) |
|
|
I disagree with this too: +m shouldn't prevent someone from changing nicks. permanent +m(u) channels with lots of normal users on it is pretty common and would be VERY very annoying with that cannot-nickchange-behavior. If we would change that we'll have many angry people, including me :P. +b ~q... I dunnow... depends on how you actually use it :P. Prolly worth to gather opinions on (I'll ask around a bit, and perhaps add a poll). |
|
|
Well, in terms of numeric replies, it treats +b ~q as plain +b... but yeah. +mu is most certainly a special case, but in this case, it is not technically true that the non-voice users cannot speak (just that such messages are only visible to certain users, and the sender gets a "cannot speak" reply back) (unless an op does the +b IRC!*@* thing), and so therefore would be allowed to change nicks in this situation. So how about having it just for +m-u? Of course, having it for +M is nothing but a headache. I speak from experience on that ;) (had times on dalnet were I got 10053'd and reconn'd with my (unregistered) alternate nick, and after either the ghost died or I nickserv GHOST'd it, I found I couldn't go back to my normal nick because one of my regular channels with +M! 'course that'd be a good time to get around to linking the nicks. ;) ) So yeah, I can see how it might be a headache, but you also have +N. That can be a headache sometimes too ;) . I guess the point of this is to prevent users from circumventing these silence situations (like in the example I quoted) or from evading weak +b ~q bans (without needing to rejoin). And for the "depends on how you use it" part, one net I'm on has a channel that ~q's AOLers (but they also +e specific ppl on request). Course that probably wouldn't be good example for blocking the nicksurf-while-can't-talk thing. *edit: kill -term `pidof typod`* edited on: 2004-06-02 00:11 |
|
|
As said, the "deny speaking if +m (and yes +M ;p)"-stuff is not going to happen [you even touch some of the points yourself ;p] +N is very explicit and ment for anti-flood purposes (which is why voiced users are not 'exempted'). Anyway, thanks for your feedback on +b ~q usage :P. That's probably how I would use it (like 'light bans'). Just mailed another admin which has quite some users using it too, so I wonder what kind of usage (in what situations) he sees most. *edit* annoying typo too */edit* edited on: 2004-06-02 00:30 |
|
|
So yeah, someone who wanted this behavior with +mM would probably just put +N (and maybe give voiced users a method to temporarily unset it, or said voiced users would be autovoice, and can just part-nick-join) as well... so no go for +mM, okay ;) . Doing it with +b ~q would be harder, though. A full ban would accomplish it, but it will probably have a side-effect (ie users can't join) the ops don't want. |
|
|
For the record... another nicksurf-bypass-moderate-thingy incident occured on the support channel. I think Syzop was actually there to see it :) : [10:29:52] * Jason ([email protected]) has joined #unreal-support [10:30:10] * Jason is now known as Jason-VOICE_NO-DARN-BOT [10:30:42] * Jason-VOICE_NO-DARN-BOT is now known as Jason-VOICE_NO-DARN-BOT_did-pa [10:30:49] * Jason-VOICE_NO-DARN-BOT_did-pa is now known as Jason-VOICE_did-pass-test [10:32:45] * Jason-VOICE_did-pass-test is now known as Jason Yeah... UnrealHelper was out to lunch ( :D ) at the time, but it's kind of annoying when people bypass ban/moderate with a nicksurf like that. Maybe I'll look into seeing if this is possible with a module... |
|
|
*offtopic* For #unreal-support itself I thought of just making the bot ban on certain stupid nickchanges [nickchanges to *voice* or something similar] ;). {yeah the bot was down, but.. in such a case nicksurfing isn't that bad/understandable} */offtopic* However in lots of other cases you do not want that behavior, so... Another idea also crossed my mind: let ~q also block nickchanges if the channel is +m (since ~q with +m is useless anyway), however.. that might lead to some confusion of what ~q actually does... |
|
|
Yeah, I was thinking just make another extended ban type, ~n. * aquanight sets mode: +b ~n:*!*@*.aol.com Matching users cannot change nicks unless +o or higher. * aquanight sets mode: +e ~n:*!ExceptMe@* Matching users can change nicks, regardless of bans, +N, etc. A straight +e will only override +b ~n. An explicit +e against ~n will except from anything that would block nickchange. With it that way, though then the problem with +m that codemastr mentioned wouldn't be a problem. A chanop could set +e ~n:codemastr!*@*. If modules.unrealircd.org comes back up, I'll look into it :) . Of course, this would require a command override for NICK, but oh well. Unless of course this were to be built-in to the commands.so... *edit* I don't know what an appropriate numeric would be though... */edit* edited on: 2004-06-07 13:44 |
|
|
Yeah perhaps.. (and no, I'm not thinking of modules here :P) However, I thought you were talking about preventing 'nicksurfing'... the whole thing you now present is not useful against that (like for #unreal-support) because such bans except both voiced and normal users. I guess one could say it would be somewhat useful against flooding botnets or perhaps some other things, then again.. such users shouldn't get voice anyway.. so.. why not obey the general rule that bans only affect normal non-voiced users? In that case you could also do +b ~n:*!*@* to make non-voiced users unable to nickchange, etc.. [Plus, our current system doesn't check any bans for voice and higher anyway.. would require recoding and even some redesign to allow that.. I once thought of ~Q [~q applying to +v'd users] but.. I'm not that bored.] |
|
|
Well, the +b part was supposed to be like +N, but against specific hostmasks instead of just global. But allowing +v to walk it sounds better :) since it technically is a ban. Now that I think about it, I'm a little unsure about the +e ~n part, hm... but it could be useful for cases like the channel is +N but an op wants to allow one person (and just one person) to nickchange... or for the situation codemastr described. |
|
|
I dunno.. I think it's best to make +e ~n be the reverse of +b ~n, and thus not having anything to do with +N. Else it's a bit like making +e nick!user@host going trough +i/+l/.. or something ;). |
|
|
I think this is a pretty good idea.. it's not only useful for things like #unreal-support (+b ~n:*!*@*), but I've also seen cases where someones script went nuts and kept changing nicknames (because it didn't recognize the 'your nickname is registered blabla' from nickserv when services came back)... instead of doing a full ban one could just do such a ~n ban [which is nice in case it's one of your friends that is away ;p]. |
|
|
>0006613 "I dunno.. I think it's best to make ..." Heh... didn't think about it that way... but then what would be the point? Unless we don't make normal +e able to walk it. edited on: 2004-06-07 14:31 |
|
|
I don't understand your question :P. |
|
|
I was saying what would be the purpose of having +e ~n, then, if +e normal would override it like always. But after i had already posted it, it hit me. *DUH!* +e ~n would override only +b ~n, like it should, and +e normal would override everything like always. |
|
|
Exactly ;). +e ~c makes someone able to join/nickchange/talk, regardless of other matching bans +e ~q makes someone able to speak, regardless of other matching bans so.. +e ~n makes someone able to nickchange, regardless of other matching bans and yeah.. +e n!u@h makes someone able to join/nickchange/talk regardless of other matching bans. *edit*blahhhhhh.. enough about this ;p*/edit* edited on: 2004-06-07 14:49 |
|
|
Added +b ~n in CVS (.54). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-06-01 21:34 | aquanight | New Issue | |
| 2004-06-01 22:03 | w00t | Note Added: 0006531 | |
| 2004-06-01 22:42 |
|
Note Added: 0006533 | |
| 2004-06-01 22:51 | aquanight | Note Added: 0006536 | |
| 2004-06-01 23:39 | syzop | Note Added: 0006538 | |
| 2004-06-02 00:09 | aquanight | Note Added: 0006539 | |
| 2004-06-02 00:11 | aquanight | Note Edited: 0006539 | |
| 2004-06-02 00:17 | syzop | Note Added: 0006541 | |
| 2004-06-02 00:30 | syzop | Note Edited: 0006541 | |
| 2004-06-02 00:32 | aquanight | Note Added: 0006542 | |
| 2004-06-07 12:37 | aquanight | Note Added: 0006608 | |
| 2004-06-07 12:51 | syzop | Note Added: 0006609 | |
| 2004-06-07 13:40 | aquanight | Note Added: 0006610 | |
| 2004-06-07 13:44 | aquanight | Note Edited: 0006610 | |
| 2004-06-07 13:54 | syzop | Note Added: 0006611 | |
| 2004-06-07 14:02 | aquanight | Note Added: 0006612 | |
| 2004-06-07 14:23 | syzop | Note Added: 0006613 | |
| 2004-06-07 14:29 | syzop | Note Added: 0006614 | |
| 2004-06-07 14:31 | aquanight | Note Added: 0006615 | |
| 2004-06-07 14:31 | aquanight | Note Edited: 0006615 | |
| 2004-06-07 14:40 | syzop | Note Added: 0006616 | |
| 2004-06-07 14:43 | aquanight | Note Added: 0006617 | |
| 2004-06-07 14:48 | syzop | Note Added: 0006618 | |
| 2004-06-07 14:49 | syzop | Note Edited: 0006618 | |
| 2004-06-11 21:23 | syzop | Status | new => closed |
| 2004-06-11 21:23 | syzop | Note Added: 0006632 | |
| 2007-04-27 03:16 |
|
Relationship added | has duplicate 0003302 |
