0002040: +L without +l? - UnrealIRCd Bug Tracker

(0007420)
medice (reporter)
2004-08-24 09:09

is there a need for -L om l?

maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it...

on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well...

(0007422)
aquanight (reporter)
2004-08-25 02:20

Hm... yes I thought of this.

>maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it..

I'm thinking that typically +l and +L would be set in mlock - at least when used together. I can imagine using +l for join controls (though +f does a better job of this :P ), but in such a case would you use +L? I don't quite see the point in sending massjoinflooders to a different channel - flooding it instead :) .
Also, there's a way to "disable the limit" but still leave the channel +l: (try to) set the limit to 2147483647 which is probably the effective limit when -l :P .

>on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well..

I had considered that if this were done, +l wouldn't be able to be unset (maybe changed to a different number, but not to "set" to 0 (aka unset)) for the reason you mentioned that nonowners would otherwise become able to -L...

I guess what we'd need is to look and see how +L is being used (if it's being used :/ )... maybe... problem is I don't know anyone that uses +L :P maybe the coders do... *poke*

(0007427)
w00t (reporter)
2004-08-26 05:46

I use +L personally, a useful tool for locking say, filesharing channels. Redirect them to the main channel (>:)). The one thing I don't like about +L is it is owner-only, meaning if you don't have services, you have to +q yourself to use it. Makes sense, I suppose... but yeah. :) "if you cant trust your chanops, dont make them chanops" >:)

(0007432)
aquanight (reporter)
2004-08-26 20:29

Well I notice that with +i and +K, -i also does -K:

-> MODE #Test +iK
<- :aquanight!~aquanight@netadm.dragons.net MODE #Test +iK
-> MODE #Test -i
<- :aquanight!~aquanight@netadm.dragons.net MODE #Test -iK

