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

  1. Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!sgiblab!spool.mu.edu!agate!usenet.ins.cwru.edu!po.CWRU.Edu!ekb2
  2. From: ekb2@po.CWRU.Edu (Ethan K. Butterfield)
  3. Newsgroups: alt.irc
  4. Subject: Re: Bots and Common Sense
  5. Date: 28 Jan 1993 02:59:53 GMT
  6. Organization: Case Western Reserve University, Cleveland, OH (USA)
  7. Lines: 152
  8. Message-ID: <1k7i79INNpmp@usenet.INS.CWRU.Edu>
  9. References: <1k75t7INNdgv@usenet.INS.CWRU.Edu> <C1IxIu.IFC@news.cso.uiuc.edu> <C16Iuq.DJH@news.cso.uiuc.edu> <1k5833INNoqd@usenet.INS.CWRU.Edu>
  10. Reply-To: ekb2@po.CWRU.Edu (Ethan K. Butterfield)
  11. NNTP-Posting-Host: thor.ins.cwru.edu
  12.  
  13.  
  14. >[IRC as more than chat service; some "good" bots]
  15. >>So do you want to turn IRC into a MUSH? Shaz, and Nickserv and all other useful
  16. >>bots should be improved and I have no problem with them at all, I even encourage
  17. >>people to write them.... all because they do things that the average user can
  18. >>not do by themselves...
  19. >
  20. >Actually that sounds cool.  A friend of mine has a theory that addiction to
  21. >MUDs, and addiction to IRC, is mutually exclusive.  But consider that no MUD
  22. >has more than about 300 users at a time, whereas I've seen IRC with 1300 plus.
  23. >No MUD (that I am aware of) takes advantage of the resources of more than
  24. >one computer, while IRC uses hundreds.  You could make one helluva MUD with
  25. >all that.
  26. >
  27. Thanks for mentioning me. Anyways, I would happily take part in a
  28. IRC/MUD environment. The only problem I see here, well actually two, are
  29. these:
  30.  
  31. 1) What happens when lots of people get into one room and start talking
  32. to each other. Like in normal IRC, you'll be flooded and may miss
  33. messages, have your terminal lock up, or not be able to have a
  34. conversation with that person you just met.
  35.  
  36. 2) How do you find people? Well, it's easy to program that in, but how
  37. do you get there? If you're in "Toronto", and your friend is in "China",
  38. and you have to traverse rooms to get there, how is it accomplished? The
  39. only thing i see is that you have to stay in a small area of rooms you
  40. know. Then you can find your friends, but it lessens your chance of
  41. contacting other people.
  42.  
  43. >>[stuff on owning channels]
  44. >>I will grant you this for established channels... however, usually at least
  45. >>one ircop is on #hot*, so the offender better watch out...
  46. >
  47. >I wasn't thinking of #hot* -- no one owns those channels; they're both very
  48. >close to anarchy.  I'm thinking more along the lines of #sherwood.  Often
  49. >hovering around ten people or so, with a few old-timers (sometimes as old as
  50. >*three whole years*!  A long time in the fast-moving computer world), and lots
  51. >of semi-faithful visitors who can only get opped by a lot of major kissing-up.
  52. >It's pretty disgusting to watch.
  53. >
  54. Hmmmmm....personal vendetta? Well, you must remember Greg, that channel
  55. op is a privilege, not a right. I know just what you used ops for...I
  56. think the system of scaled channel ops could work. I'd like to see you
  57. program it, however...
  58.  
  59. >>[stuff on owning and registering nicks]
  60. >>Let them register from different accounts (possibly 2-5, unless they have hacked
  61. >>root somewhere...) This will still prevent nick duplication, although some
  62. >>users will have more possible nicks than others, but this is a small price to
  63. >>pay, in my opinion.
  64. >
  65. >What about those people who modify their clients to allow them to set their
  66. >own IRC username?  This will have to be prevented in some way.  ... Yes, I did
  67. >this myself.  I only had to change about twenty characters of the source code
  68. >to do it.  Did all sorts of fun and annoying things with that ability.  Nearly
  69. >lost my UNIX account as a result.  But if there is ever going to be any sort
  70. >of nickname registration, this sort of bug will have to be eliminated first.
  71. >     I realise that every time I admit publicly, on Usenet, that I've done
  72. >this or that, I've stuck my neck way out.  I only take that risk because it
  73. >shows what's wrong with the system.  We have to be aware of the obstacles to
  74. >be overcome, and that includes making the system much more waterproof.
  75. >
  76. Obviously, this would save a lot of time and stress, and would eliminate
  77. the impotent NickServ. NickServ is a good idea, with without the power
  78. to back it up, it's worthless. I have personally ignored the "This nick
  79. is registered to xxx" message repeatedly. Either this "register for
  80. access" idea, or possibly a KILL command in its programming.
  81.  
  82. >>[channel-reserving bots...]
  83. >>Emotions aside for a minute... An ircrc can act as a channel cop... it's
  84. >>quite easy to deop anyone who deops someone else or changes nicks or whatever...
  85. >>I admit that I don't like talking bots, but pubserv (from what you have said,
  86. >>I have never personally run into that bot) sounds more like channel atmosphere..
  87. >>As long as it's not annoying, I'll put up with bots...
  88. >
  89. >One thing a bot can do that (most) human users cannot, is be on the system 24
  90. >hours a day.  That allows people to log in from anywhere, at odd hours, and
  91. >hold conversations and read postings, etc.
  92. >
  93. The arguments are good for both sides...I guess if you really WANT a
  94. certain channel name, you could install a do-nothing bot to hold it
  95. open, or closed for that matter. It's real easy to program it to make
  96. the channel +pstin, and have it auto-invite you when you get on. Also,
  97. program an auto-deop so that people can't hack ops. Aside from that, a
  98. really worked .ircrc file is still as good as a bot. The problem I see
  99. is that you don't have that added level of "defense" that a bot gives
  100. you. I think it was brought up earlier that if you get kicked, join a
  101. new channel and ban the person. That works.
  102.  
  103. >>[the inevitability of mode wars; how could they be accomodated]
  104. >>This sounds like quite a good idea to me. Sorry, no ideas here... You have a 
  105. >>very good point about granting and revoking power. Maybe a new type of op
  106. >>status should be used....
  107. >
  108. >Someone once suggested that when you op someone on a channel, you should lose
  109. >your own op status.  Not a bad start--a problem arises if someone leaves a
  110. >channel without opping anyone else.  Perhaps the person who forms a channel
  111. >would have a higher level of op status, the channel owner.  The channel might
  112. >then be branded with his/her username and host, so that it would still be
  113. >theirs if they came back later (eliminating the need for a bot to reserve it).
  114. >A minor "channel controller" status could be passed out by the owner, and then
  115. >distributed or not the way chops are now.  For this to work, the channel would
  116. >need to stay in existence even when empty--that might lead to the registration
  117. >of channels, just like for nicks.  Hey, I'm just thinking out loud, I know
  118. >this idea is just half-baked, but there is definitely some potential here.
  119. >Maybe we could cut down on mode changes, instead of demanding that the server
  120. >handle the large load being dished out with this system.
  121. >
  122. Mode wars are a hideous waste of bandwidth, but there are those people
  123. out there that just get on IRC to "flex their muscles", and show just
  124. how much of a stud they really are. There's nothing you can do about
  125. that; it's human nature. Maybe set aside two or three designated "Mode
  126. Wars" channels, just like the #hot___ channels are sort of now.
  127.  
  128. >>[ircrcs and bots and aliases and modules]
  129. >>why duplicate a command? anyway, most bot users (95%) don't use /load commands
  130. >>(the number is a guess, but probably close to the mark)
  131. >
  132. >Then they're not very bright, programming-wise, or are just copying someone
  133. >else's old code--either way I don't want to hear about it.  I don't respect
  134. >such people, and it's a shame that they are taken as representative of bot
  135. >programmers.
  136. >
  137. Again, bots really aren't needed if you've got a good .ircrc file. I
  138. came up with a sort of comparison: There are bots, and users, but
  139. someone with a .ircrc file that acts like a bot, but still is a human
  140. controller (sort of like augmented reflexes. See where I'm headed?), is
  141. like a cyborg. Human mind, computer reflexes. The ON command is powerful
  142. enough to allow this. That's the way I'm set up.
  143.  
  144. >
  145. >>Scott Andrew McMillan             University of Illinois at Urbana-Champaign
  146. >>socket@uiuc.edu        "Fighting for peace is like fornicating for chastity"
  147. >>smcmilla@ux4.cso.uiuc.edu            What about my ontological predicates???
  148. >
  149. >                                        Greg Meyers
  150. >                                        Lord_Max
  151. >                                        meyers@alpha.ces.cwru.edu
  152. >
  153. Just thought I'd add my two cents. I like IRC as a way to meet people. I
  154. got over the "My term is better than yours!!!" long ago. Till we meet in
  155. cyberspace.
  156.  
  157. I am Primus_I. Just thought you'd like to know that.
  158.  
  159.  
  160. -- 
  161. Ethan K. Butterfield, Pope of the Holy Discordian Church of Anarcho-
  162. Metaphysics, Order of the Salmon Reich.    Hail Eris!!!
  163. "I tell you: One must still have Chaos in order to give birth
  164.  to a dancing star!"  -Nietzsche
  165.