One line of options might be to offer some user specific server mode, similar +d (but only blocking joins/parts from a channel -- still leaving the issue of quits), or some channel specific (rather than host specific) server side utility such as +silence (again, modified to filter joins/parts, and in this case possibly even quits). Client side solutions could not work because they, at best, filter or redirect incoming information. This still leaves the bandwidth issues for truely large channels. Undernet definitely has a need for a utility like this for their #class services. I have been trying to view these for years and have been driven out by the mass of joins/parts/quits.
pzl ----- Original Message ----- From: "peter green" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, July 28, 2002 3:13 AM Subject: Re: [Coder-Com] Patch idea.. any thoughts? > I think i have a soloution to your problem which would requier much less > upheavel > > first you add a channel mode which redirects limit blocked clients to > another channel > > then you have a bot which replicates the traffic > > >From: [EMAIL PROTECTED] > >To: [EMAIL PROTECTED] > >Subject: Re: [Coder-Com] Patch idea.. any thoughts? > >Date: Sun, 28 Jul 2002 01:42:31 +0100 > >MIME-Version: 1.0 > >Received: from mc2-f17.law16.hotmail.com ([65.54.237.24]) by > >mc2-s14.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 > >Jul 2002 17:48:01 -0700 > >Received: from trek.sbg.org ([66.134.137.28]) by mc2-f17.law16.hotmail.com > >with Microsoft SMTPSVC(5.0.2195.4905); Sat, 27 Jul 2002 17:47:47 -0700 > >Received: (from undernet@localhost)by trek.sbg.org (8.12.1/8.12.1) id > >g6S0gbRd032709for coder-com-outgoing; Sat, 27 Jul 2002 17:42:37 -0700 > >Received: from mercury.stbarnab.as ([212.115.48.196])by trek.sbg.org > >(8.12.1/8.12.1) with ESMTP id g6S0gZJs032706for <[EMAIL PROTECTED]>; > >Sat, 27 Jul 2002 17:42:36 -0700 > >Received: from ground.stbarnab.as ([212.115.48.200] ident=mail)by > >mercury.stbarnab.as with esmtp (Exim 3.36 #2)id 17Yc8o-00027l-00for > >[EMAIL PROTECTED]; Sun, 28 Jul 2002 00:42:34 +0000 > >Received: from davidm by ground.stbarnab.as with local (Exim 3.35 #1 > >(Debian))id 17Yc8l-0001UP-00for <[EMAIL PROTECTED]>; Sun, 28 Jul 2002 > >01:42:31 +0100 > >Message-ID: <[EMAIL PROTECTED]> > >References: <[EMAIL PROTECTED]> > ><[EMAIL PROTECTED]> > >In-Reply-To: <[EMAIL PROTECTED]> > >User-Agent: Mutt/1.3.28i > >Sender: [EMAIL PROTECTED] > >Precedence: bulk > >Return-Path: [EMAIL PROTECTED] > >X-OriginalArrivalTime: 28 Jul 2002 00:47:48.0052 (UTC) > >FILETIME=[64CE8140:01C235D0] > > > >On Sat, Jul 27, 2002 at 02:43:11AM -0400, Py Fivestones wrote: > > > > > Doesn't that pretty much destroy the concept behind IRC, that is to > >allow > > > people to chat with each other? Also, don't people on a channel have the > > > right to see who they are keeping company, and thus being associated > >with? > > > >The mode under discussion is only for use for very large channels (and if > >implemented would probably only be settable on channels at least 500 users > >or something). Under these circumstances the points you mention are less > >important (particularly if without the mode the users can't stay on the > >network!). > > > > > The other question is, will this channel mode break IRC clients? > > > >If the implementation works as I envisage it, not really. There would be > >users on the channel that the ircd knows about but the client doesn't, but > >there is no way for the client to find out about them anyway (they can't > >talk or anything, and nick changes etc. would be supressed). Enabling ops > >to see all channel members would allow bots to function normally, too. > > > >splidge > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com >