So in a way, it's inconsistant. /me wonders what other modes should be tried...
In this case, I can understand: +K is meaningless because /KNOCK can't be used on a channel that isn't +i (though +R isn't enough either?). But on the same token, +L has no meaning on a "limitless" channel.

(0007433)
yodaone (reporter)
2004-08-26 22:46

Maybe +L should always redirect the users if +l isn't set

(0007438)
aquanight (reporter)
2004-08-27 02:31

>Maybe +L should always redirect the users if +l isn't set

That can be acheived with +l - set it to 1 :P .

(0007439)
yodaone (reporter)
2004-08-27 19:51

Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p

(0007444)
aquanight (reporter)
2004-08-28 05:46

> Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p

I don't see where you get that logic from. You were suggesting +L do something without +l. The point is: it doesn't, so why does it "stick around" without it's partner?

(0007446)
yodaone (reporter)
2004-08-28 08:52

You say +L should be unset at the same time as +l, but there is this +L=owner-only problem.
So why don't make +L an independent mode and forget -L on -l.

(0007447)
aquanight (reporter)
2004-08-28 19:07

:/

I already metioned how this could be handled: if +L is set, a normal chanop could be prevented from doing -l at all, but using +l to change the limit would be okay.

(0007465)
al5001 (reporter)
2004-08-31 02:23

+L is a handy feature for large channels. Suppose your channel usually gets 80 people. You wouldn't want them all talking at once in #channel-1, so you'd set +lL 40 #channel-2. This feature should stay in the IRCd.

I don't see the reason to set -L on -l. What if someone wants to temporarily stop the channel link? For example, unset +l and then set it again later? I don't see why this mode should be changed.

+L is also set for channel owner for a reason; You wouldn't want any op to just link your channel to his. This should not be changed.

(0007466)
aquanight (reporter)
2004-08-31 02:27

>I don't see the reason to set -L on -l. What if someone wants to temporarily
>stop the channel link? For example, unset +l and then set it again later? I
>don't see why this mode should be changed.

As I mentioned, in most cases you'd probably have +l mlocked or something.

If you have a floating limit however, then it is possible to "disable" it by simply changing the limit to a ridiculously high value. Besides, if you can't trust the chanops, why are they chanops?

(0007480)
al5001 (reporter)
2004-09-03 04:38

"Besides, if you can't trust the chanops, why are they chanops?"

Ok, if you've ever understood the purpose of a hierarchy, you'll know my whole point. Take an army, for example. People don't just go from Private to Warrant Officer right away. They do however, get to the next step: the rank of Corporal. The Warrant Officer can lead the platoon, whereas the Corporal can only lead a squad of four inside the platoon. Now, you're saying this: Why shouldn't the Corporal be able to lead the whole platoon? (if you can't trust the chanops, why are they chanops? --> if you can't trust the Corporals, why are they Corporals?). It all comes down to the hierarchy system. You don't just give someone full privileges right away.

(0007481)
aquanight (reporter)
2004-09-03 15:39

Hm... it's not quite the same thing...

Giving someone chanop on a channel is usually a sign of trust. Would you give ops to just any random person that asked for it? Probably not.

*pokes coders*

(0007520)
White_Magic (reporter)
2004-09-04 16:38
edited on: 2004-09-04 16:40

maybe the purpose is coz of "thinking ahead" -

add a limit, add a +L link, remove the limit, in a flood, simple add the limit and you *dont* need to the add the link coz it there...

same story with +K, add +i add +K, remove the +i, and ur reassured the next time u set +i u *WONT* get a Knock flood becuz +K was never removed in the first place....

*edit* prevention is better than cure...

edited on: 2004-09-04 16:40

(0007521)
aquanight (reporter)
2004-09-04 16:41

Um. No. +K *IS* removed when you set -i.

(0013485)
WolfSage (reporter)
2007-04-17 17:41
edited on: 2007-04-17 17:44

This should behave identical to +i/+K regardless of how we actually want both mode sets to behave. Let's recap:

You CANNOT set +K without +i.
You CANNOT set +L without +l.

+K without +i is worthless, it does nothing, knocking isn't allowed unless +i is set.
+L without +l is worthless, it does nothing, joining won't kick you to a different channel unless +l is set and the limit is reached.

Now, allowing the modes to remain set so that a user can simply +i or +l a channel and let the defaults take over certainly would be nice, as it makes it easier for the user.

But disabling the modes automatically also makes it easier for the user who uses them in the ways intended.

Here's what I think should happen:

If a set of modes such as i/K, l/L can coexist or exist on its own without causing any behavior issues in Unreal, then I think we should leave it up to the user to decide what they want to do. In this case, the user could set +L and +K without +l or +i being set.

The only problem I can see with this is that users who don't fully understand what the modes are for won't then have the incite given to them by the errors that are currently provided.

So it seems to come down to:

Would allowing users to set the modes and remove them manually be an issue?
Is it worth the possibility of confusing users?

And if not, then we simply make +l/+L behave exactly as +i/+K, and -L when -l is set.

(0013496)
Shining Phoenix (reporter)
2007-04-18 04:51

WolfSage: Microsoft Word does stuff that the programmers thought would be helpful. I hate it. Changing user's channel modes for them is similar. I think we should let them set unset iKlL whenever they want, and not have the server do it for them.

(0013501)
stskeeps (reporter)
2007-04-18 04:59

+l should remove +L due to the fact on net.join +L won't be set cos +l isn't set, and we have a desync.

(0013560)
WolfSage (reporter)
2007-04-18 19:48

Your logic here baffles me Sts =)

(0013570)
Bricker (reporter)
2007-04-18 22:40

what sts is saying, i believe, is that the modes arnt reset after a netsplit or during desync, so the server trying to force +L which cannot be set without +l would break something. This has been an issue for quite some time, and should have been fixed, but i guess its going to be now

(0013892)
stskeeps (reporter)
2007-04-27 13:13

Another issue. +L can only be set/unset by +q users.. if we allow -l to take away +L, we would subvert this .. just noticed this while trying to add this functionality.

(0013893)
vonitsanet (reporter)
2007-04-27 13:28

when +L is active only allow +q to remove -l

(0013910)
stskeeps (reporter)
2007-04-28 08:26

