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 Fri, Feb 26, 2010 at 9:23 PM, verdy_p <[email protected]> wrote:

>
> To make Gnutella really universal, it should be able to encapsulate all
> protocols that can work on top of a MAC
> layer (ecept that the Gnutella client GUID just replaces the Ethernet MAC
> address and is built to be universally
> unique and reachable, something that IEEE MAC addresses do not provide
> except on a single segment.
>

huh? even more tracking by using the mac? what about the cpu-ID? acer is
using to start the internetexplorer over their homepage with the ID in the
url and then forwarding to the set homepage? that is tracking like chrome...
the the GUID needs to be deletable. In offload this is solved by a GUID and
unique DHT position.


>
>  ported to IPv6-based routing network
>

here each network cable has a unique ID, that is even more than evil...



> It's time to think about P2P networks as an infrastructure instead of a
> specific service for file sharing (and this
> is what Microsoft has done in its own P2P protocol, used to extend private
> LANs securely to make them accessible
> from any access point where there's some Internet transport available but
> unpredictable IP addresses for these
> access points).
>

you know HADOOP from apache and yahoo? it is a storage system like offload.
so another reason, why offload is not a file sharing system, as there are
no  file in it, it is a dht network of blocks, you can bring in over XORing
a file. That has the advantage, to make big file distributions like ubuntu
distros stored in the network forever..

>
> The best service now is the Kademlia-based
> "Mojito" DHT, routed via the Gnutella infrastructure, and the host
> discovery system (that allows the network to
> remain fully connected, independantly of what they can transport).
>

kadc and for java mojito or the azureus java dht are well kown, the offload
dht works as well with that direction but has some advantages. you can
connect to the dht over the off url (magnet uri like), wich has the ip
included. Magnets as bootstrappers are possible. Second there is a cache
like the old bearshare has used.


>
>
> But the whole search service is bad as it cannot correctly index the
> ressources. A true service should behave more
> or less like a classic desktop search engine with a similar API. It should
> work over a smarter indexing database,
> and it should be capable of performing full text searches within documents
> or medias.
>

the file shared or stored in offload is cutted into small chunk blocks,
before the block is uploaded. that means the XOR Shredderer is used, before
the chunk is distributed, and: before the distribution starts, the client
knows, where the store in which client in the DHT, so the storage is done
before the search is done, the index is build before it is sent.
The off url is seperated from the network, the block data is shreddered
random and so meaningless, the meaning is in the off url, which should be
ideally not searched on the blocks-DHT network, but in a seperate one, so
any portal.e.g.



>
> If we develop such an infrastructure and want it open, and if it works, you
> can be sure that it will also used by
> spambot networks like "Storm". The problem is not how we can avoid it, but
> how we can limit its impact, so that the
> rest of the network will still remain usable and will offer great contents
> and services.
>

as offload is a storage network of blocks, and the off-torrents or urls or
gnutella-3-hash-links are seperated from the blocks DHT, there is no spam.
the idea who to make an off url repositiory has to be developed, e-g- a
portal or f2f sharing.

>
> If we cannot, then let's live with giant centralized servers (like Google
> and Facebook and their enormous databases
> of personnal information about hundred of millions of people in the world),
> and hope that they will not abuse it by
> selectively presenting us only the content they want us to see or want us
> to buy (though their paying advertizers),
> and also hope that our governments will force them to remain well-behaved
> to protect our privacy and all they know
> about us, so that nobody else (including themselves) will have the right to
> get an eye to our full profile, and that
> they will effectively delete out personal information immediately from our
> own request.
>

we can do a big action, if a p2p network is a storage network of random
blocks, and the meaning in the url allows to extract datafiles from the big
block cloud, that is the idea of hadoop apache and offload realizes this for
XORed blocks, which make the sharing safe as well. the MEANING is in the off
url and there we need just a portal or a big file distributer like any linux
distro, to link the files with offload urls.


>
>  Facebook is the worst service
> ever, much worse than Google that just tracks us to display a few non
> intrusive banners we can ignore.
>

I am woundering why you do not say this about ipV6.  please use retroshare
for F2F and friend connections.
libretroshare is found and developed here:
http://Retroshare.sf.net<http://retroshare.sf.net/>and the wxwidgets
gui of the messenger only is here;
http://retromessenger.sf.net wx-me SVN.


>
> The problem will always be the same: who do you trust, and how do you build
> a
> trunstable network and control at anytime the interaction and dissemination
> of information,
>

off network is a blocks network, there is even a ruby client found here;:
http://gitorious.org/blocksnet

maybe we a
php client as well for off / gnutella 3?
because the blocks are independent from the meaning of the off urls, there
is a great chance, to keep it free of spam, it is just a random data cloud,
and you can extract the needed blocks by the given off-url (aka magent
link).
So we just need a good off url repository like bitzi or Dooble Download
Directory, link given above, with nodes poviding the blocks, which means,
they just downloaded the url or stored it..


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