software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2004/003070.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices Coding] 5.0.36 and Unreal
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%205.0.36%20and%20Unreal&In-Reply-To=4105074a.24411%40achurch.org">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="003069.html">
  11    <LINK REL="Next"  HREF="003071.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices Coding] 5.0.36 and Unreal</H1>
  15     <B>Aragon Gouveia</B>
  16     <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%205.0.36%20and%20Unreal&In-Reply-To=4105074a.24411%40achurch.org"
  17        TITLE="[IRCServices Coding] 5.0.36 and Unreal">aragon at phat.za.net
  18        </A><BR>
  19     <I>Mon Jul 26 07:23:43 PDT 2004</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="003069.html">[IRCServices Coding] 5.0.36 and Unreal
  22 </A></li>
  23         <LI>Next message: <A HREF="003071.html">[IRCServices Coding] 5.0.36 and Unreal
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#3070">[ date ]</a>
  27               <a href="thread.html#3070">[ thread ]</a>
  28               <a href="subject.html#3070">[ subject ]</a>
  29               <a href="author.html#3070">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>|<i> By Andrew Church &lt;<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org</A>&gt;
  35 </I>|<i>                                          [ 2004-07-26 15:31 +0200 ]
  36 </I>&gt;<i>      Actually, what would be best from my perspective is if someone--or
  37 </I>&gt;<i> even better, several someones--made their own hacks to Services on their
  38 </I>&gt;<i> own network to do what they thought was the &quot;right thing&quot;, and some sort of
  39 </I>&gt;<i> consensus arose from there.  (I often look to Services derivatives for
  40 </I>&gt;<i> ideas as well; is anyone aware of a Services-like program that does use the
  41 </I>&gt;<i> channel owner mode, and if so, how does it use the mode?)
  42 </I>
  43 I don't know of anything apart from the IRCd itself.
  44
  45
  46 &gt;<i>      I think a lot of the problem is that chanowner and protected (+a)
  47 </I>&gt;<i> overlap too much--there isn't anything a chanowner can _do_ other than not
  48 </I>&gt;<i> get de-ownered(?) by +a users, and maybe set a couple of modes that could
  49 </I>&gt;<i> be just as easily handled by SET MLOCK.  At the moment it's just an
  50 </I>&gt;<i> extraneous, unnecessary privilege level, and I think that's what's causing
  51 </I>&gt;<i> a lot of the confusion.
  52 </I>
  53 Yea, that's right.
  54
  55 Current Unreal protocol dictates that
  56    channel owners (+q) can:
  57         Set the channel +u
  58         Set the channel +L
  59         Set a channel user +a
  60         Set a channel user +q
  61         Set all other channel modes normal chanops can set
  62         Kick anyone in the channel
  63         NOT be kicked by anyone but another owner
  64         NOT be deopped by anyone but another owner
  65         NOT be de-q'd by anyone but another owner
  66         NOT be de-a'd by anyone but another owner
  67
  68    channel admins (+a) can:
  69         Set the same channel modes normal chanops can set
  70         NOT be kicked by anyone but an owner
  71         NOT be deopped by anyone but an owner
  72         NOT be de-a'd by anyone but an owner
  73         NOT kick other channel admins
  74         NOT deop other channel admins
  75         NOT de-a other channel admins
  76
  77
  78 The confusion for me is this:
  79
  80 -ChanServ-     PROTECT    Give a user protected status (+a)
  81 -ChanServ-     DEPROTECT  Remove protected status (+a)
  82
  83 The (DE)PROTECT commands are labelled as being capable of adding/removing
  84 +a status.  However, the DEPROTECT command will remove +a and +q.
  85 Additionally, channel admin status is essentially just a chanop status
  86 providing kick/deop protection.  Channel ownership is more than that, which
  87 is why I think DEPROTECT should not have the ability of removing that
  88 status.  IMHO that control should be reserved for the ChanServ
  89 FOUNDER, SUCCESSOR, and holder(s) of the founder password.
  90
  91 I suspect I'm the only one with this opinion.  In which case, no worries..
  92 will mod the source.  I originally posted thinking it'd be a simple bug
  93 report. :)
  94
  95
  96 Regards,
  97 Aragon
  98
  99
 100 </PRE>
 101
 102 <!--endarticle-->
 103     <HR>
 104     <P><UL>
 105         <!--threads-->
 106         <LI>Previous message: <A HREF="003069.html">[IRCServices Coding] 5.0.36 and Unreal
 107 </A></li>
 108         <LI>Next message: <A HREF="003071.html">[IRCServices Coding] 5.0.36 and Unreal
 109 </A></li>
 110          <LI> <B>Messages sorted by:</B>
 111               <a href="date.html#3070">[ date ]</a>
 112               <a href="thread.html#3070">[ thread ]</a>
 113               <a href="subject.html#3070">[ subject ]</a>
 114               <a href="author.html#3070">[ author ]</a>
 115          </LI>
 116        </UL>
 117
 118 </body></html>