[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2007 / 003286.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [IRCServices Coding] Feature Suggestions
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Feature%20Suggestions&In-Reply-To=BAY115-F128D33FFCBF18F53D54FE381520%40phx.gbl">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="003285.html">
   <LINK REL="Next"  HREF="003287.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[IRCServices Coding] Feature Suggestions</H1>
    <B>Kieron Thwaites</B> 
    <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Feature%20Suggestions&In-Reply-To=BAY115-F128D33FFCBF18F53D54FE381520%40phx.gbl"
       TITLE="[IRCServices Coding] Feature Suggestions">ron2k.za at gmail.com
       </A><BR>
    <I>Mon Apr 16 03:27:12 PDT 2007</I>
    <P><UL>
        <LI>Previous message: <A HREF="003285.html">[IRCServices Coding] Feature Suggestions
</A></li>
        <LI>Next message: <A HREF="003287.html">[IRCServices Coding] Feature Suggestions
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#3286">[ date ]</a>
              <a href="thread.html#3286">[ thread ]</a>
              <a href="subject.html#3286">[ subject ]</a>
              <a href="author.html#3286">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>&gt;<i> 1. /ns set autoop [on|off] - Just like Anope
</I>
If this is what I think it is, which is that the nick in question
won't be auto-opped on any channel (next time please elaborate on what
Anope does), I believe that Andrew may have been considering this at
one point (I think it was in one of the TODO lists). That being said,
I haven't seen this in 5.1, so it may have been dropped or thrown out.

&gt;<i> 2. I think channel passwords suck, so:
</I>&gt;<i>
</I>&gt;<i> - Leave /cs register the same, but ignore the password field, like on
</I>&gt;<i> Surreal Services
</I>&gt;<i>
</I>&gt;<i> - Add an xOP level called QOP or CF or Co-Founder, access level 900 (not 999
</I>&gt;<i> please).
</I>&gt;<i>
</I>&gt;<i> - Only the &quot;true founder&quot; can set successor.
</I>&gt;<i>
</I>&gt;<i> - Remove /cs identify
</I>&gt;<i>
</I>&gt;<i> - /cs drop won't require the user to do /cs identify first
</I>&gt;<i>
</I>&gt;<i> - Add commands owner and deowner, and levels autoowner and owner
</I>&gt;<i>
</I>&gt;<i> - /cs deprotect will no longer set mode -q, it will do -a only
</I>
I was actually thinking of something like this a while back. I'll
leave it up to Andrew to make the final call on this one, but I
suggest a few more things: firstly, regarding the &quot;only the 'true
founder' can set successor&quot; bit, go further - only the true founder
should be able to modify such a list in the first place. Secondly,
dropping a channel should always require a password, for security
reasons and to guard against accidental drops.

What I like about this method is that it reduces the possibility of
someone changing the &quot;true founder&quot; of a channel, as I assume that
users on a &quot;co-founder&quot; list wouldn't be given that permission.

As a sidenote, 5.1 has dropped support for the channel owner mode (+q
on UnrealIRCd for example); channel owners will be given the same
modes as those on the SOP list or access level &gt;= 100.

&gt;<i> 3. /cs clear #channel users - make this only kick users who don't have the
</I>&gt;<i> access to use it.
</I>
No opinion on this.

&gt;<i> 4. When someone sets a new founder for the channel, they immediately lose
</I>&gt;<i> their founder-level access.
</I>
Kind of stupid, as someone losing their founder-level access and
knowing the channel password could just identify using the channel
password and get founder-level access straight back. If the system
mentioned in your second point were to be implemented, then I could
see a use for this, but right now it makes no sense at all.

&gt;<i> 5. /ns listchans - make this list all of the user's channel accesses, like
</I>&gt;<i> /ns alist in Anope
</I>
If I understand you correctly, you want this to display the access
list for a channel as well. Services already does this. (/msg ChanServ
ACCESS #channel LIST - or something like that)

&gt;<i> 6. When someone does /cs info #channel, and it shows the mode lock, make it
</I>&gt;<i> show the locked mode paramaters too.
</I>
Bad idea. I'm sure that no-one wants to see their channel key
displayed in this manner. :)

--K
</PRE>


<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="003285.html">[IRCServices Coding] Feature Suggestions
</A></li>
	<LI>Next message: <A HREF="003287.html">[IRCServices Coding] Feature Suggestions
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#3286">[ date ]</a>
              <a href="thread.html#3286">[ thread ]</a>
              <a href="subject.html#3286">[ subject ]</a>
              <a href="author.html#3286">[ author ]</a>
         </LI>
       </UL>

