Re: Re: Gnutella 3

On Sat, Feb 27, 2010 at 12:51 AM, <[email protected]> wrote:

>
>   I believe that the use cases
> and the philosophy are completely different from the ones that Gnutella
> supports.
>
> my claim was, that gnutells 3 is or will be not gnutella


>   As a publisher, I do not want to upload data to a system so that later
> on
> people can access it.
>
> oin offload you do not do this, as you decide to give data to the p2p
network by giving them your off url.
that is the same in gnutella, once someone downloaded your magnet link, he
can go on sharing,
so the same with the off url. so keep it in the group, you want to share
with.


>   As a user, I do not want to use two different systems to get the data,
> so using a separate out-of-band mechanism seems a bit awkward.
>
>
torrent had as well no search system for torrents, so the same for
off-torrents or gnutella 3
as said, it is possible to share these kind of magnets on the blocks
network, but it is not recommended,
so why not on bitzi or a gnutella 3 portal? a search system would work
different over f2f hopping urls,
the short metadata is ideal to forward the ulr database from friend to
friend.


>   Active publishing also raises the problem of data expiration. The
> network
> is not going to keep published data indefinitely since its capacity,
> although
> huge potentially, remains limited. So this makes things more complex to
> manage from a network perspective.
>
>
that is not true, if you insert you file into the network, this node is
hosting the blocks,
as soon as someone is downloading the off-url, you have the blocks as well
in this node present.
as long as his cache is still growing, third, there is the way to disperse,
which means to upload actibvely the blocks to the DHT,
then all other nodes have good chances, to represnetz 100 % of the needed
blocks, and fourth, you can XOR one file with the other, which means, you
have the blocks for ubuntu and at the same time you can restore kubuntu, so
the blocks can have two meanings or uses for a restore, which makes blocks
very efficient to keep the representation within the network.


>   This is not really what I had in mind when I proposed "Gnutella 3.0".
>
> For me Gnutella is a search network with almost zero-cost for publishing.
>

publishing in offload / gnutella 3 means as well to upload the file, go
offline, and the blocks/off url still work,
You can publslish without beeing online. that is zero cost and zero risk.
you search for off urls only in portals or in OFD Files, which are big
repository catalogues shared in offload, you can download the whole bitzi
with one off url,
so what do you mean? ne need to search, with ONE url, you can download
locally and index the whole network!! why searching 7*7 hops, if one magnet
link can represent the whole network file index? one url and the whole world
is given.
only one service needs to pack it. as odf..


>   And Gnutella also offers an efficient swarming ability, thanks to the
> combination of the download mesh and the recently introduced DHT.
>
> offload has been tested and it swarms as fast as torrent, that means,
though, you do not see, which IP is swarming. so this term is not used.


>   It even outperforms bittorrent from an architecture point of view
> (partly
> due to a grave bug in bittorent's torrent file architecture where the
> hash of the complete file is not mandatory -- this can lead to having
> several torrents for the same file if the file is not split identically).
>
>
off-torrent are some kind of bit-torrent and the chunks represent ed2k, it
is a mix of all, gnutella, torrent and ed2k, so if you really want to revoke
gnutella, makte offload gnutella 3.


>   For popular content, downloading with Gnutella or from bittorrent is
> almost equivalent. For non-popular content, downloading with bittorrent
> fails miserably.
>
>
and this is the difference for torrent and off-torrent, off torrent is still
available on the network, if the seeder node even has gone, as the blocks
are in the DHT in each client a piece.


>   One of the shortcomings of Gnutella 1.0 that I would like to see
> addressed
> is a standard way to query by regular expression, and not just the file
> name but also the available meta data.
>
> Another shortcoming is avoiding badly designed XML. I don't want to do
> any fingerpointing, but using XML schemas is just plain stupid. Even using
> XML ("in the name of simplification, standardization, hype, convenience")
> at all is questionable.
>
>
> yes, off urls have only the filehash and the filename, maybe we can work on
it to make additional information available, and i think it is an
interesting development to add the magnet structure appendable to the start
of the off-hash, which is HTTP.. so, why not making a magnet starndard, that
magnets 3.0 begin with http://localhost or http://IP-adress<http://ip-adress/>



>
> Gnutella 3.0, the Lord of P2P networks :-)
>
>

Well, you and we need to clarify for one point, if you share open source
files, all the sharing networks are well done
The question is, if you want to provide means, that the users can share mp3
and movies again, which make them not sueable.
or simpler: has gnutella 3 a sue risk or does it include anonymous sharing,
which is done in all other 3. generation p2ps by proxying
(retroshare.sf.netf2f hopping, or
i2p2.de / imule with proxying from peer to peer) or as offload to share
meaningless data blocks in a network, which is not of interested, as all p2p
nodes share only shreddered blocks, The meaning is in the off url. So a
network, in which you can share without a risk, and the user decides, to
whoom an OFF-MAGNET is shared and over which sharing base (e.g. portal like
bitzi).


So the only point I see in the draft for gnutella, is the wish, to have
additional metadata in the hashlink, like the videosize or mp3 quality. I
guess that is extendable and developable, sharing the OFF url is possible,
but i think it is better done in another portal and not on the p2op network,
as meaning (urls) and blocks (shreddered data) has to be kept apart, to
avoid accusationd asn sue processes for the p2p network.

I dont think, that the lib-offsystem, e.g. realized in the blocksnet ruby
client or the wxwidgets c++ client of offload, is too bad, it is ideal to
develop it as gnutella 3 and maybe some inventive developer on this list
comes out with an offload clone renamed to "gnutella three strikes" (lol)
though this only would be a term, we again would wounder about, but instead
i recommend to develop the liboffsystem ad a gnutella 3 library!
that would require:
- build an client (we could use offload) as a gnutella 3 client
- we should describe the main points in a wiki
- we could write a RFC
- we need the implementation in 2-3 clients, to get a "market" competition
for gnutella 3
- the integartion of liboffsystem into a gnutella hybrid would be idea.
maybe there is a gntuella client with wxwidgets c++ gui? do you know one?
- we should start with an open source media bitzi.com. Users should be able
to add off urls to the database.
- develop ideas, how a magnet standard can start with http-prefix and how to
extend the off-url with additional metadata.

Regards Max


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