home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / alt / irc / 4625 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  5.2 KB

  1. Path: sparky!uunet!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu
  2. From: dougmc@ccwf.cc.utexas.edu (Doug McLaren)
  3. Newsgroups: alt.irc
  4. Subject: Re: yes or no? (bot deopping)
  5. Message-ID: <85220@ut-emx.uucp>
  6. Date: 13 Dec 92 01:09:08 GMT
  7. References: <1fgmksINNjhu@manuel.anu.edu.au> <19NOV199219244875@rigel.tamu.edu> <1g5lmrINNh0k@usenet.INS.CWRU.Edu>
  8. Sender: news@ut-emx.uucp
  9. Organization: Doug's House of Disco
  10. Lines: 96
  11.  
  12. In article <1g5lmrINNh0k@usenet.INS.CWRU.Edu> gjm5@po.CWRU.Edu (Lord Maximilien of Myragorthia) writes:
  13.  
  14. >Actually the problem is even worse than that.  You don't need to have two
  15. >bots attacking each other to see this server-disalignment effect.  If you
  16. >have a bot with a command like this:
  17. >
  18. >     /on mode "* -o MyOwner" kick TheirNick
  19. >
  20. >and someone on a far-off server executes some sort of nuke command that
  21. >deops everyone on the channel one at a time (a poor way to write one, but
  22. >easier to do in IRC script so often employed anyway), the bot will in fact
  23. >respond, and havoc can result.  Consider what happens if the mass deoper's
  24. ...
  25. { we get the idea }
  26.  
  27.  
  28. This is an old problem, one that came to fore with the advent of the 2.7
  29. servers and the *** Hack: message.  The problem was still there before this,
  30. but wasn't advertised to everybody and their dog.
  31.  
  32. Personally, I think it's time for the *** Hack: message to go the way of the
  33. numbered channels ...
  34.  
  35. But it doesn't take a stupid bot that protects his owner to cause this.  I
  36. see it alot w/ the mass kick/deop protection scripts I've written (which, btw,
  37. I give out to anybody who wants them ...)  Baasically, if somebody sends X
  38. kicks or deops in a row (X = usually 3 to 5) you kick them.  The mass kicker
  39. sometimes ends up being the only op on his server, and not even on the channel
  40. on the rest of the net.  (Of course, they generate hack messages like mad, and
  41. some self-rightous IRCop tends to kill them ... :)
  42.  
  43. That is a problem.  Personally, I think it's better than letting them SUCCEED
  44. in their mass deop, so I continue to give out my mass deop/kick protection
  45. scripts, and suggest that people add it to their .ircrc files and their bots.
  46.  
  47. Having your bot kick anybody who deops or kicks you is an idea which has 
  48. become old.  If anybody pays attention, they will notice that my bots do NOT
  49. protect me or anybody else in this manner.  They DO include the mass kick
  50. protection, with X set to 5, which is generally discriminating enough to not
  51. kick anybody who really doesn't need it.  Yes, it does tend to cause hack
  52. messages (usually in the mass deopper) but I think that's better then letting
  53. them succeed.
  54.  
  55. A solution?  I see a few possible ones:
  56.  
  57.    1) One central server handles modes.   (Will never work.  Not only would
  58.       it be slow, but how would people even  choose WHO gets to run this
  59.       server, and what if it goes down ...)
  60.    2) Do away with the *** Hack message.  This is a good idea IMHO, whos
  61.       time has come.  It won't fix the problem, but will make it MUCH less
  62.       annoying ...
  63.    3) Do away with mode changes.  Personally, I think this is the best
  64.       solution, but it's really up to the people who do the coding ...
  65.       A slightly less drastic solution would be to do away with the 'o' and the
  66.       'b' modes (and 'm' would have to go too ...)  Then anybody on the channel
  67.       would be considered 'opped'.
  68.       Kick would seem to be a good thing to get rid of too.  But it serves it's
  69.       purpose too.
  70.  
  71. My proposal:
  72.  
  73.    No bans.  No opping people.  +i, s, t, n, p all still in effect, able to
  74.    be changed by anybody on the channel.
  75.    Anybody on the channel can 'kick', but all the kick will do is do a
  76.    server-level ignore on that person.  So I kick you, and it keeps ME
  77.    and only ME from seeing you.  Perhaps if 1/2 or more of the people on
  78.    the channel kick a single person it ought to become 'real' ...
  79.       
  80.    As far as IRCops go: No '*' ... let it be silent/invisible.  That '*' was
  81.    supposed to be there so people would know who to ask for help, but that
  82.    purpose is way out of date, because, as a group, IRCops aren't generally
  83.    much more help than the other lusers.
  84.    Leave /kill in, as it DOES have it's uses.  But make it kill yourself
  85.    too, so people will only use it when it's really needed.  Also, add a
  86.    K-line for 60 seconds on anybody killed, both the killer and the kilee.
  87.    This will make it a bit more inconvienient to kill and be killed.
  88.  
  89. These changes would do several things:  
  90.    1) reduce the bandwidth used by IRC.  (fewer mode changes ...)
  91.    2) Reduce the need/desire for bots (sure, they could have a few uses,
  92.       but these uses would be greatly reduced.)
  93.    3) Reduce the number of kills.
  94.    4) Reduce the 'power' of the IRCop, but still retain the /kill command.
  95.       This would also greatly reduce people's desire to start up their own
  96.       server just so they could /kill and so they could have that nifty
  97.       little '*' next to their name.
  98.  
  99. I don't promise that these ideas are perfect, or foolproof, or a panacea for
  100. IRC.  But they strike me as something to consider ...
  101.  
  102. -- 
  103. ----------------------- \  Zippy says:
  104. Doug McLaren,            \  I'm having an EMOTIONAL OUTBURST!! But, uh, WHY is
  105. DemoN on IRC              \  there a WAFFLE in my PAJAMA POCKET??
  106. dougmc@ccwf.cc.utexas.edu  \
  107. -------------------------- /
  108.