projects / irc.git / blame
| Commit | Line | Data |
|---|---|---|
| 3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
| 2 | <HTML> | |
| 3 | <HEAD> | |
| 4 | <TITLE> [IRCServices] IRC Services 5.1 Features | |
| 5 | </TITLE> | |
| 6 | <LINK REL="Index" HREF="index.html" > | |
| 7 | <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20IRC%20Services%20%205.1%20Features&In-Reply-To=200471516537.076693%40MARVIN"> | |
| 8 | <META NAME="robots" CONTENT="index,nofollow"> | |
| 9 | <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> | |
| 10 | <LINK REL="Previous" HREF="004525.html"> | |
| 11 | <LINK REL="Next" HREF="004528.html"> | |
| 12 | </HEAD> | |
| 13 | <BODY BGCOLOR="#ffffff"> | |
| 14 | <H1>[IRCServices] IRC Services 5.1 Features</H1> | |
| 15 | <B>BrightSide</B> | |
| 16 | <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20IRC%20Services%20%205.1%20Features&In-Reply-To=200471516537.076693%40MARVIN" | |
| 17 | TITLE="[IRCServices] IRC Services 5.1 Features">brightside at quasinet.org | |
| 18 | </A><BR> | |
| 19 | <I>Fri Jul 16 06:59:55 PDT 2004</I> | |
| 20 | <P><UL> | |
| 21 | <LI>Previous message: <A HREF="004525.html">[IRCServices] Nick Enforcer Holding Problem | |
| 22 | </A></li> | |
| 23 | <LI>Next message: <A HREF="004528.html">[IRCServices] noop feature | |
| 24 | </A></li> | |
| 25 | <LI> <B>Messages sorted by:</B> | |
| 26 | <a href="date.html#4521">[ date ]</a> | |
| 27 | <a href="thread.html#4521">[ thread ]</a> | |
| 28 | <a href="subject.html#4521">[ subject ]</a> | |
| 29 | <a href="author.html#4521">[ author ]</a> | |
| 30 | </LI> | |
| 31 | </UL> | |
| 32 | <HR> | |
| 33 | <!--beginarticle--> | |
| 34 | <PRE>><i> Noted.  (No promises, though... maaaybe if you get enough people | |
| 35 | </I>><i> to  pester me ;) ) | |
| 36 | </I> | |
| 37 | pester, pester, pester! :) | |
| 38 | ||
| 39 | But on a more serious note: if it will be any help, I'll be more | |
| 40 | than happy to share my hacked Bahamut protocol module which I'm | |
| 41 | currently using for Ultimate3. (Running on irc.quasinet.org for | |
| 42 | anyone who got some idle time and wanting to see it in action) | |
| 43 | ||
| 44 | ><i> I admit handling of the channel admin/owner mode was only added | |
| 45 | </I>><i> in  as a "might as well use it" sort of thing.  I'm not sure I | |
| 46 | </I>><i> like the  idea of adding yet another ChanServ option, though.  As | |
| 47 | </I>><i> far as I  understand it (correct me if I'm wrong), channel owner | |
| 48 | </I>><i> mode is just  like protected (+a) except that it can't be unset | |
| 49 | </I>><i> by other +a  users; if that's the case, I'm not sure there's much | |
| 50 | </I>><i> reason to use  it at all--after all, ChanServ will always let the | |
| 51 | </I>><i> founder unban,  rejoin, and get +a back as needed.  (And | |
| 52 | </I>><i> internally, channel owner  mode support is a pain because | |
| 53 | </I>><i> different ircds use different mode  letters for it.) | |
| 54 | </I>><i> | |
| 55 | </I>><i> What would people think of just doing away with channel owner | |
| 56 | </I>><i> mode  support entirely? | |
| 57 | </I> | |
| 58 | I don't have any experience with other ircd's so I can't answer for | |
| 59 | them, but on Ultimate the +a is used in much the same way as halfop | |
| 60 | except that it is one step above chan-op instead of one step below. | |
| 61 | Channel-Admins can give and remove mode +a for other users, chanops | |
| 62 | can not. Chanops are also not able to kick admins out of the | |
| 63 | channel, in the same way that halfops are not allowed to kick | |
| 64 | chanops. When a new channel is created, the first user is given | |
| 65 | chanops status and for this reason it's necessary for services to | |
| 66 | be able to set this mode. There is no way normal users can set this | |
| 67 | themselves without requiring assistance from an ircoper. | |
| 68 | ||
| 69 | The reason I want this to be specifiable is because some users want | |
| 70 | to use this as a "founder only" mode, and some want to use it as a | |
| 71 | mode given to the founder and all co-founders (a.k.a SOPs). I have | |
| 72 | also seen some clients break because the mode is outside the | |
| 73 | RFC1459 spesifications, so I believe that some users might find it | |
| 74 | more annoying than helpful so they want to disable it completely, | |
| 75 | in other words make chanserv not set the mode at all. But these | |
| 76 | needs varies from channel to channel. | |
| 77 | ||
| 78 | ><i> Channel memos is one thing I've been meaning to revisit for a   | |
| 79 | </I>><i> while; thanks for reminding me.  The channel memo system is a | |
| 80 | </I>><i> major  hack as is, with no notification or anything else that can | |
| 81 | </I>><i> be done  for nicknames.  So let me pose a question:  What would | |
| 82 | </I>><i> you (anyone  feel free to reply) want to use channel memos for?   | |
| 83 | </I>><i> In what cases  would you want to send a memo to a channel, and | |
| 84 | </I>><i> who would you want  to read the memo?  I've got a few redesign | |
| 85 | </I>><i> possibilities in mind,  but to avoid leading questions, I won't | |
| 86 | </I>><i> mention them right now;  just assume channel memos could do | |
| 87 | </I>><i> anything you want, and tell me  what you'd want them to do. | |
| 88 | </I>><i> | |
| 89 | </I> | |
| 90 | I see channel memos as a simple way of informing all operators of a | |
| 91 | channel about channel events without requiring them to be online. | |
| 92 | This could be messages informing them of new operators, channel | |
| 93 | guildelines etc. etc. It's an easy way to reach everyone at the | |
| 94 | same time so you can be sure they got the message, and there's no | |
| 95 | need for channel-users to create their own mailinglist or a forum | |
| 96 | board. From my own experience, I have found this very handy in | |
| 97 | channels with users from all over the world, as it's impossible to | |
| 98 | reach everyone at the same time because of timezones :)I see | |
| 99 | channel memos as a simple way of informing all operators of a | |
| 100 | channel about channel events without requiring them to be online. | |
| 101 | This could be messages informing them of new operators, channel | |
| 102 | guildelines etc. etc. It's an easy way to reach everyone at the | |
| 103 | same time so you can be sure they got the message, and there's no | |
| 104 | need for channel-users to create their own mailinglist or a forum | |
| 105 | board. From my own experience, I have found this very useful in | |
| 106 | channels with users from all over the world, as it's impossible to | |
| 107 | reach everyone at the same time because of timezones :) | |
| 108 | ||
| 109 | Also, a final wish: | |
| 110 | ||
| 111 | 3) I've noticed there are a callback for "receive message" to | |
| 112 | capture all messages sent from a server to services but I have not | |
| 113 | yet found any way to capture all messages sent from services to a | |
| 114 | server. It would be useful to support server-to-server compression | |
| 115 | and encryption. | |
| 116 | ||
| 117 | -BrightSide- | |
| 118 | ||
| 119 | ||
| 120 | ||
| 121 | ||
| 122 | ||
| 123 | </PRE> | |
| 124 | ||
| 125 | <!--endarticle--> | |
| 126 | <HR> | |
| 127 | <P><UL> | |
| 128 | <!--threads--> | |
| 129 | <LI>Previous message: <A HREF="004525.html">[IRCServices] Nick Enforcer Holding Problem | |
| 130 | </A></li> | |
| 131 | <LI>Next message: <A HREF="004528.html">[IRCServices] noop feature | |
| 132 | </A></li> | |
| 133 | <LI> <B>Messages sorted by:</B> | |
| 134 | <a href="date.html#4521">[ date ]</a> | |
| 135 | <a href="thread.html#4521">[ thread ]</a> | |
| 136 | <a href="subject.html#4521">[ subject ]</a> | |
| 137 | <a href="author.html#4521">[ author ]</a> | |
| 138 | </LI> | |
| 139 | </UL> | |
| 140 | ||
| 141 | </body></html> |