cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1997-01-11 - Re: A vote of confidence for Sandy

Header Data

From: Against Moderation <antimod@nym.alias.net>
To: Ray Arachelian <sandfort@crl.com
Message Hash: 71a4a75261ba39d3e2afac5f0a8ccc87d8ac12d174e433fec0b33828e27827dc
Message ID: <19970111060735.2441.qmail@anon.lcs.mit.edu>
Reply To: <Pine.SUN.3.91.970109162541.11773A-100000@beast.brainlink.com>
UTC Datetime: 1997-01-11 06:07:46 UTC
Raw Date: Fri, 10 Jan 1997 22:07:46 -0800 (PST)

Raw message

From: Against Moderation <antimod@nym.alias.net>
Date: Fri, 10 Jan 1997 22:07:46 -0800 (PST)
To: Ray Arachelian <sandfort@crl.com
Subject: Re: A vote of confidence for Sandy
In-Reply-To: <Pine.SUN.3.91.970109162541.11773A-100000@beast.brainlink.com>
Message-ID: <19970111060735.2441.qmail@anon.lcs.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


Ray Arachelian <sunder@brainlink.com> writes:

> > 3. Not making the unmoderated list first-up (i.e., cutting posts first,
> >    then making the "full" list available later) is suspicious, or at
> >    least a bad idea.
> 
> What difference does it make if a message is delayed for 10-30 minutes?  
> Why is it a bad idea or suspicious?  If you post something and it doesn't 
> make it at all, you can complain about it.  Is that what you fear?

10-30 minutes is potentially far less than it would take.  What about
mail that arrives in the middle of the night, or what if all the
moderators are away or busy.

If you really want to filter cypherpunks@toad.com by default, fine.
But is it too much to ask for those of us who don't want the filtering
to request an unmoderated, undelayed list, with all headers intact
(someone had suggested Approved headers be removed)?

Remember, other people may want to run differently moderated versions
of the list.  If you add delay before secondary moderators can even
get the stuff, you are unfairly penalizing those who use a better or
more efficient filtering scheme, because those people will have to
wait for the central authorities' moderation decisions before even
their own moderators or auto-moderators get ahold of messages.

> The point was to optimize the sendmail to send moderated messages first.

Fine for those who want the moderation, but why are you forcing
everyone to use this scheme?

There are plenty of moderation schemes that are way more cypherpunk
than one central moderation authority.  NoCeM is one great example.
Obviously some people don't have the right software to experiment with
this--fine they can subscribe to a centrally moderated list.  But why
not let those of us who write code experiment with other ways of
moderating the list?  Please.

What does it cost anyone to have a separate mailing list which
immediately gets all cypherpunks submissions?  The only argument
against this is "load", but that doesn't make sense.  First of all, if
someone subscribes to cypherpunks-raw instead of cypherpunks and
cypherpunks-flames, the total number of messages is the same, and the
amount of bandwith you might lose to split mult-RCPT messages is
negligiable (and could easily be recouped by switching mailers, though
that shouldn't even be necessary).

More importantly, if some significant number of people really do want
to subscribe to cypherpunks-raw (as in enough that you would even
start to think about load), then maybe centralized moderation is not
the way to go.

What is the advantage of not having a cypherpunks-raw?  I just don't
understand it.  It costs you nothing, it shows your willingness to
compete with other moderators or moderation schemes, and it will make
people a lot more confident that you aren't suppressing some messages
from cypherpunks-flames list.

If for some reason load really is the problem (though I can't see
how), then can you set some maximum number of subscribers you would be
willing to mail cypherpunks-raw to?  I mean 50 people shouldn't be
that big a deal, right?  And if more than 50 want to subscribe and you
think toad can't handle the load, I will run a mail exploder on a
different machine.

Thread