WolfSage suggest making the modes independent (ie, +L doesnt require +l to be set), which is feasible. Any comments? This will break backwards compatibility, but it is needed :P

(0013998)
stskeeps (reporter)
2007-05-04 08:36

Patched in .2387, removing dependancy on +l for +L. This will be backwards compatible as well, SJOIN doesn't care (TM) and mode doesn't either in case of a server sending it. So this will be just a client protocol modification. Also pulled out a modification that got in accidentially. The reason it is feasible is due to the fact +l 0 and +l 1 will be, honestly, the same, and we can read +l 0 as being +l 1 if the channel has one user that keeps it open.

Notes
(0007420) medice (reporter) 2004-08-24 09:09	is there a need for -L om l? maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it... on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well...

(0007422) aquanight (reporter) 2004-08-25 02:20	Hm... yes I thought of this. >maybe someone wants to disable the limit but reinstall it later on - so it's more comfortable if +L stays in the meantime ans he has not to care for it.. I'm thinking that typically +l and +L would be set in mlock - at least when used together. I can imagine using +l for join controls (though +f does a better job of this :P ), but in such a case would you use +L? I don't quite see the point in sending massjoinflooders to a different channel - flooding it instead :) . Also, there's a way to "disable the limit" but still leave the channel +l: (try to) set the limit to 2147483647 which is probably the effective limit when -l :P . >on another point of view L is owner-only (if I remember correctly) and +l is not - so you enable the unset of this mode to non-owners as well.. I had considered that if this were done, +l wouldn't be able to be unset (maybe changed to a different number, but not to "set" to 0 (aka unset)) for the reason you mentioned that nonowners would otherwise become able to -L... I guess what we'd need is to look and see how +L is being used (if it's being used :/ )... maybe... problem is I don't know anyone that uses +L :P maybe the coders do... poke

(0007427) w00t (reporter) 2004-08-26 05:46	I use +L personally, a useful tool for locking say, filesharing channels. Redirect them to the main channel (>:)). The one thing I don't like about +L is it is owner-only, meaning if you don't have services, you have to +q yourself to use it. Makes sense, I suppose... but yeah. :) "if you cant trust your chanops, dont make them chanops" >:)

(0007432) aquanight (reporter) 2004-08-26 20:29	Well I notice that with +i and +K, -i also does -K: -> MODE #Test +iK <- :aquanight!~aquanight@netadm.dragons.net MODE #Test +iK -> MODE #Test -i <- :aquanight!~aquanight@netadm.dragons.net MODE #Test -iK So in a way, it's inconsistant. /me wonders what other modes should be tried... In this case, I can understand: +K is meaningless because /KNOCK can't be used on a channel that isn't +i (though +R isn't enough either?). But on the same token, +L has no meaning on a "limitless" channel.

(0007433) yodaone (reporter) 2004-08-26 22:46	Maybe +L should always redirect the users if +l isn't set

(0007438) aquanight (reporter) 2004-08-27 02:31	>Maybe +L should always redirect the users if +l isn't set That can be acheived with +l - set it to 1 :P .

(0007439) yodaone (reporter) 2004-08-27 19:51	Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p

(0007444) aquanight (reporter) 2004-08-28 05:46	> Yes, but then there is no reason to remove +L on -l so this "bug" could be closed :p I don't see where you get that logic from. You were suggesting +L do something without +l. The point is: it doesn't, so why does it "stick around" without it's partner?

(0007446) yodaone (reporter) 2004-08-28 08:52	You say +L should be unset at the same time as +l, but there is this +L=owner-only problem. So why don't make +L an independent mode and forget -L on -l.

(0007447) aquanight (reporter) 2004-08-28 19:07	:/ I already metioned how this could be handled: if +L is set, a normal chanop could be prevented from doing -l at all, but using +l to change the limit would be okay.

