Re: Re: Implementing a Gnutella-structured network only with basic HTTP possible?Date: Wed, 24 Feb 2010 09:08:15 +0000 (UTC)Date: Fri, 26 Feb 2010 12:55:15 +0000 (UTC)

On Sat, Feb 27, 2010 at 2:48 AM, verdy_p <[email protected]> wrote:

>
>
>
Dear Philippe,

>just to make sure that some chunk of data is still present, you need a push
or pull
>protocol to detect this, Yes this is the role of a trcker to mange this,
or the DHT, sending the blocks into the right position to the right node,
Offload is doing three ways of distributing.
If you store locally, and do nothing, the local blocks are sent to the DHT
in a slow way, into the right node, into the rigth distance and postition of
"hamming distance",
Second, If you disperse, you can upload all the blocks 1-10 times, the user
defines how often, default is 3x, the same by them way in the
www.yay.netdht. and the users defines on which timestamp he is doing
that.
(e.g. a board users telling, we need more blocks.., then the inserter can
come up online again and dispers, go offline, and enough blocks are present
again.
third, users can download the off-url and the node (if online), who stored
the file, is sending the blocks in the requesting node.

>All of these participants must be also be equally reachable from anywhjere
>in the larger network.
see gain, ruled by the dht.
>Do you need trackers in fact? No. The DHT is supposed to do that,
right, you gave the answer, see above.

> excessive duplication that will overwhelm the available ressources of the
network.
see above, there are several ways, you can load an off-url even if it was
not dispersed. dispersing is an option.
if the storer of the file is online, you can load from that node without
dispersing/spreading the blocks before. so no duplocation is done
but what should dublication mean anyway? once it it called swarming, once it
is called having lots of download resources, once it it called,
suddenly in a DHT environment: OVERHEAD. What a nonsense. many nodes hosting
blocks refering to a file, is not redundancy, but also called speed.
if there are 50 users downloading the same off-torrent, each one wants the
blocks, and hostes the blocks redundant, and the result is:
you get speeds like in torrent, that was tested with off-urls in 2008.

>But people are still reluctant to cache data for others, notably if there's
a legal
>risk for this data. The only solution is to have this cached data
completely split into small chunks whose content
>is not directlly trackable to the metadata describing it: the chunks have
to be completely blind, possible even
>encrypted
you do not cache data, you cache random shreddered blocks, the correct way
to express would be:
people are reluctant to cache off urls. as the meaning is here, that is why
offsystem with spreading urls differs from offload,
which is not sending any off-url over the p2p network, but over retroshare
friend to friend web of trust instead,
Here you hop as well - with metadata - (and that is the point plus against
e.g. imule routing physical data chunks over a proxy chain of nodes)
so f2f is as well a kind of 7*7 hopping way to search and to push.
See retroshare, which has implemented f2f turtle (tannenbaum) hopping. You
can search for filename and hash, as well for shared off-urls
and there is a newsgroup feature, and: not made visible in the gui of client
v 05. : Link Cloud, which is not a search over friends
of friends, but a PUSH of OFF-Urls to fiends and their friends and their
friends...
so this will develop, but a normal portal in the beginning to have off urls
listed is quite pretty. maybe we can use bitzi.com

<And there asolutely MUST exist a feature in the design that will allow the
ORIGINAL submitted
<to send a kill action
blocks are always available on the network, a kill is not possible in normal
guntella, if the file has been released, onayone still can share it...
But you can control in offload, to whom you give the orr-url.
>Now there's the need to control the reputation of every participant: the
public reputation is not good, what people
>want is a restricted level where their trust can be given to a handful of
particopants
retroshare is a web of trust, in which you can sign full or half or not your
friends.
but that is done for friends, and off urls are hopped and shared in this
kind of web of trust, while the p2p network just hostes
some random data blocks in a DHT. Offload gui tries to combine p2p block
hosting in a dht with a friend to friend web of trust messenger
which is not yet implemented due to wxwidgets gui.

>The delegations also MUST not be symetric: you should be able to give trust
for yuou own needs, to someone that will
>not trust you for his own needs.
yes, retroshare allows to sign someone as half trusted.
That is why i request to start to make a proove of concept along the offload
client, there is less work to do, just some gui improvements,
And some people, taking then the together finished client and release it
under some clone/fork in their context.
Regards


[Non-text portions of this message have been removed]