CDRv2 discussion (was: Re: Al-qaeda.net deprecated)
J.A. Terranson
measl at mfn.org
Mon Jan 20 13:24:54 PST 2014
On Mon, 20 Jan 2014, Riad S. Wahby wrote:
> As far as I can tell this doesn't (yet) solve the problem of
> whitelisting subscribers to other nodes.
>
> However, we can add one more step and solve this: when a node receives
> an email from the repeater whose sender is a member of the node's local
> subscriber list, it bounces the message back to the repeater with an
> added header saying, in effect, "I vouch for this sender."
There are two possible approaches to dealing with white (& black)
listings:
(1) The repeater is a dumb one, and doesn't care, each node on the CDR is
free to implement their own local rules and white/blacklists;
(2) Any one whitelist is agreed to be valid for all nodes: as you point
out, there will need to be some way to recognize that.
Option 1 is simple to implement, but I don't know if it's consistent with
the goals of sharing information freely amongst CDR subscribers. Option 2
is, obviously, much harder to design.
<SNIP>
\> I'm not totally in love with the master repeater scheme, though.
> Notwithstanding my previous comments regarding the supposed threat model
> behind the CDR's original conception, as long as we're paying the fixed
> cost of setting up a new system we may as well get *some* additional
> reliability out of it, right?
OK: if we want to design redundancy in all possible dimensions (above the
threat model I believe, but still a good practice to have no single point
of failure... We have a repeater on each CDR which, again, is elected
every time an Elected Master Repeater refuses/fails to keep up with a
heartbeat timer?
> -=rsw
>
//Alif
--
Those who make peaceful change impossible,
make violent revolution inevitable.
An American Spring is coming:
one way or another.
More information about the cypherpunks
mailing list