(0007465) al5001 (reporter) 2004-08-31 02:23	+L is a handy feature for large channels. Suppose your channel usually gets 80 people. You wouldn't want them all talking at once in #channel-1, so you'd set +lL 40 #channel-2. This feature should stay in the IRCd. I don't see the reason to set -L on -l. What if someone wants to temporarily stop the channel link? For example, unset +l and then set it again later? I don't see why this mode should be changed. +L is also set for channel owner for a reason; You wouldn't want any op to just link your channel to his. This should not be changed.

(0007466) aquanight (reporter) 2004-08-31 02:27	>I don't see the reason to set -L on -l. What if someone wants to temporarily >stop the channel link? For example, unset +l and then set it again later? I >don't see why this mode should be changed. As I mentioned, in most cases you'd probably have +l mlocked or something. If you have a floating limit however, then it is possible to "disable" it by simply changing the limit to a ridiculously high value. Besides, if you can't trust the chanops, why are they chanops?

(0007480) al5001 (reporter) 2004-09-03 04:38	"Besides, if you can't trust the chanops, why are they chanops?" Ok, if you've ever understood the purpose of a hierarchy, you'll know my whole point. Take an army, for example. People don't just go from Private to Warrant Officer right away. They do however, get to the next step: the rank of Corporal. The Warrant Officer can lead the platoon, whereas the Corporal can only lead a squad of four inside the platoon. Now, you're saying this: Why shouldn't the Corporal be able to lead the whole platoon? (if you can't trust the chanops, why are they chanops? --> if you can't trust the Corporals, why are they Corporals?). It all comes down to the hierarchy system. You don't just give someone full privileges right away.

(0007481) aquanight (reporter) 2004-09-03 15:39	Hm... it's not quite the same thing... Giving someone chanop on a channel is usually a sign of trust. Would you give ops to just any random person that asked for it? Probably not. pokes coders

(0007520) White_Magic (reporter) 2004-09-04 16:38 edited on: 2004-09-04 16:40	maybe the purpose is coz of "thinking ahead" - add a limit, add a +L link, remove the limit, in a flood, simple add the limit and you dont need to the add the link coz it there... same story with +K, add +i add +K, remove the +i, and ur reassured the next time u set +i u WONT get a Knock flood becuz +K was never removed in the first place.... edit prevention is better than cure... edited on: 2004-09-04 16:40

(0007521) aquanight (reporter) 2004-09-04 16:41	Um. No. +K IS removed when you set -i.

(0013485) WolfSage (reporter) 2007-04-17 17:41 edited on: 2007-04-17 17:44	This should behave identical to +i/+K regardless of how we actually want both mode sets to behave. Let's recap: You CANNOT set +K without +i. You CANNOT set +L without +l. +K without +i is worthless, it does nothing, knocking isn't allowed unless +i is set. +L without +l is worthless, it does nothing, joining won't kick you to a different channel unless +l is set and the limit is reached. Now, allowing the modes to remain set so that a user can simply +i or +l a channel and let the defaults take over certainly would be nice, as it makes it easier for the user. But disabling the modes automatically also makes it easier for the user who uses them in the ways intended. Here's what I think should happen: If a set of modes such as i/K, l/L can coexist or exist on its own without causing any behavior issues in Unreal, then I think we should leave it up to the user to decide what they want to do. In this case, the user could set +L and +K without +l or +i being set. The only problem I can see with this is that users who don't fully understand what the modes are for won't then have the incite given to them by the errors that are currently provided. So it seems to come down to: Would allowing users to set the modes and remove them manually be an issue? Is it worth the possibility of confusing users? And if not, then we simply make +l/+L behave exactly as +i/+K, and -L when -l is set.

(0013496) Shining Phoenix (reporter) 2007-04-18 04:51	WolfSage: Microsoft Word does stuff that the programmers thought would be helpful. I hate it. Changing user's channel modes for them is similar. I think we should let them set unset iKlL whenever they want, and not have the server do it for them.

(0013501) stskeeps (reporter) 2007-04-18 04:59	+l should remove +L due to the fact on net.join +L won't be set cos +l isn't set, and we have a desync.

(0013560) WolfSage (reporter) 2007-04-18 19:48	Your logic here baffles me Sts =)

