Re: Some ideas on Freenet architecture

Matthew John Toseland <[email protected]> Fri, 15 Sep 2017 21:36:55 +0100
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
On 15/09/17 20:51, Arne Babenhauserheide wrote:
> 
> Matthew John Toseland <[email protected]> writes:
>> Specifically, the process for a scarce *insert* will be:
>> 1) Is the key popular?? We can tell this from how many peers are
>> subscribed to it in the ULPR table. If not, kill the request; we only
>> provide protection for popular applications.
>> 2) Has there been another scarce SSK insert from the same peer recently?
>> If so, kill the request; they've used their quota. (More complex
>> conditions are possible; quotas, per-key etc)
>> 3) Commit the data to the datastore and propagate it via ULPRs.
>>
>> So indeed, there is no routing involved here.
> 
> This sounds good.

The above is slightly inaccurate. For a genuine user, the third step
starts off as a bundle, then later becomes a broadcast. We enforce the
scarcity and popularity requirements in both stages.

Spammers would of course go straight into the broadcast stage.

Not involving routing is because I can't see a way to involve routing
that actually works. Perfect scalability is not necessary, only good
enough scalability.
> 
>> All we do is have a single global Scarce KSK queue for announcements.
>> Every WoT instance subscribes to it. The key is generated from the date
>> and changes e.g. once a day. All scarce inserts are propagated to all
>> nodes - but the scarcity mechanism restricts the number of inserts.
> …
>> Every WoT instance adds every identity announced via the queue. Then we
>> rely on the usual mechanisms to weed out spammers after the fact - some
>> combination of positive and negative trust, backed by the fact that it's
>> relatively costly to create new identities.
> 
> This misses part of the point of WoT: WoT only lets you be seen by a
> small group at first and when you get positive trust you get seen by a
> wider group.
> 
> However a solation which keeps the resilience of WoT active could be
> built on top of what you describe by not having one global queue but
> rather N queues with each ID trusting one of the queues chosen at
> random. Every day you choose another section to watch.
> 
> N could be chosen by taking the size of the WoT into account.

For Scarce KSKs to work, as currently designed, the queue needs to be
*very* popular. So maybe have everyone subscribe to the global queue,
but new identities only accepted automatically by some randomised subset
of the graph. Then you need to get some likes or whatever before you can
be seen more widely.
> 
> This would enable use-cases like automatic newsbots (something I’m
> sorely missing for babcom_cli).

I don't understand this use-case.
> 
> Kudos!
> 
> Best wishes,
> Arne
>
signature.asc (application/pgp-signature, 833 B)