[Noisebridge-discuss] Is there a good way to do incrementally updated torrents?

[travis+ml-noisebridge at subspacefield.org]

On Tue, Dec 07, 2010 at 01:46:51PM -0600, Sai wrote:
> The only ways around this I know of is
> a) issuing whole new torrents for each update (which don't know about
> each other and thus are likely to duplicate traffic and disk space),
> or
> b) issuing updates in batches, with one torrent per batch (which
> logically fragments the data, but at least is consistent)
> 
> Is there a better solution?
> 
> I think one solution would be to issue new torrents that have "the
> same pointers" as old torrents for the files they have in common, such
> that people hosting the older versions participate fully in sharing
> the subset of the new version that was in the last even if they don't
> switch to the new one. But I don't know whether it's possible to do
> this with the current bittorrent protocol; I suspect not.

You know, this is what Zooko was talking about when he talked about
Tahoe-LAFS (which I still think shouldn't be called a "file system").

In Tahoe-LAFS, he has "mutable" and "immutable" files.  The immutable
ones are referred to by a hash of their contents, but mutable ones
have to be handled differently, since the name is a pointer to
contents which are basically undefined or may change.

I've wondered about alternative uses of bittorrent, such as for
actually sharing web content itself.  Imagine that you could publish
the entire contents of a web site over bittorrent, and that browsers
could trigger BT downloads as you click on hyperlinks.  That way, you
could publish a web site, but only have to provide the bandwidth once,
in theory.
-- 
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.noisebridge.net/pipermail/noisebridge-discuss/attachments/20101208/5a14f1ac/attachment-0003.sig>