</body></html>
Commit	Line	Data
3bd189cb JR	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
	2	<HTML>
	3	<HEAD>
	4	<TITLE> [IRCServices Coding] Feature Suggestions
	5	</TITLE>
	6	<LINK REL="Index" HREF="index.html" >
	7	<LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Feature%20Suggestions&In-Reply-To=BAY115-F128D33FFCBF18F53D54FE381520%40phx.gbl">
	8	<META NAME="robots" CONTENT="index,nofollow">
	9	<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
	10	<LINK REL="Previous" HREF="003285.html">
	11	<LINK REL="Next" HREF="003287.html">
	12	</HEAD>
	13	<BODY BGCOLOR="#ffffff">
	14	<H1>[IRCServices Coding] Feature Suggestions</H1>
	15	<B>Kieron Thwaites</B>
	16	<A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Feature%20Suggestions&In-Reply-To=BAY115-F128D33FFCBF18F53D54FE381520%40phx.gbl"
	17	TITLE="[IRCServices Coding] Feature Suggestions">ron2k.za at gmail.com
	18	</A><BR>
	19	<I>Mon Apr 16 03:27:12 PDT 2007</I>
	20	<P><UL>
	21	<LI>Previous message: <A HREF="003285.html">[IRCServices Coding] Feature Suggestions
	22	</A></li>
	23	<LI>Next message: <A HREF="003287.html">[IRCServices Coding] Feature Suggestions
	24	</A></li>
	25	<LI> <B>Messages sorted by:</B>
	26	<a href="date.html#3286">[ date ]</a>
	27	<a href="thread.html#3286">[ thread ]</a>
	28	<a href="subject.html#3286">[ subject ]</a>
	29	<a href="author.html#3286">[ author ]</a>
	30	</LI>
	31	</UL>
	32	<HR>
	33	<!--beginarticle-->
	34	<PRE>><i> 1. /ns set autoop [on\|off] - Just like Anope
	35	</I>
	36	If this is what I think it is, which is that the nick in question
	37	won't be auto-opped on any channel (next time please elaborate on what
	38	Anope does), I believe that Andrew may have been considering this at
	39	one point (I think it was in one of the TODO lists). That being said,
	40	I haven't seen this in 5.1, so it may have been dropped or thrown out.
	41
	42	><i> 2. I think channel passwords suck, so:
	43	</I>><i>
	44	</I>><i> - Leave /cs register the same, but ignore the password field, like on
	45	</I>><i> Surreal Services
	46	</I>><i>
	47	</I>><i> - Add an xOP level called QOP or CF or Co-Founder, access level 900 (not 999
	48	</I>><i> please).
	49	</I>><i>
	50	</I>><i> - Only the "true founder" can set successor.
	51	</I>><i>
	52	</I>><i> - Remove /cs identify
	53	</I>><i>
	54	</I>><i> - /cs drop won't require the user to do /cs identify first
	55	</I>><i>
	56	</I>><i> - Add commands owner and deowner, and levels autoowner and owner
	57	</I>><i>
	58	</I>><i> - /cs deprotect will no longer set mode -q, it will do -a only
	59	</I>
	60	I was actually thinking of something like this a while back. I'll
	61	leave it up to Andrew to make the final call on this one, but I
	62	suggest a few more things: firstly, regarding the "only the 'true
	63	founder' can set successor" bit, go further - only the true founder
	64	should be able to modify such a list in the first place. Secondly,
65	dropping a channel should always require a password, for security
66	reasons and to guard against accidental drops.
67
68	What I like about this method is that it reduces the possibility of
69	someone changing the "true founder" of a channel, as I assume that
70	users on a "co-founder" list wouldn't be given that permission.
71
72	As a sidenote, 5.1 has dropped support for the channel owner mode (+q
73	on UnrealIRCd for example); channel owners will be given the same
74	modes as those on the SOP list or access level >= 100.
75
76	><i> 3. /cs clear #channel users - make this only kick users who don't have the
77	</I>><i> access to use it.
78	</I>
79	No opinion on this.
80
81	><i> 4. When someone sets a new founder for the channel, they immediately lose
82	</I>><i> their founder-level access.
83	</I>
84	Kind of stupid, as someone losing their founder-level access and
85	knowing the channel password could just identify using the channel
86	password and get founder-level access straight back. If the system
87	mentioned in your second point were to be implemented, then I could
88	see a use for this, but right now it makes no sense at all.
89
90	><i> 5. /ns listchans - make this list all of the user's channel accesses, like
91	</I>><i> /ns alist in Anope
92	</I>
93	If I understand you correctly, you want this to display the access
94	list for a channel as well. Services already does this. (/msg ChanServ
95	ACCESS #channel LIST - or something like that)
96
97	><i> 6. When someone does /cs info #channel, and it shows the mode lock, make it
98	</I>><i> show the locked mode paramaters too.
99	</I>
100	Bad idea. I'm sure that no-one wants to see their channel key
101	displayed in this manner. :)
102
103	--K
104	</PRE>
105
106
107	<!--endarticle-->
108	<HR>
109	<P><UL>
110	<!--threads-->
111	<LI>Previous message: <A HREF="003285.html">[IRCServices Coding] Feature Suggestions
112	</A></li>
113	<LI>Next message: <A HREF="003287.html">[IRCServices Coding] Feature Suggestions
114	</A></li>
115	<LI> <B>Messages sorted by:</B>
116	<a href="date.html#3286">[ date ]</a>
117	<a href="thread.html#3286">[ thread ]</a>
118	<a href="subject.html#3286">[ subject ]</a>
119	<a href="author.html#3286">[ author ]</a>
120	</LI>
121	</UL>
122
123	</body></html>