home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / irc / 5106 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  8.5 KB

  1. Path: sparky!uunet!das.wang.com!ulowell!m2c!nic.umass.edu!caen!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!po.CWRU.Edu!gjm5
  2. From: gjm5@po.CWRU.Edu (Gregory J. Meyers)
  3. Newsgroups: alt.irc
  4. Subject: Re: Bots and Common Sense
  5. Message-ID: <1k5833INNoqd@usenet.INS.CWRU.Edu>
  6. Date: 27 Jan 93 05:54:42 GMT
  7. References: <C16Iuq.DJH@news.cso.uiuc.edu>
  8. Reply-To: gjm5@po.CWRU.Edu (Lord Maximilien of Myragorthia)
  9. Organization: Case Western Reserve University, Cleveland, OH (USA)
  10. Lines: 145
  11. NNTP-Posting-Host: slc5.ins.cwru.edu
  12.  
  13.  
  14. I'd like to post a reply to this one, because it's probably the most logical,
  15. intelligent, and above all, calm posting regarding bots that I've seen so far.
  16.  
  17.  
  18. In a previous article, smcmilla@ux4.cso.uiuc.edu (Scott A McMillan) says:
  19.  
  20. >Let's start with what IRC is: Internet Relay Chat. Okay, so the purpose of
  21. >IRC is to chat. I take that to mean to talk, to hold a conversation. From the
  22. >ardent supporters of vanity bots, I must be wrong...
  23.  
  24. IRC began as a chat service, but I don't see why it has to remain just that.
  25. When you connect up hundreds of computers around the globe, the possibilities
  26. are endless.  Almost none of these possibilities have been exploited yet.  I
  27. see NickServ, and Shaz (the GIF-distribution bot), and NCC-1701, and little
  28. else.  These bots all share a common feature: they interface a useful program
  29. with an easily understood network interface.  With more creativity we might
  30. see better netgames, some ongoing MUD-type environments.  The difference is,
  31. anyone with a little skill can write a bot, whereas starting a MUD and getting
  32. people to try it out is more difficult.
  33.  
  34. >Going on. Can people own channels? Nope. Why not? The number of channels is
  35. >potentially infinite. Any basic economics book will tell you that you can
  36. >only own something if there is a finite amount of it. In response to the
  37. >people who are plagued by people who join their channels and kick everyone
  38. >off or deop them or commit other IRC crimes... Create a new channel and
  39. >ban the offender and then invite everyone over... 
  40.  
  41. A possible exception is the case of old, well-known channels, where seniority
  42. gives priority over control.  The method you describe doesn't work on these
  43. channels, since everyone already knows the channel by its old name, and cross-
  44. overs are unlikely.  Apart from that, this is a compelling argument.
  45.  
  46. >Next. Can people own nicks? Yep. I know that I violate my previous argument,
  47. >but nicks are names, when it's all boiled down. And names just represent
  48. >people. ... [stuff deleted]
  49. >I personally believe that nickserv is doing a fine job right now...
  50.  
  51. I agree.  Perhaps we need something stronger than NickServ to reserve nick-
  52. names--say, some sort of user registration.  BBS's have this, so why not IRC?
  53. It would eliminate the problem of impersonating other users.  It would also
  54. probably require the deletion of the /nick command, but maybe it's worth it.
  55. The only problem I see is how to prevent users from registering twice, from
  56. two different hosts.
  57.  
  58. >Vanity bots... I'll admit that I have written a bot, and ran it for about
  59. >two days. Then I wrote an ircrc. For better or worse, bots are good as
  60. >sources for ircrc's. Bot's that just hold a channel are wastes of IRC
  61. >resources (for the reasons mentioned above.) Bots that op users are also
  62. >a waste.
  63.  
  64. Depends.  A well-written channel holding bot is a bit like a government in a
  65. tiny country.  If it performs valuable services, like keeping track of
  66. messages and maintaining the peace (rather than instigating wars), then it can
  67. provide a safe haven for regular users, and even enhance conversation.  I
  68. remember channel #pub not too long ago, and its bot #pubserv, which was a
  69. bartender of course.  All it could do was pour you a Coors.  But people on
  70. that channel talked as if they were really in a pub.  One guy came on the
  71. channel to tell us he'd just lost a friend.  Man, I sure needed that Coors
  72. right then.
  73.  
  74. >Let's go back to what IRC is: chat. I sure don't need an op to
  75. >chat. Some people sure think they do. Maybe if people didn't throw around
  76. >ops, they wouldn't get kicked off 'their own' channel. I personally auto-op
  77. >three people when they join (from an ircrc.) I know lots of people on 
  78. >IRC, but I op three. Point made? I refuse to join #hotsex and #hottub because
  79. >of the number of opings and deopings that just clutter the channel and 
  80. >interfear with talking, the supposed purpose of IRC.
  81.  
  82. No one joins those channels to talk.  They're way too clogged up with people
  83. for anything that laid-back.  People go on #hot* because they want to have
  84. mode wars--it's like a huge wrestling match, everyone jostling for position,
  85. and I often find it's fun to watch as well as to participate.  OK, I know it's
  86. wasteful of bandwidth.  This point has been made so many times, it's begun to
  87. lose its bite.  But when channels get as huge as those two, things can easily
  88. get volatile, and after a while a reputation builds up that perpetuates the
  89. situation.  Seems to me that whenever you give some users power over other
  90. users, along with the ability to grant or revoke that power, you're gonna
  91. have a little rivalry.
  92.      Instead of trying to stop it, how about finding ways to accomodate it?
  93. Perhaps if the system were organized differently, so that it weren't necessary
  94. to transmit mode commands to *every single server* on the system, there would
  95. be no more complaints.  How to do this, I'm not sure yet, but I'm working on
  96. it, just give me a couple minutes... *Grin*  I've suggested this before.  I'll
  97. keep thinking about this one until someone comes up with an idea, or proves to
  98. me why it's impossible.
  99.  
  100. >Let's see, what other reasons are there why someone would run a bot? To
  101. >keep people off of a channel? Use an ircrc. I can't stress it enough,
  102. >an ircrc can do everything a bot can do, but it is better. You don't have
  103. >to worry about the bot getting kicked off a channel or losing it's op.
  104. >The commands are shorter (eg. /msg botname op nickname vs. /op nickname, or 
  105. >even if you shorten the /msg botname with an alias, it's still /alias op
  106. >nickname) and easier to remember.
  107.  
  108. My bots are all written with various modules strung together.  My .ircrc and
  109. my bot scripts are both just series of /load commands, and the two share many
  110. of the same modules.  So I don't have to tell my bots to /op suchandsuch, I
  111. just do it myself.  But my bot could do it if I told it to, since it has the
  112. same alias.
  113.  
  114. >Plus, ircrcs are written from the ground
  115. >up, therefore the user gains some knowledge of IRC script. I know of bots
  116. >created by just changing the /nick at the top and the op list. Can't learn
  117. >much from that...
  118.  
  119. All my modules were written by myself only.  I think all bots should be
  120. written by their owners.  Otherwise you have no idea what you're getting into
  121. when you run a bot, and the dangers are numerous.  People who run bots written
  122. by others should be aware that the owner can turn around at any moment and
  123. use the bot to annihilate the owner's account.
  124.      I *did* add some neat programming techniques to my modules which someone
  125. else authored (public domain), but that's different.  I understood what I was
  126. doing, and wasn't copying lines of code directly.
  127.  
  128. [stuff deleted... basically restating earlier argument]
  129. >I hope that makes sense to most people. I do not believe that bots can ever
  130. >be banned from irc, so we have to put up with them. We SHOULD however, make
  131. >sure that they never flood and avoid loops. Hopefully, users will progress
  132. >from using bots (at least harmful ones) and become mature IRC users, and
  133. >not out to only op your friends and ban your enemies.
  134.  
  135. Since the client program has developed into an operating system all its own,
  136. the knowledge necessary to write a bot has diminished.  I applaud this,
  137. because I still feel bots could be used to foster creativity in a flexible
  138. environment.  But if the bot-writing feature of client programs goes away, it
  139. won't be all bad.  At least this will single out the *true* programmers, who
  140. will have no choice but to write their bots in C, Pascal, assembler, etc.
  141. Many of them already do.
  142.  
  143. >As far a `right' to have a bot, sure you can have your bot, just don't get
  144. >mad if I kick it off.... The roads goes both ways....
  145.  
  146. Fair's fair.
  147.  
  148. >socket
  149. >
  150. >-- 
  151. >Scott Andrew McMillan             University of Illinois at Urbana-Champaign
  152. >socket@uiuc.edu        "Fighting for peace is like fornicating for chastity"
  153. >smcmilla@ux4.cso.uiuc.edu            What about my ontological predicates???
  154.  
  155.                                         Greg Meyers
  156.                                         Lord_Max
  157.                                         meyers@alpha.ces.cwru.edu
  158.