View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002044 | unreal | ircd | public | 2004-08-27 20:55 | 2005-01-29 13:00 |
| Reporter | medice | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.2.3 | ||||
| Summary | 0002044: Implementation of Invex (chanmode +I) | ||||
| Description | I didn't find any record with this - so I hope that I've nothing overseen... well - I really like these to modes I've seen on other ircds: +I -invite exception - works similar to +e - working on +i instead on +b-situations +B -banlink - works similar to +L and joins users to a different channel - usefull if a community which wants to establish some kind of special channel in dealing with bans | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0002273 | closed | +e exempts +i as well |
|
|
Well that +B isn't going to happen. That would be a horrible idea. So you flood, and I kick you... now you automatically join another channel so that you can flood it? 500 clones join my channel, I ban them, now they automatically join another channel? That's horrible! As for +I, I have nothing against it, but can you provide situations where it is really necessary? What I mean is, it overrides +i... Well why use +i? If you set +b *@*, no one can join. If you /invite a +b'ed user, they can join. And if they are on the +e list, they can join. So why not just set +b *@* instead of +i and get the same effect? |
|
|
well - +I may be used as a permanent /invite in some kind - chan-ops may be set +I to be able to join in case there is a +i during an attack for example (i've never seen anyone set +b *!*@* , although it makes the same...) or the owner may usually not be able to join because for some reason there has a +k been set so the users need not to twiggle around with services (if there are any) or start to look who's online at that moment and communicate with than there might not be a severe necessarity in this case - but it's a nice feature and since unreal has already many nice feature it will perfectly fit in, I believe. for those who want to see +I in action - efnet has it. |
|
|
If you set the channel +b *@* the users can't speak or change their nick, so +I would be nice. |
|
|
Set services to autovoice everyone who joins? But +e completely protects you from the effects of +b, so if you are +e'd so that you can join, then you can still talk/change nick. As for +B, I have to agree with codemastr... though you could try coding an extended ban module to provide something like this, in which case you can select the banmask and the channel... like +b ~<whatever>:*!*@*.aol.com:#AOL or somesuch (IPv6 addys might create a problem with :. If so, use something like ; or TAB instead :P .) Shouldn't be too hard :/ . |
|
|
I always disliked the idea of autovoice for each and everyone - since a simple +m doesn't get the channel quite in case it's necessary... i haven't thought on all the behaviour of +b before - so thanks yodaone :) [edit] +e does protect form +b - but if you make +b *!*@* to lock a channel - every normal user in the channel is banned - which means no talk - no nickchange - so +i is the better solution to lock a channel temporarily [/edit] +B isn't that important - was just a suggestion, in fact there is a +B-module going around, but it seems terribly broken (unreal does not start with module - rehashing module in after start seems to work - but that's nothing I'd dare to use...) and I'm no coder at all and have no time to learn C & Co from scratch ;) but it's really not that important... edited on: 2004-08-28 08:26 |
|
|
The only difference between +iI and +be would be this: Users: [email protected] [email protected] [email protected] [email protected] We want our channel #friends to be a private channel (only let friends in), and to keep BadGuy out of it. #friends +iI *!*@*.wp.shawcable.net #friends +b *!*@ca-93C8F345.wp.shawcable.net Without +I, you'd have to do it this way: #friends +b *@* #friends +e *@ca-BB178F31.wp.shawcable.net #friends +e *@ca-DB598A58.wp.shawcable.net #friends +e *@ca-8D76C321.wp.shawcable.net As this is a small example, in a larger channel, this would fill up the banlist and could possibly reach the exception ban limit. Your proposed +B mode would just create a new tool for flooders to have fun on your server. |
|
|
maybe have a options in config, if u set +B to go to a certain channel - soon as they join the server bans them? - thus u ban something coz of bots flood they instaly go to that channel and they are K G or GZ`ed, Thats the only thing i can see +B being usful for. |
|
|
Well does anyone else have any opinions on +I? If I'm going to add something big like this, I'd kinda like to see more than just 1-2 users supporting it... |
|
|
Well, as I was saying, there's really not much difference between using +be and using +iI. They'll still perform the same basic thing (with minor differences). I don't think +I is important, and I probably won't be using it -- so in other words, I'm not really supporting it. Edit: Perhaps if someone really needs it, they could ask someone else to code a separate module to implement it. edited on: 2004-09-05 00:37 |
|
|
I am though :) . One thing that's going into WinSE is the ability to manage +e and +I lists via ChanServ in the same way one manages +b. Without IRCd-side support for invex(+I), I'd have to resort to watching for knocks and autoinvite (and/or forcejoin) the appropriate users... (mind I'm not quite sure how I'd go about when an invite list entry is pushed into a channel... *poke @ w00t* *edit* >Edit: Perhaps if someone really needs it, they could ask someone else to code a separate module to implement it. I don't know if that's possible. IIRC, Unreal internally handles I because mIRC would freeze if anything other than the "End of List" numeric was returned. ...codemastr beat me, didn't he? :P edited on: 2004-09-05 00:49 |
|
|
al5001, well first off, a module can not do this, so that's already out of the question. |
|
|
We want our channel #friends to be a private channel (only let friends in), and to keep BadGuy out of it. #friends +iI *!*@*.wp.shawcable.net #friends +b *!*@ca-93C8F345.wp.shawcable.net Without +I, you'd have to do it this way: #friends +b *@* #friends +e *@ca-BB178F31.wp.shawcable.net #friends +e *@ca-DB598A58.wp.shawcable.net #friends +e *@ca-8D76C321.wp.shawcable.net whats wrong with +e *!*@*.wp.shawcable.net??? I dont support this either i cat see the point, unless +I was resevered for users with umode +r to use it it? *shrugs* |
|
|
whats wrong with +e *!*@*.wp.shawcable.net??? ---> We don't want [email protected] to join. Therefore, we ban *!*@* and channel except on all other hosts that should be allowed in (or you could ban *!*@*.wp.shawcable.net as well). |
|
|
+I -invite exception - works similar to +e - working on +i instead on +b-situations We want our channel #friends to be a private channel (only let friends in), and to keep BadGuy out of it. #friends +iI *!*@*.wp.shawcable.net #friends +b *!*@ca-93C8F345.wp.shawcable.net - Ok, So u ban the badguy IP but u have his ISP on +I - Invite overrides a ban... therefore ur not keeping him out the channel.... Oh and coz the channel is Already +i - it clearly shows that the badguy is allowed to use +I so this is usless far as i see or am i missing something? coz thats what it looks like to me. *edit to fill in +i / +I text* edited on: 2004-09-06 10:02 |
|
|
IIRC, Invex doesn't quite work that way. In other words, matching an invite mask isn't quite the same as being actually invited. Invexs are *inv*ite *ex*ceptions, which means matching people are allowed to walk +i (invite-only), but nothing else AFAIK. |
|
|
[quote]matching an invite mask isn't quite the same as being actually invited. Invexs are *inv*ite *ex*ceptions, which means matching people are allowed to walk +i (invite-only), but nothing else AFAIK.[/quote] Well, it's kinda hard to say. Hybrid, for example, doesn't let /invite override +b either! The only time Hybrid checks either the +I list or the /invite list is when the channel is +i. Bahamut is different though. In Bahamut, +I overrides everything *except* +b. I haven't tested yet, but it seems as though, even if the channel is +k, if you are +I'ed, then you can join. IRCNet seems to work like Hybrid. +I only overrides +i. I'm not really sure which way is best, both have merit. For example, it would allow an op to get passed +l really easily. But, it also has bad points. Like if I set +I *@*.someisp.com, and my channel is +R, well now non-registered users from that ISP can come in, which probably is not what I wanted. If anyone has suggestions on which way is better, I'm willing to listen. |
|
|
Hm... well, some possibilites: 1 /invite works like it does now (overrides everything except +AO). +I list only overrides +i. 2 /invite works like it does now (overrides everything except +AO). +I list only overrides +ikl. 3 As #1, but ~R:mask entries override +R as well. 4 As #2, but ~R:mask entries override +R as well. 5 As #1, but ~o:mask ("operator") entries override +kl. 6 As #5, but said ~o:mask entries override everything except +AO like /invite does. Combinations could get interesting, such as #3 and #5 combined could be useful... Naturally, 3, 4, 5, and 6 would mean implementing the extended ban system on the +I list... but... |
|
|
whatever comes: it should be clearly documented, what is overriden by +I... as a mather of fact I'm not really sure what an /invite exactly overrides - so don't stone me right after (maybe an idea to document this?) I think there are 2 points of views: on one side: it's the user who has to make clever mode-settings (+I *!*@* - jippie ;) ) on the other side - what I personally think would be senseful... generally spoken /invite overrides modes that block joining a channel - so I had a look on the modes which are actually blocking (hope didn't forget any) A/O --> nothing I'd like to be overriden by /invite nor +I z --> same - it would allow matching non-sslers to join R --> as mentioned - no - it would allow unregistered users in which brakes the idea of +R b --> difficult decision - there is +e, but why not - I'm honestly not quite sure... i --> well thats where the whole thing started --> yes! k --> +k provides a similarity to +i, in my opinion, on a "close the channel down"-point of view it's weaker than +i since the key may be told around anywhere - so yes l --> yes (but I'm personnally not really using +l often and have not many experiences... many channels I've seen just set +l to have a cool mode-look +l 1337 ... whatever they want...) is it really necessary to implement the extended ban-system in +I? it's a fine idea, so you may define severyl extensions with special mode-overrides, but I think this is a heavy to complex thing and don't know if it brakes clients? |
|
|
Thanks for explaining that aqua :) my thoughts are +I should override +il only - The reason against k is it could allow a user to " fix " the channel and make it open to floods / bots - but not only against them any unwated guests. modes - R z b A O need to keep their purpose, should someone crack a channel key in any chance at least they can still set +R to stop <whatever> entering. or even use +z to stop them... codemastr is defently mode +B out - even thou i suggested a possible use for it? |
|
|
[quote]is it really necessary to implement the extended ban-system in +I?[/quote]If I did add extban support to +I, it wouldn't be like was suggested. It would work just like the current system, e.g., +I ~r:*blah* adds an invite for someone with a realname matching that. If we did it any other way, it would just lead to confusion. [quote]The reason against k is it could allow a user to " fix " the channel and make it open to floods / bots - but not only against them any unwated guests[/quote] Can you explain this? I don't understand what "fix the channel" means at all. And I don't see how this makes it open to floods? As medice kind of mentioned, +k isn't a good flood stopper because if the key is discovered, then the bots can join. How does +I make the situation any worse? [quote]codemastr is defently mode +B out - even thou i suggested a possible use for it?[/quote] Your use made no sense to me. You said that you would set them +b, then have them redirected to #somechan where they are akilled... Well why bother setting them +b to begin with? Why not just akill them immediately? That doesn't make sense to me. All it does is redirect them to another channel where they will continue to flood until they are akilled, and if services are down and the akill is not automatically added, well now they just keep on flooding. And if you really wanted it, that could be done with a module. edited on: 2004-09-06 20:07 |
|
|
Well, some of the extended ban stuff doesn't quite work very well with Invex... for example, ~q and ~n have no meaning with invex. Granted this would be simple to integrate by just passing the BANCHK_JOIN to the check routines, and the EXBTYPE_EXCEPT (or a new constant) for the (un)set routines... |
|
|
Can you explain this? I don't understand what "fix the channel" means at all. And I don't see how this makes it open to floods? As medice kind of mentioned, +k isn't a good flood stopper because if the key is discovered, then the bots can join. How does +I make the situation any worse? " Fix the channel " i mean to set it up so it can be exposed / attacked. Invite could override +k so they could add the bots to +I which would allow them to flood, and maybe the channel ops wouldnt know why they can keep coming in *even thou +i is on they are still joining* - this is how i see it as worse. |
|
|
>" Fix the channel " i mean to set it up so it can be exposed / attacked. >Invite could override +k so they could add the bots to +I which would allow them >to flood, and maybe the channel ops wouldnt know why they can keep coming in >*even thou +i is on they are still joining* - this is how i see it as worse. Uhhhh Only a _Channel Operator's_ Invite will override +bikl. If an Operator adds floodbots/etc to the +I list, then he should be subject to punishment by the other channel staff. *edit* (blah, how did you get those funny quote:| thingies? :\) */edit* edited on: 2004-09-07 16:29 |
|
|
[quote]and maybe the channel ops wouldnt know why they can keep coming in *even thou +i is on they are still joining* - this is how i see it as worse.[/quote] If the channel ops don't know what +I is, why did they set it? [quote]*edit* (blah, how did you get those funny quote:| thingies? :\) */edit*[/quote] I got tired of typing out ">" at the beginning so I added support for the bbcode [quote] tag. At the end you also need a [/ quote] (without the space) to tell it where the quote ends. |
|
|
[quote]If the channel ops don't know what +I is, why did they set it?[/quote] Of course... this is one of this cases where using SVSMODE to clear a channel list (namely +beI) could be useful for a normal user... :) |
|
|
I prefer ircnet/hybrid's way.. +I only affecting +i. In practical situations I've experienced that +l(/+k) overriding can be quite helpful too. I'm however against making +I affect any other chanmode than +i/+l/+k (such as +b)... that would be very confusing. In fact, I'm not sure at all whether +I should affect +ilk or only +i... Because if it affects +l it can be very confusing... '*** Alpha sets mode: +l 0 *** Beta has joined #test <Alpha> Hi Beta. Uhm.. how did you join? <Beta> I'm on the invite exception list <Alpha> But the channel is not invite only <Beta> Yeah, well...' I also thought of other ideas like making it only override +l/+k when +i is set AND +l or +k, but that makes it only MORE confusing IMO. Seeing as how there are currently 2 variations around... ircnet, hybrid: +I overriding +i bahamut: +I overriding all chanmodes (even +O) except +b I'm not sure if adding yet another variation (eg +I affecting +i/+l/+k) is a good idea. It should be clear at least, that the practical advantages of +lk overriding should outweight the confusion it adds. @extban alike stuff.. I'm not too keen on that for +I.. both me & codemastr are not 100% convinced that +I is so very useful, so I don't think anyone of us is really willing to make it so complex/put so much time/effort in it. |
|
|
Yes... definately no +b overriding... that's what +e is for :P . [quote]bahamut: +I overriding all chanmodes (even +O) except +b[/quote] AFAIK, the only modes that block joins are +iklRO. I really don't think a nonoper should be allowed to join an oper-only channel by any means short of /sajoin :P (and probably not even that...). So that leaves +iklR. I like to think of +R as a form of +i, not really different. Though +R is intended to keep out unregistered users, it's mostly used as flood control / anti-spambot. I could tell users to register and identify, but how would I do so? I only have the topic visible to outsiders, and I might have +s'd my channel to help turn away yet more spambots... and of course, they can't /knock because the channel is not +i... so all they can do is pray I'm online and PM me... or of course take the initiative and register their nicks, but then there's the possibilty of services downtime (mind: in the real world, I'd probably -R and use something else if services go down - having NickServ in the notify list helps :D !). But of course you can think of this: INVEX is INVite EXception. Matching users are exempt from /invite requirements. The only the mode that imposes an invite requirement is +i. +bkl simply have invite as an override. Someone trusted with an INVEX should probably also have the channel key, and probably can just wait until the channel membership decreases or the limit is increased. Or they can /chanserv INVITE :-) . If you ask me, I'd say utilize the extban system so that the choice can be left to channel operators. |
|
|
Um 1 question... '*** Alpha sets mode: +l 0 *** Beta has joined #test <Alpha> Hi Beta. Uhm.. how did you join? <Beta> I'm on the invite exception list <Alpha> But the channel is not invite only <Beta> Yeah, well...' um if Alpha had set a +L - im presumming they would go to the other channel right? i also agree with syzop, the only modes i should see it affect are +il. edited on: 2004-09-08 12:12 edited on: 2004-09-08 12:14 |
|
|
[quote]um if Alpha had set a +L - im presumming they would go to the other channel right?[/quote] Yeah, +L is where +l gets even more tricky. Because imho, if we say "+I overrides +l" but "+I does not override +lL" that makes things even more confusing! :P So I'm kinda leaning towards just +I overrides +i. It seems everything else is going to lead to some kind of confusion. |
|
|
Yeah. It probably wouldn't be to hard for services to provide a form of override for other modes if it was wanted... like check if the channel is +l, the user has some ChanServ privilege to override the limit, he can just ask ChanServ to let him in (which can of course include either raising/removing the limit or simply inviting the requester)... |
|
|
aquanight: well, yes.. authorized users can just /CS INVITE themselves.. this has existed for years and it's a nice feature (eg: for bots) since it goes trough a lot of modes ;p. Anyway, good! Then we hereby decide that +I only overrides +i! :P |
|
|
syzop: I wasn't referring specifically to /cs invite. There could be restricted versions that any one can use but have a few conditions, like match a +I and only +l is set (nothing else, like +kAOzb - unless of course the user meets the necessary conditions (knows the key, is an admin/oper/ssler, or matches a +e :P )) and user is on the access list or something like that and the channel isn't over the limit by a significant amount, or something along those lines... but yeah INVITE works too :) . |
|
|
I would also like to see +I implemented. It seems it can be a useful feature in private channels where only certain users are allowed to join. With current invites, you need to invite every user every time he/she connects. With +I that user stayes on the invite list, and there is no re-inviting needed. |
|
|
Our network needs +I or something similar to it. There is a student hostel connected to our network, and they want to keep their channel private, i.e. only students can join. Early they used hybrid ircd and &channel. Now they reject to migrate to unrealircd for this reason. They say +I would be fine, but unrealircd doesn't support it. :( +e is not solution for them, because channel ops sometimes have to ban some students when they talk badly or otherwise break channel rules. This userbase is quite big and we don't want to loose them. Please implement +I. Another solution might be to implement "inverted" or "non-match" bans. That is, mode like "+b ~i:*!*@*.hostel.net" means that everyone that does not match "*!*@*.hostel.net" is banned. But it's unclear what to do with multiple such bans. So +I is better in my opinion. |
|
|
don't worry, +I is scheduled for Unreal3.2.3 :P. |
|
|
Also, the "inverse ban" idea could easily be done in a module. |
|
|
"Inverse ban" is the same thing as: mode #channel +be *!*@* *!*@*.hostel.net I dont see a need for another extended bantype for something so easily done otherwise. |
|
|
Well what happens if you want to ban *!*@user-7F000001.hostel.net ? But like I said, it'd be like supereasy to do that in a module so blah :P . |
|
|
*Quote: medice * l --> yes (but I'm personnally not really using +l often and have not many experiences... many channels I've seen just set +l to have a cool mode-look +l 1337 ... whatever they want...) *End Quote* +l (channel limit) is often set between 1 and 3 higher then the current user count so for example, if 100 floodbots try to join at the same time, only 1-3 will get in (depending on the user count/channel limit ratio). This mode is more useful then it often seems. Unfortunately, the floodbots can still probably get in (slowly) as the bot/script gradually sets the channel limit higher and higher as the floodbots join. But this is a problem for bot developers and irc client scripters, which can easily be worked around, and has been on most bots by setting +ikm when there is a join flood, even if all of the hosts are different. In conclusion, I'd have to say that +l is important to avoid channel floods. |
|
|
+I is added in .240 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-08-27 20:55 | medice | New Issue | |
| 2004-08-27 21:04 |
|
Note Added: 0007440 | |
| 2004-08-27 21:38 | medice | Note Added: 0007441 | |
| 2004-08-28 05:15 | yodaone | Note Added: 0007442 | |
| 2004-08-28 05:44 | aquanight | Note Added: 0007443 | |
| 2004-08-28 08:23 | medice | Note Added: 0007445 | |
| 2004-08-28 08:26 | medice | Note Edited: 0007445 | |
| 2004-08-29 17:23 | al5001 | Note Added: 0007453 | |
| 2004-09-04 16:28 | White_Magic | Note Added: 0007518 | |
| 2004-09-04 22:55 |
|
Note Added: 0007528 | |
| 2004-09-05 00:36 | al5001 | Note Added: 0007531 | |
| 2004-09-05 00:37 | al5001 | Note Edited: 0007531 | |
| 2004-09-05 00:42 | aquanight | Note Added: 0007532 | |
| 2004-09-05 00:48 |
|
Note Added: 0007533 | |
| 2004-09-05 00:49 | aquanight | Note Edited: 0007532 | |
| 2004-09-05 04:08 | White_Magic | Note Added: 0007535 | |
| 2004-09-05 19:31 | al5001 | Note Added: 0007543 | |
| 2004-09-06 09:59 | White_Magic | Note Added: 0007557 | |
| 2004-09-06 10:02 | White_Magic | Note Edited: 0007557 | |
| 2004-09-06 14:38 | aquanight | Note Added: 0007558 | |
| 2004-09-06 16:28 |
|
Note Added: 0007559 | |
| 2004-09-06 16:39 | aquanight | Note Added: 0007560 | |
| 2004-09-06 17:14 | medice | Note Added: 0007561 | |
| 2004-09-06 19:40 | White_Magic | Note Added: 0007563 | |
| 2004-09-06 20:07 |
|
Note Added: 0007564 | |
| 2004-09-06 20:07 |
|
Note Edited: 0007564 | |
| 2004-09-06 22:17 | aquanight | Note Added: 0007567 | |
| 2004-09-07 16:23 | White_Magic | Note Added: 0007575 | |
| 2004-09-07 16:27 | aquanight | Note Added: 0007576 | |
| 2004-09-07 16:29 | aquanight | Note Edited: 0007576 | |
| 2004-09-07 19:26 |
|
Note Added: 0007578 | |
| 2004-09-07 19:30 | aquanight | Note Added: 0007579 | |
| 2004-09-07 20:32 | syzop | Note Added: 0007582 | |
| 2004-09-08 03:20 | aquanight | Note Added: 0007586 | |
| 2004-09-08 12:12 | White_Magic | Note Added: 0007587 | |
| 2004-09-08 12:12 | White_Magic | Note Edited: 0007587 | |
| 2004-09-08 12:14 | White_Magic | Note Edited: 0007587 | |
| 2004-09-08 17:43 |
|
Note Added: 0007592 | |
| 2004-09-08 17:51 | aquanight | Note Added: 0007593 | |
| 2004-09-09 00:36 | syzop | Note Added: 0007596 | |
| 2004-09-09 05:21 | aquanight | Note Added: 0007598 | |
| 2004-09-21 17:19 | Stealth | Note Added: 0007753 | |
| 2004-12-03 05:41 | Lynxer | Note Added: 0008463 | |
| 2004-12-03 11:09 | syzop | Note Added: 0008464 | |
| 2004-12-03 11:12 | syzop | Status | new => confirmed |
| 2004-12-03 11:58 | aquanight | Note Added: 0008468 | |
| 2004-12-03 18:23 | Stealth | Note Added: 0008478 | |
| 2004-12-04 02:52 | aquanight | Note Added: 0008479 | |
| 2004-12-04 23:07 | pepolez | Note Added: 0008497 | |
| 2005-01-11 15:54 |
|
Relationship added | has duplicate 0002273 |
| 2005-01-29 12:13 |
|
Summary | Implementation of Invex (chanmode +I) and Banlink (chanmode +B) => Implementation of Invex (chanmode +I) |
| 2005-01-29 12:19 |
|
Status | confirmed => resolved |
| 2005-01-29 12:19 |
|
Resolution | open => fixed |
| 2005-01-29 12:19 |
|
Assigned To | => codemastr |
| 2005-01-29 12:19 |
|
Note Added: 0008938 | |
| 2005-01-29 13:00 |
|
Fixed in Version | => 3.2.3 |
