Re: Some ideas on Freenet architecture

Arne Babenhauserheide <arne_bab-S0/[email protected]> Wed, 13 Sep 2017 22:23:01 +0200
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
Matthew John Toseland <[email protected]> writes:

> On 12/09/17 22:34, Arne Babenhauserheide wrote:
>> 
>> Matthew John Toseland <[email protected]> writes:
>>> But we need *something* in this approximate area.
>> 
>> I fully agree with that. I think however that we need to be careful not
>> to require user interaction for that. Users already added the friend, we
>> can’t require more than maintaining the friend connections. Otherwise
>> that would be the next bottleneck.
>
> What makes you think we'd need user interaction?

That’s how I understood it.

> If there is any deconfliction it's all at the client level, not the
> node. The client can enforce any appropriate rules and decide to cast a
> vote by reinserting the block it most prefers. The user might get
> involved if there's a dispute about e.g. eliminating spammers.

I don’t understand how the client casts votes without exposing the
data it uses to decide how to vote. How do you avoid coupling private
data with the insert decisions?

> Proposal 0: Bundles
> -------------------
>
> If an SSK insert has maximum HTL, we pre-route it along a fixed
> pseudo-random path, which ideally doesn't change for a given source
> node. It only uses friend connections, and stays at max HTL until a
> pseudo-random termination point (always the same node on a static
> network). After that it turns into an ordinary insert.

Do I understand it correctly that this means that all inserts from a
given source initially travel along the same path?

If yes, then it sounds good.

> There are tricks we can use to compensate for churn by using shadow
> nodes so that even if we can't route it to fixed peer A, we route it to
> fixed peer B instead, but the following hop is the same (possibly using
> FOAF connections and proof of previous arrangements and whatever).

That sounds like quite a bit of additional complexity but a nice
longterm goal.

It would be great to have this for requests, too, since this would
clearly stop most correlation attacks which are used right now.

> Proposal 1: Scarce SSKs with global (per-node) scarcity
> -------------------------------------------------------
…
> Proposal 2: Scarce SSKs with per-key scarcity and multiple versions
> -------------------------------------------------------------------
…
> Proposal 3: Scarce SSKs with voting
> -----------------------------------
…
I don’t really understand these three. They all sound like they could
leak information from the anonymous ID layer to the networking layer.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken
signature.asc (application/pgp-signature, 832 B)