Send Devl mailing list submissions to
        devl at freenetproject.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.uprizer.com/mailman/listinfo/devl
or, via email, send a message with subject or body 'help' to
        devl-request at freenetproject.org

You can reach the person managing the list at
        devl-admin at freenetproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devl digest..."


Today's Topics:

   1. Re: Proposal: algorithm for forgetting documents in datastore (Tavin Cole)
   2. Re: Announcement Protocol (Oskar Sandberg)
   3. Re: Announcement Protocol (Oskar Sandberg)
   4. Re: GMP/GCJ update. (Mark J. Roberts)
   5. Re: Aardvark (Mark J. Roberts)
   6. Re: Aardvark (Sebastian Spaeth)
   7. Re: Aardvark (Tavin Cole)

--__--__--

Message: 1
Date: Thu, 1 Feb 2001 12:39:53 -0500
From: Tavin Cole <ta...@mailandnews.com>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Proposal: algorithm for forgetting documents in 
datastore
Reply-To: devl at freenetproject.org

On Thu, Feb 01, 2001 at 12:38:24PM +0100, Neil Barsema wrote:
> Tavin Cole wrote
> >There is no way "a file can be instrumental in a routing decision" ..
> >you're talking nonsense here.
> >I can see how the structure of the 0.3
> >datastore could lead to this misconception, but files and references
> >are going to be much more orthogonal in 0.4 anyway.
> 
> >The best interpretation of what you just said is that, if a node
> successfully
> >routes a request for a file that was not in its datastore, it should
> >promote the file that was originally associated with the reference used
> >in the routing decision.  So you would be promoting a file because it's
> >close to a key that's popular on another node.   How would that help
> >matters?
> 
> Hm for nonsense you pretty much got the concept well enough to see a way to
> implement it in the current technical solution. I apologise for missing this
> development I have been away ;-)
> 
> anyway ok, the file originally associated with the reference gets a tiny
> bump.
> that's basicly my suggestion.
> 
> Now to how that will help matters.
> Your not promoting a file that is close to a key that is popular on another
> node(well you are but thats besides the point), you are promoting a file
> that is close to a key that some other node thought your node should be
> serving.

Dude!!!  You just don't get it.  If your node routes a request, there's
no (necessary) relationship whatsoever with the key being routed and your
node's keyspace focus.  Granted, you should receive more requests that
are close to your keyspace focus than not, but you'd still end up
promoting lots of files that are far away from it.

The closest we could come to making this make sense is, anytime your
node successfully serves a file from its datastore, it looks for the file
with the key closest to that one and promotes it.  I hope you can see
the flaw in that.


> Basicly files competing against deletion are all pretty unpopular. Either
> because they aren't close enough to the keyspace focus or because they are
> outright unpopular.
> 
> What people don't seem te get is I am fighting for unpopular files!

It's impossible!  You can only end up reducing the percentage of successful
requests over the whole network.

I'm sorry if my explanations have been less than clear, but if you consider
how Freenet routing works for a while, you will come to the same conclusions.


> If the outright unpopular file gets deleted chances are it is going to fall
> out of Freenet altogether.
> however if we delete the file that just isn't close enough to the focus we
> are probably just reducing (unnescasary) redundancy in the network.
> 
> My suggestion in no way guaranties the unpopular file will persists it just
> improves its chances.
> 
> But okay, if no one sees the merrit in the suggestion I'll stop pushing it,
> I'll go back to pushing request forking. Has that been implemented yet ;-)

-- 

// Tavin Cole


--__--__--

Message: 2
Date: Thu, 1 Feb 2001 19:05:23 +0100
From: Oskar Sandberg <md98-...@nada.kth.se>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org

On Thu, Feb 01, 2001 at 11:33:35AM -0500, Scott G. Miller wrote:
<>
> Alice can detect evilness though.  If Mallory acting as Bob2 completely
> fabricates the nodes above him on the chain, Alice will find out when she
> tries to retrieve the keys those fake nodes sent back.  If they try and
> forge the x values then that will be detected, again by Alice.  In either
> case she can re-announce.  Because the routes are random, the chances of
> encountering the same Bob2 the second time are 1 in the number of
> references in Bob1's datastore.

Another thing we can implement, to help against the evil Bob2 problem is
to allow Alice to start several announcement messages at once with the
same id - one for every address she trusts from the start. That way having
just two addresses from the beginning will half the effect of an evil
Bob2.

-- 
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.

Oskar Sandberg
md98-osa at nada.kth.se


--__--__--

Message: 3
Date: Thu, 1 Feb 2001 19:05:23 +0100
From: Oskar Sandberg <md98-...@nada.kth.se>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org

