View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002352 | unreal | ircd | public | 2005-02-19 08:25 | 2005-02-25 15:18 |
| Reporter | Int21h | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Summary | 0002352: Two suggestions for future versions | ||||
| Description | Well, I have not found a better place where to post that, so if it botters you, just move it to a better place. I've been thinking and maybe implementing my idea would be useful for next versions of Unreal. I've thought that: It would be good allowing IRC Operators to set any usermode on any user, so for example if an oper activates +I usermode on someone, and it does not match anything for Unreal, this user would get a special info, for example on whois it would be appear: User is Infected with some trojan, be careful. Or for example, if an oper activates usermode +S on someone, on a whois it would appear: User has his nickname Suspended. The .conf format would be something like: usermode { mode <theusermode>; swhois <theextrainfo>; }; usermode { mode "R"; swhois "only allows QUERY messages from registered users"; }; usermode { mode "S"; swhois "has his nickname Suspended."; }; I don't know if u see this like an useless idea, but this maybe would help a very big number of netadmins :) And another suggestion.. I think it would be better if someone could only activate +R mode if previously he/she had activated +r mode. I think it's absurd if someone wants only private messages from registered users when himself has not registered his nickname. So, that's all for now. CY. | ||||
| 3rd party modules | |||||
|
|
@modes/swhois: nah.. I don't think so. @+R: well, perhaps someone has a good reason to do so? like if I go to the unreal network and - imagine - I don't have my nick registered, I could set myself +R to get rid of any idiots msging me with 'HELP MEEEE', and since all official helpers and most likely regulars as well would have their nick registered they would still be able to msg me. Just as an example. |
|
|
Hmm, are you sure the modes/swhois would be completely uselless? :))))))) I don't know what think other ppl, but I've commented that to many ppl and told me it would be a good idea.. but of course you decide :) |
|
|
SWhois already exists for this purpose. Use that. |
|
|
[quote]I don't know what think other ppl, but I've commented that to many ppl and told me it would be a good idea.. but of course you decide :)[/quote] You're looking at it from a completely functional perspective. You're not thinking about how this would be implemented: 1.) Unreal has a hard limit of 32 user modes (that's a simple limitation of 32bit architectures). If you count, Unreal already has 27 user modes. This would give you the ability to add 5 modes at most. 2.) It creates conflicts with future versions. What happens when we add a mode with that letter? As an example, you said +S. Well Unreal already has a +S usermode, it is the "is a Network Service" mode. So now what happens? NickServ is +S and suddenly Unreal is saying it has a suspended nickname! Conflicts will result if we ever add a mode that has the same letter you are already using. 3.) What happens, using your example, if I were +RS? Would it show two swhois lines for me? Or would it just pick one? If it just picks one, then it defeats the whole purpose of this idea. If it uses more than one, it requires the entire swhois system to be redesigned (and it would use more memory btw), and it would probably also break many services programs that currently use the SWHOIS command. 4.) Your examples make no sense. Why would I want to notify someone that I am +R? All that does is make /whois a spammers best friend! I do a /whois before spamming people to see if they are +R. If they are +R, I don't waste my time. And for your +S idea, what reason does a normal user ever have to know whether someone is using a suspended nickname? I really see no point in adding this. It would require a great deal of changes to the way Unreal works, and I see very little if any utility for it. |
|
|
[quote]1.) Unreal has a hard limit of 32 user modes (that's a simple limitation of 32bit architectures). If you count, Unreal already has 27 user modes. This would give you the ability to add 5 modes at most.[/quote] Thank goodness for that! I don't think I need to name names but I do think there are such things as "too many usermodes"! It most certainly is a problem when you have to use digits and symbols for usermodes! (Again, not naming names here... :P ) [quote]3.) What happens, using your example, if I were +RS? Would it show two swhois lines for me? Or would it just pick one? If it just picks one, then it defeats the whole purpose of this idea. If it uses more than one, it requires the entire swhois system to be redesigned (and it would use more memory btw), and it would probably also break many services programs that currently use the SWHOIS command.[/quote] Well, I don't think you have to use the same swhois stuff... I mean, unreal already sends some whois lines based solely on usermodes. For example, 307 (+r), 313 (to a point, text is dependant on highest of +OoSCAaN, and of course +H hides it), 310 (+h - but also dependant on /away and +H), and 335 (+B) are already sent based on usermodes. Also, a second 320 numeric (which is the SWHOIS numeric) is sent when the user has +z. I suppose all this would really need is test for whatever mode and send the 320 with the approriate text pulled straight from the conf. Knowing this though, it should be super-easy to code this as a module if you really want it that badly :P . [quote]4.) Your examples make no sense. Why would I want to notify someone that I am +R? All that does is make /whois a spammers best friend! I do a /whois before spamming people to see if they are +R. If they are +R, I don't waste my time. And for your +S idea, what reason does a normal user ever have to know whether someone is using a suspended nickname?[/quote] Actually it doesn't make things any easier. If anything I'd think it makes it harder! In the time it takes me to /whois someone to see if they're +R I could've just sent the spam and move on :P . Instead of just sending one message (whatever spam) per user, I have to send one message per user (the /whois) plus an extra message (the spam) for those that are -R... |
|
|
Well... 2) The S mode was only an example, of course I meant a mode that does not mean anything, for example the L mode. 3) My idea was that if you activate +RL modes, there would be a line for each of these modes, but I see that it's too difficult to do... 4) I don't know how is it in other countries, but for example here most of scripts when you open a query to a user, automatically does an whois and shows it at the active window, so in the query. I realized that so much ppl totally ignore the status window, so it would avoid messages like, "heeeey", "why are you ignoring me??", "answer please"... And in my opinion it wouldn't make the spammer's best friend at all, simply if he/she does a whois, he'll see that the user has the +R activated, but will continue making spam and the result is the same, just with the difference that maybe he won't make you a query. I didn't know that making that would be so hard, it was just an idea. I see a lot of utilities for that, but as I've already told, you decide.. :) Thanks anyway. |
|
|
[quote]I suppose all this would really need is test for whatever mode and send the 320 with the approriate text pulled straight from the conf.[/quote] But this assumes that every server will have the same usermode blocks. Otherwise, it would require a synching system like SWHOIS. Also, since you mentioned the +z notice, you should also be aware that we are changing SSL to NOT use 320 because the idea of using a single numeric for two completely different purposes like that is flawed. [quote]2) The S mode was only an example, of course I meant a mode that does not mean anything, for example the L mode.[/quote] You completely missed my point. What happens when we then add a +L to Unreal? My point is, if we add a new usermode, it might conflict with a user's usermode blocks. |
|
|
[quote]You completely missed my point. What happens when we then add a +L to Unreal? My point is, if we add a new usermode, it might conflict with a user's usermode blocks.[/quote] Would there exist a conflict althought the usermode meant only a info line in the whois? If you say that there're 5 free user modes at most, one possibility would be using them, but maybe it wouldn't be a good idea, because there are many better ways of using these modes, and probably you'll plan something for next versions. In fact introducing that module would make more problems: for example, a user with suspended nick would not be able to set -L himself, or an infected user (following my example in the first post) wouldn't be able to set -I himself... |
|
|
Just call me the devil's advocate. I can (sort) of see a use for this, in a direction I'm currently considering for the (probably far) future for WinSE. IE: marking users as abusive. (That is, "you have one more chance...") so an oper goes /whois blarp and gets a "is abusive: comment here" or something similar, and then knows to kill the bastard if he does something wrong again. Just idle thinking. But as you said, it's really not going to work with the whole 32bit thing :/ |
|
|
[quote]I can (sort) of see a use for this, in a direction I'm currently considering for the (probably far) future for WinSE. IE: marking users as abusive. (That is, "you have one more chance...") so an oper goes /whois blarp and gets a "is abusive: comment here" or something similar, and then knows to kill the bastard if he does something wrong again.[/quote] Well the thing is, if the point of it is mainly for services, then why not have services manage it? Meaning, /ns info shows it rather than /whois. |
|
|
Our five modes... What about usermodes added by modules? What then, if there are no mode spaces left? As for your suspended modes: What about the inability of opers to (without services raw) set other users modes? And would it only say suspended? What good is that when they can still do whatever they want? BTW: My Opinion: Bad Bad idea. Set a bot to services RAW SWHOIS if you really need it, or make a module. |
|
|
*nod* I agree with codemastr there that if services maintain such a thing (like 'last warning' etc), why not view it trough services... You could even make it like a criminal record *g*. As for informative whois info (that non-opers can see), you can use SWHOIS. And I doubt users would like many more lines in whois than you have now. Rather I think they will find it realllly annoying (just like I do) :P. Actually I think a similar idea like this was present earlier, but that was more like 'tagging' ('looks like a drone'), that one got closed because we could not be convinced that it would be worth the effort/etc. |
|
|
Good point, I was just suggesting another potential reason :P (I've actually made an alias /swhois because I want to /whois as well as /ns info ;D) |
|
|
[quote]And I doubt users would like many more lines in whois than you have now. Rather I think they will find it realllly annoying (just like I do) :P.[/quote] I also know that client coders get very pissed at it. Some clients are trying to do client-side translations. Most numerics have static text, therefore they are translating it and showing it in the user's language. However, when we have things like SWHOIS which have dynamic text, this becomes impossible. Expanding the system to show more information will just make them even more annoyed. |
|
|
Hm, maybe it would be better adding this to some services instead of Unreal. It would make it easier to configure, and would automatize some processes like for example: a suspended user connects, operserv would automatically set a swhois on him telling that he's suspended, or an user changes his nickname to a suspended one, etc; and no mode is needed. Also syzop's idea of the "criminal record" would be nice.. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-02-19 08:25 | Int21h | New Issue | |
| 2005-02-19 09:49 | syzop | Note Added: 0009174 | |
| 2005-02-19 12:55 | Int21h | Note Added: 0009176 | |
| 2005-02-19 14:00 | aquanight | Note Added: 0009180 | |
| 2005-02-20 21:41 |
|
Note Added: 0009209 | |
| 2005-02-21 03:30 | aquanight | Note Added: 0009212 | |
| 2005-02-21 03:33 | aquanight | Note Edited: 0009212 | |
| 2005-02-21 11:35 | Int21h | Note Added: 0009216 | |
| 2005-02-21 11:43 |
|
Note Added: 0009217 | |
| 2005-02-21 15:35 | Int21h | Note Added: 0009224 | |
| 2005-02-23 04:06 | w00t | Note Added: 0009262 | |
| 2005-02-23 21:25 |
|
Note Added: 0009272 | |
| 2005-02-24 18:01 | JasonTik | Note Added: 0009281 | |
| 2005-02-24 18:04 | syzop | Note Added: 0009282 | |
| 2005-02-24 18:05 | syzop | Note Edited: 0009282 | |
| 2005-02-24 23:21 | w00t | Note Added: 0009288 | |
| 2005-02-25 00:04 |
|
Note Added: 0009294 | |
| 2005-02-25 12:32 | Int21h | Note Added: 0009307 | |
| 2005-02-25 15:18 | syzop | Status | new => closed |
