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] IrcServices enforcing +R | |
| 5 | </TITLE> | |
| 6 | <LINK REL="Index" HREF="index.html" > | |
| 7 | <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20IrcServices%20enforcing%20%2BR&In-Reply-To=ce6d53600703290659x484fb79of7a1992b1c02302b%40mail.gmail.com"> | |
| 8 | <META NAME="robots" CONTENT="index,nofollow"> | |
| 9 | <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> | |
| 10 | <LINK REL="Previous" HREF="005243.html"> | |
| 11 | <LINK REL="Next" HREF="005245.html"> | |
| 12 | </HEAD> | |
| 13 | <BODY BGCOLOR="#ffffff"> | |
| 14 | <H1>[IRCServices] IrcServices enforcing +R</H1> | |
| 15 | <B>Andrew Church</B> | |
| 16 | <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20IrcServices%20enforcing%20%2BR&In-Reply-To=ce6d53600703290659x484fb79of7a1992b1c02302b%40mail.gmail.com" | |
| 17 | TITLE="[IRCServices] IrcServices enforcing +R">achurch at achurch.org | |
| 18 | </A><BR> | |
| 19 | <I>Thu Mar 29 23:53:06 PDT 2007</I> | |
| 20 | <P><UL> | |
| 21 | <LI>Previous message: <A HREF="005243.html">[IRCServices] IrcServices enforcing +R | |
| 22 | </A></li> | |
| 23 | <LI>Next message: <A HREF="005245.html">[IRCServices] IrcServices enforcing +R | |
| 24 | </A></li> | |
| 25 | <LI> <B>Messages sorted by:</B> | |
| 26 | <a href="date.html#5244">[ date ]</a> | |
| 27 | <a href="thread.html#5244">[ thread ]</a> | |
| 28 | <a href="subject.html#5244">[ subject ]</a> | |
| 29 | <a href="author.html#5244">[ author ]</a> | |
| 30 | </LI> | |
| 31 | </UL> | |
| 32 | <HR> | |
| 33 | <!--beginarticle--> | |
| 34 | <PRE>><i>Imho, "modes lock" and "modes enforcement" are 2 different things. If | |
| 35 | </I>><i>they are separated, channel owners could decide not to enforce the | |
| 36 | </I>><i>modes, allowing for instance cmode +b be used to silence a user (as | |
| 37 | </I>><i>some irc servers don't allow messages from banned users) but still | |
| 38 | </I>><i>keep the banned user in the channel. Analogously, the same goes for | |
| 39 | </I>><i>cmode +r (identified to services only). Further, if configured by the | |
| 40 | </I>><i>services admin, services could act even more aggressively by kicking | |
| 41 | </I>><i>all users matching a ban not placed via the ban list in services but | |
| 42 | </I>><i>via /mode #chan +b mask, provided the channel has "modes enforcement | |
| 43 | </I>><i>on". The last extra isn't probably desirable for big production | |
| 44 | </I>><i>networks. | |
| 45 | </I>><i> | |
| 46 | </I>><i>Feel free to disagree with me, but propose something better instead, | |
| 47 | </I>><i>as my idea should be trivial to implement and is an acceptable | |
| 48 | </I>><i>compromise. | |
| 49 | </I> | |
| 50 | Okay, here's my proposal. The ChanServ "mode lock" functionality | |
| 51 | will enforce locked modes at all times, performing the following actions: | |
| 52 | ||
| 53 | - When a client attempts to change the state of a locked mode (off to | |
| 54 | on, on to off, or changing parameters of an active mode), ChanServ | |
| 55 | will reverse the change. | |
| 56 | ||
| 57 | - When a client joins an empty channel with one or modes locked on, | |
| 58 | those modes will be automatically set on the channel. | |
| 59 | ||
| 60 | - If a client attempts to join a channel to which the mode lock denies | |
| 61 | them access, ChanServ will kickban the client from the channel. | |
| 62 | ||
| 63 | If this enforcement is not desired, the mode lock functionality should not | |
| 64 | be used. | |
| 65 | ||
| 66 | Conveniently, this is how Services already works. (: | |
| 67 | ||
| 68 | --Andrew Church | |
| 69 | <A HREF="http://lists.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org</A> | |
| 70 | <A HREF="http://achurch.org/">http://achurch.org/</A> | |
| 71 | ||
| 72 | P.S. If you disagree with my decision, you are of course free to write | |
| 73 | (and distribute, if you so choose) a patch. That's what open source is | |
| 74 | about, after all. You would, however, be well advised to consider the | |
| 75 | varied effects of netsplits and netjoins, particularly with respect to | |
| 76 | colliding channels and clients in them at netjoin time. | |
| 77 | </PRE> | |
| 78 | ||
| 79 | ||
| 80 | ||
| 81 | ||
| 82 | ||
| 83 | <!--endarticle--> | |
| 84 | <HR> | |
| 85 | <P><UL> | |
| 86 | <!--threads--> | |
| 87 | <LI>Previous message: <A HREF="005243.html">[IRCServices] IrcServices enforcing +R | |
| 88 | </A></li> | |
| 89 | <LI>Next message: <A HREF="005245.html">[IRCServices] IrcServices enforcing +R | |
| 90 | </A></li> | |
| 91 | <LI> <B>Messages sorted by:</B> | |
| 92 | <a href="date.html#5244">[ date ]</a> | |
| 93 | <a href="thread.html#5244">[ thread ]</a> | |
| 94 | <a href="subject.html#5244">[ subject ]</a> | |
| 95 | <a href="author.html#5244">[ author ]</a> | |
| 96 | </LI> | |
| 97 | </UL> | |
| 98 | ||
| 99 | </body></html> |