(0013570) Bricker (reporter) 2007-04-18 22:40	what sts is saying, i believe, is that the modes arnt reset after a netsplit or during desync, so the server trying to force +L which cannot be set without +l would break something. This has been an issue for quite some time, and should have been fixed, but i guess its going to be now

(0013892) stskeeps (reporter) 2007-04-27 13:13	Another issue. +L can only be set/unset by +q users.. if we allow -l to take away +L, we would subvert this .. just noticed this while trying to add this functionality.

(0013893) vonitsanet (reporter) 2007-04-27 13:28	when +L is active only allow +q to remove -l

(0013910) stskeeps (reporter) 2007-04-28 08:26	WolfSage suggest making the modes independent (ie, +L doesnt require +l to be set), which is feasible. Any comments? This will break backwards compatibility, but it is needed :P

(0013998) stskeeps (reporter) 2007-05-04 08:36	Patched in .2387, removing dependancy on +l for +L. This will be backwards compatible as well, SJOIN doesn't care (TM) and mode doesn't either in case of a server sending it. So this will be just a client protocol modification. Also pulled out a modification that got in accidentially. The reason it is feasible is due to the fact +l 0 and +l 1 will be, honestly, the same, and we can read +l 0 as being +l 1 if the channel has one user that keeps it open.

Issue History
Date Modified	Username	Field	Change
2004-08-24 02:05	aquanight	New Issue
2004-08-24 09:09	medice	Note Added: 0007420
2004-08-25 02:20	aquanight	Note Added: 0007422
2004-08-26 05:46	w00t	Note Added: 0007427
2004-08-26 20:29	aquanight	Note Added: 0007432
2004-08-26 22:46	yodaone	Note Added: 0007433
2004-08-27 02:31	aquanight	Note Added: 0007438
2004-08-27 19:51	yodaone	Note Added: 0007439
2004-08-28 05:46	aquanight	Note Added: 0007444
2004-08-28 08:52	yodaone	Note Added: 0007446
2004-08-28 19:07	aquanight	Note Added: 0007447
2004-08-31 02:23	al5001	Note Added: 0007465
2004-08-31 02:27	aquanight	Note Added: 0007466
2004-09-03 04:38	al5001	Note Added: 0007480
2004-09-03 15:39	aquanight	Note Added: 0007481
2004-09-04 16:38	White_Magic	Note Added: 0007520
2004-09-04 16:40	White_Magic	Note Edited: 0007520
2004-09-04 16:41	aquanight	Note Added: 0007521
2006-01-22 13:59	syzop	Relationship added	has duplicate 0002757
2007-04-16 10:40	stskeeps	Relationship added	has duplicate 0002805
2007-04-17 17:41	WolfSage	Note Added: 0013485
2007-04-17 17:42	WolfSage	Note Edited: 0013485
2007-04-17 17:44	WolfSage	Note Edited: 0013485
2007-04-18 04:51	Shining Phoenix	Note Added: 0013496
2007-04-18 04:54	stskeeps	Relationship added	has duplicate 0003240
2007-04-18 04:59	stskeeps	Note Added: 0013501
2007-04-18 04:59	stskeeps	Status	new => acknowledged
2007-04-18 05:00	stskeeps	Relationship added	child of 0003049
2007-04-18 19:48	WolfSage	Note Added: 0013560
2007-04-18 22:40	Bricker	Note Added: 0013570
2007-04-27 13:13	stskeeps	Note Added: 0013892
2007-04-27 13:28	vonitsanet	Note Added: 0013893
2007-04-28 08:26	stskeeps	Note Added: 0013910
2007-05-04 08:36	stskeeps	Status	acknowledged => resolved
2007-05-04 08:36	stskeeps	Fixed in Version	=> 3.3-alpha0
2007-05-04 08:36	stskeeps	Resolution	open => fixed
2007-05-04 08:36	stskeeps	Assigned To	=> stskeeps
2007-05-04 08:36	stskeeps	Note Added: 0013998