View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003322 | unreal | ircd | public | 2007-05-07 22:24 | 2015-07-13 22:36 |
| Reporter | Shining Phoenix | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Platform | i386 | OS | Linux | OS Version | 2.6.10-1.771_FC2 |
| Product Version | 3.2.6 | ||||
| Summary | 0003322: Suggestions for channel mode f | ||||
| Description | 1. Split it in two. Channel mode f would count actions for individual users, F would count actions for the whole channel. e.g. +f [6m,5t]:4 would become +fF [5t]:4 [6m]:4 2. More actions. e.g. +f [3n#n]:30 would set a ~n ban on someone when they nickchange too much e.g. +F [3n#n]:30 would set a ~n:*!*@* ban when there is too much nickchanging j, n and q actions would be ~j, ~n and ~q bans respectively. Only a normal ban (b) would have an accompanying kick. 3. An i trigger for invite flooding. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Two Mode Binary Modes Option: Trigger || f actions || F actions || extra notes m || - || m,M t || kick,b,q || - c || C,m,M,b,q || C,m,M j || i,R,b,j || i,R,j || f's j ~j bans one person, F's j sets +b ~j:*!*@* k || K || K n || N,n || N,n || f's n bans one person, F's n sets +b ~n:*!*@* i || i,V || i,V EDIT: How do I make this table more table-like? |
|
|
just do printscreen on notepad :P |
|
|
1. nah.. I indeed understand your confusion, but.. we should keep it as-is instead of doing major rework, otherwise people never get used to it (I'd hate it myself too). It also has various other effects in the code when separated. So.. no. 2. I guess. We could add this to another request which asks for a ~q ban on textflood (was some other bugid...), IIRC the suggestion was to use #bq btw, and not just #q or #n. Details... 3. hm, I see... :) |
|
|
I'd actually think 3) is an interesting thing to have. Especially as non-chanopped users can silently invite others (maybe I should file a seperate bug on that so we can get it changed?). As for seperating global from per-user. No. We don't need more complicated stuff with floodprot et al. As it is, we only have t as per user anyway. Maybe if we had more per-user stuff to the point that +f syntax started looking like weirdly valid perl... then maybe. |
|
|
Aquanight: Maybe if we had more per-user stuff to the point that +f syntax started looking like weirdly valid perl... then maybe. Me: Huh? One Binary Mode Option: Trigger -|| Actions c (user) || C,m,M,b,bq C (chan) || C,m,M i (user) || i,V I (chan) || i,V j (chan) || i,R,b,bj J (user) || i,R,bj k (chan) || K K (user) || K m (chan) || m,M n (chan) || N,bn N (user) || N,bn t (user) || kick,b,bq Related reports: 2108 and 2380...I can't remember if 2380 is the something I forgot or not =\ |
|
|
[quote]I'd actually think 3) is an interesting thing to have. Especially as non-chanopped users can silently invite others (maybe I should file a seperate bug on that so we can get it changed?).[/quote] changed? why? it's normal... but yeah, offtopic for here :P |
|
|
I don't like a supercomplexlongbabyeating parameter, coders don't want to split f into multiple modes and everyone wants more features. Hence, I have an idea. * People run away One List Mode Option: e.g. /mode channel +fff 4t#b:5 3j#R:5 5j:5 <--Two join flood controls ;) e.g. /mode channel +f <--returns a list of flood controls Side components of this: /mode channel -f ?n* <-- remove all nickchange flood controls /mode channel -f * <-- remove all flood controls /mode channel +f *:5 <-- set the bit after the colon for all of them to 5 /mode channel +f *j*:5 <-- set the bit after the colon for all join flood controls to 5 A Two List Mode Option would be analagous to the Two Binary Mode Option. |
|
|
Y'know, validating chmode +f isn't _that_ hard. If anybody wants an example, there is a validate_chmodef in SrSv::Unreal::Validate in SurrealServices. As far as I can tell, it fits the exact same rules as what the IRCd does (via reverse-engineering and empirical testing). Is the question making it easier for coders, or for users? Hell, we could just look at a simpler construction method. Consider a webpage that decodes and constructs new chmode f parameters. Also, splitting it into multiple pieces leaves the possibilities of conflicts, and reordering during resyncs. |
|
|
Also, what's the point of ~n:*!*@* when we already have +N ? |
|
|
Question: What do you mean by validate? Note: ~n:* stops users with no status, N stops users with halfop or lower. 4. A related suggestion: A badwords trigger. When there are more than x badwords in y seconds, from a (user or whole channel?), do something. e.g: +f [15g#G60]:60 Ok, ignore point 1 in the original suggestion and the "Two Mode Binary Modes", "One List Mode" and "Two List Modes Options" in notes. 5. The suggestion that was in this line is now redundant. |
|
|
6. ACTION trigger As far as I know the implementation of an ACTION trigger would probably be a lot like the CTCP trigger, so it shouldn't be hard to do. This is specifically to deal with slap floods, because that is what a flood of ACTION would be. If someone starts clicking slap over and over, or their script goes off, I would like it if the server kicks, or bans and kicks, them. |
|
|
I don't think +b ~n is a good idea. If 50 drones are nick-change flooding you don't want 50 bans, you want a single +N. And I don't want to add a two-step process / two-limits either. Also, we have set::anti-flood::nick-flood for individual control anyway. +b ~q could be done in case of 't' (but not 'm'.. for same reason as +N above), that would be more friendly way of limiting a user.. rather than kickbanning them. Invite flood. Don't think I've really seen that before. Hmm. Unless you mean one user mass-/inviting people to him/her own channel, but we can add some other method to counter that (actually it may already be handled by MAXTARGETS throttling). Action I don't see any reason to implement. All the rest.. let's keep it as-is. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-05-07 22:24 | Shining Phoenix | New Issue | |
| 2007-05-07 22:24 | Shining Phoenix | Note Added: 0014031 | |
| 2007-05-07 22:25 | Shining Phoenix | Note Edited: 0014031 | |
| 2007-05-07 22:25 | Shining Phoenix | Note Edited: 0014031 | |
| 2007-05-07 22:27 | Shining Phoenix | Note Edited: 0014031 | |
| 2007-05-08 01:03 | Bock | Note Added: 0014036 | |
| 2007-05-08 03:38 |
|
Status | new => feedback |
| 2007-05-08 04:06 | syzop | Note Added: 0014044 | |
| 2007-05-08 22:16 | aquanight | Note Added: 0014056 | |
| 2007-05-09 03:32 | Shining Phoenix | Note Added: 0014058 | |
| 2007-05-09 03:38 | Shining Phoenix | Note Edited: 0014058 | |
| 2007-05-09 04:00 | Shining Phoenix | Note Edited: 0014058 | |
| 2007-05-09 04:19 | Shining Phoenix | Note Edited: 0014058 | |
| 2007-05-09 07:28 | syzop | Relationship added | related to 0002108 |
| 2007-05-09 15:27 | Shining Phoenix | Note Edited: 0014058 | |
| 2007-05-09 15:54 | syzop | Note Added: 0014063 | |
| 2007-05-10 22:06 | Shining Phoenix | Note Added: 0014084 | |
| 2007-05-18 18:27 | Shining Phoenix | Note Edited: 0014031 | |
| 2007-05-18 18:28 | Shining Phoenix | Note Edited: 0014058 | |
| 2007-05-18 18:28 | Shining Phoenix | Note Edited: 0014084 | |
| 2007-05-18 18:29 | tabrisnet | Note Added: 0014172 | |
| 2007-05-18 18:30 | tabrisnet | Note Added: 0014173 | |
| 2007-05-18 18:31 | Shining Phoenix | Note Edited: 0014084 | |
| 2007-05-18 18:32 | Shining Phoenix | Note Added: 0014174 | |
| 2007-05-18 18:33 | Shining Phoenix | Note Edited: 0014174 | |
| 2007-05-25 07:14 | Shining Phoenix | Note Edited: 0014174 | |
| 2007-05-25 07:41 | Shining Phoenix | Note Edited: 0014174 | |
| 2007-05-25 07:50 | Shining Phoenix | Note Edited: 0014174 | |
| 2007-05-25 23:18 | Shining Phoenix | Note Edited: 0014174 | |
| 2007-08-06 22:34 | Shining Phoenix | Note Edited: 0014174 | |
| 2007-08-06 22:41 | Shining Phoenix | Note Added: 0014690 | |
| 2007-08-08 21:09 | Shining Phoenix | Note Edited: 0014174 | |
| 2008-06-28 19:39 | nate | Status | feedback => assigned |
| 2008-06-28 19:39 | nate | Assigned To | => nate |
| 2008-06-28 19:41 | nate | Relationship added | has duplicate 0003709 |
| 2013-01-09 09:57 | syzop | Assigned To | nate => |
| 2013-01-09 09:57 | syzop | Status | assigned => feedback |
| 2015-07-13 22:36 | syzop | Note Added: 0018495 |