On Thu, Feb 01, 2001 at 11:33:35AM -0500, Scott G. Miller wrote:
<>
> Alice can detect evilness though.  If Mallory acting as Bob2 completely
> fabricates the nodes above him on the chain, Alice will find out when she
> tries to retrieve the keys those fake nodes sent back.  If they try and
> forge the x values then that will be detected, again by Alice.  In either
> case she can re-announce.  Because the routes are random, the chances of
> encountering the same Bob2 the second time are 1 in the number of
> references in Bob1's datastore.

Another thing we can implement, to help against the evil Bob2 problem is
to allow Alice to start several announcement messages at once with the
same id - one for every address she trusts from the start. That way having
just two addresses from the beginning will half the effect of an evil
Bob2.

-- 
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.

Oskar Sandberg
md98-osa at nada.kth.se


--__--__--

Message: 4
Date: Thu, 1 Feb 2001 12:43:18 -0500 (EST)
From: "Mark J. Roberts" <m...@statesmean.com>
To: <devl at freenetproject.org>
Subject: Re: [freenet-devl] GMP/GCJ update.
Reply-To: devl at freenetproject.org

On Thu, 1 Feb 2001, Oskar Sandberg wrote:

> On Wed, Jan 31, 2001 at 05:50:08PM -0500, Mark J. Roberts wrote:
> < snip >
> > Curiously, other similar shifts appear to work. Weird.
>
> I have a question, why can't you just copy Kaffe's stuff? I thought that
> was the spirit of free software...

Kaffe's stuff uses JNI to link in the C code, GCJ uses CNI. Otherwise
there's no real reason. But it wasn't too hard.


-- 
Mark Roberts
mjr at statesmean.com



--__--__--

Message: 5
Date: Thu, 1 Feb 2001 12:52:34 -0500 (EST)
From: "Mark J. Roberts" <m...@statesmean.com>
To: <devl at freenetproject.org>
Subject: Re: [freenet-devl] Aardvark
Reply-To: devl at freenetproject.org

On Thu, 1 Feb 2001, Scott G. Miller wrote:

> > An evil node can easily spoof a KSK.  Plus someone else can easily steal
> Only if he knows its text key or dictionary attacks it.

Or (and I'm not sure about this) if the KSK in question is searchable, and
thus AFAIK must have its own text key in public metadata. True or false?

> > your KSK if it falls off enough of the network.  People can also play
> > tricks like finding a node that doesn't have the key in its cache
> > (by requesting with HTL=1) and then inserting it with HTL=1.  There's
> > supposed to be a random chance to keep forwarding a request with HTL=1
> > but even so, the attacker still has a chance.
> Correct.
>
>

-- 
Mark Roberts
mjr at statesmean.com



--__--__--

Message: 6
Date: Thu, 01 Feb 2001 20:17:39 +0100
From: Sebastian Spaeth <sebast...@sspaeth.de>
Organization: University of =?iso-8859-1?Q?Link=F6ping?=
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
Reply-To: devl at freenetproject.org

> >     OS> For fucks sake people, YOU DON'T LINK TO KSKS! It's fucking
> >     OS> nuts!
> >
> > Why not? Jeez!
> 
> What rock have you been under???
Whoohoo not everybody can know all aspects of the keys without even
having documentated them.
> 
> Linking to a KSK means "I want to you to check out a document written by
> anybody who wanted to place a document under the term <KSK value> which
> may or may not be the same document I got when I requested that key."

While I agree with you, we have to point the dangers of KSK keys more
out to normal users. These reasons should e.g. be definitely be in the
Freenet FAQ.

Sebastian 
P.S. This reminds me quite a bit of the current DNS system, where the
cleartext->address converter is a point of weakness.


--__--__--

Message: 7
Date: Thu, 1 Feb 2001 23:45:01 -0500
From: Tavin Cole <ta...@mailandnews.com>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
Reply-To: devl at freenetproject.org

On Thu, Feb 01, 2001 at 08:17:39PM +0100, Sebastian Spaeth wrote:
> > 
> > What rock have you been under???
>
> Whoohoo not everybody can know all aspects of the keys without even
> having documentated them.
> 
> While I agree with you, we have to point the dangers of KSK keys more
> out to normal users. These reasons should e.g. be definitely be in the
> Freenet FAQ.

Certainly the FAQ needs some overhauling, and we're obviously not getting
anywhere on the Freenet manual..  now if *cough* one of our Lyx proponents
would kindly explain how to get included files working, so we could each
work on a different section of the manual at the same time..  but who am I
kidding, I guess we're gonna be lucky if even 1 person works on it at
a time..

-- 

// Tavin Cole



--__--__--

_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://www.uprizer.com/mailman/listinfo/devl


End of Devl Digest

Reply via email to