Re: Some ideas on Freenet architecture

Arne Babenhauserheide <arne_bab-S0/[email protected]> Thu, 14 Sep 2017 23:18:20 +0200
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
Matthew John Toseland <[email protected]> writes:
> On 14/09/17 17:33, Arne Babenhauserheide wrote:
>> I think the core problem is that I don’t quite understand what you’re
>> proposing. Bundles I understand, but I don’t understand how the scarce
>> SSKs change routing.
>
> They don't. Pre-routing (bundles) applies to scarce SSKs as well as to
> ordinary keys. What changes (in proposal 1 and later) is that during the
> pre-routing phase we impose per-connection limits.
>
> With the updates I've posted, scarce SSKs do not get routed at all. I
> don't think it makes sense to try to impose that sort of limits on
> routed inserts, because it would tend to distort routing.
>
> Instead they only work if a key is popular. For popular keys we
> generally don't route much either: the first few requests get routed,
> but we end up forming a web of ULPRs, so that when the data is inserted,
> it rapidly gets propagated everywhere.

It first needs to be in the store of a node at the fitting location,
right? Then it gets requested and the ULPRs catch the requests.

Or do the ULPRs actually see the inserts directly?

> Hence my proposal is that we only allow "scarce SSKs" for keys so
> popular that most of the network is subscribing to them via ULPRs. This
> only means 5% or so of the network is actively requesting them
> occasionally. But it covers the key use cases such as WoT announcement.

So you mean when there’s a ULPR pointing to a KSK, it wouldn’t be routed?

> IMHO we need a degree of fairness to provide effective spam defence.
> Hence the multiple versions proposal: the spammer can insert a limited
> number of keys, but he can't prevent the other legitimate inserts.

This sounds like it would create much additional complexity. Do we need
globally consistent CAPTCHA solutions?

>> Or even deeper into my missing understanding: How should multiple SSKs
>> compete at all, given that only one person has the private key?
>
> Announcements typically use KSKs, known private keys, or similar
> spammable mechanisms. That's what we're trying to replace here.

That’s great!

> The only points at which this escalates to the client layer are:
> 1) For proposal 2, clients will get multiple responses to a
> request/subscription, and will need to decide what to do with them.
> 2) For proposal 3, clients additionally should register a vote by
> reinserting the SSK they prefer.




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