[bittorrent] Short secure file identifiers

Edward Walker walker.edward at gmail.com
Thu Jul 7 03:04:24 EDT 2005


> 
> What is controversial are the precise details of /how/ they're
> implemented, not the choice to use them.
>

Hi.
so do you think there will be agreement on a proposal soon? With authoritative
Bram missing I think that's gonna be hard. This proposal is something
that client
developers can adopt without breaking backward compatibility.
 
> 
> Why, when you're trying to stay similar to pure BitTorrent, are you
> introducing this ridiculous "SSFID" from nowhere? This doesn't gain you
> anything, and adds complexity.
>

Ultimately, I would like to have just BitTorrent URLs, which can then
be supported by
browsers natively, just as with ftp:// to improve usability (no need
to install and update separate client, human transcribable) and it
gets the Web servers for distributing the
torrents out of the loop. 
 
> You've introduced this "SSFID", a very significant protocol change. Given
> the lack of anything to gain from this, why? Due to creating this, you
> cannot fallback to the strategy of manually telling your normal BT client
> to download the metatorrent and then the main torrent.
>

Yes, you can. The .torrents and meta torrents can still be distributed
via Web sites
to support clients that don't understand BT URLs. So this proposal
allows for a transitional period in which all clients are supported.
 
> There is little incentive for peers to keep with the metatorrent. Given
> this ordinary peers will download it then disappear from that group. Only
> seeds are likely to stick with it, and so it is likely to die
> 

Most client now a days automatically continue to seed after download.
In any case,
at worst the situation is as bad as the worst case now. Currently, on
a bad day, the .torrent is available only from the original Web
servers. On a bad day in this proposal, the
.torrent is available only from the seeds. In all other cases there
will be more peers
available to get the .torrent from, automatically.

> > What I like particularly is that we can use this solution to reduce
> > blocksize.
>
> And this is novel?

Yes, I think so, because it is done without changes to the on-the-wire
BT protocol.

> 
> > Alternatively, one can first apply recursion again and upload the meta
> > torrent M into BitTorrent.
> 
> And this is different from "Merkle" trees?
> 

It solves the same problem using the same mechanism (recursion) but
without changing the on-the-wire protocol and creating a compatibility
problem.

ttfn, Ed



More information about the BitTorrent mailing list