Comments for MUTE File Sharing

15 May 2004 09:45 DickBreath

An idea
I like Mute's virtual network.

Still, a possible problem is that an entire file is sent from point A to point B.

Now suppose that instead of files, two things could be requested over the network.
1. A list of block numbers that make up a particular file.
2. A block's contents, by its id number.

An end user does a search for "The Worst Song Ever". A number of nodes may respond to the search. Each responding node responds with a list of blocks and instructions, like this...
The resulting file is length 2837889 bytes.
Block 1 consists of Blk_295837 XOR Blk_285211
Block 2 consists of Blk_9111ZQ XOR Blk_121193
Block 3 consists of Blk_11AAB1 XOR Blk_87222AZ XOR Blk_8922279
....etc....
Block 2852 consists of Blk_118sjK XOR Blk_ZZiww9
Resulting file checksum is ZQ29878228

Once your software re-assembles a file, it is truncated it to the length 2837889 specified in the list of instructions. All blocks are fixed length, like, say, 4096 bytes. But not all files are multiples of 4096. Therefore, the length specification.

So when doing a search, you enter a term, like "The Worst Song Ever", and get back one or more sets of instructions from responding nodes. (Note that responding nodes may not even contain any of the actual blocks in the instructions!)

Now, in BitTorrent like fashion, you can start requesting all of the blocks. Any node with a particular block can send it to you. Once you have that block, you can offer that block to anyone else by it's id number.

The block ID's could be something like the MD5 hash of the block's 4096 byte contents.

Each block will pass a statistical test for randomness. That is, each and every block appears to just be random bits. No block is part of the file "The Worst Song Ever". But by XOR'ing blocks together you reconstruct the file "The Worst Song Ever". No single part of the file will have come from any other node in the network.

Furthermore, any single block may be part of multiple files. Some unscrupulous organization could complain that "The Worst Song Ever" was made, in part, from Blk_295837, and therefore Blk_295837 must infringe the copyright on "The Worst Song Ever".

But Blk_295837 may also be part of another file such as The Bible, or The Declaration of Independance. So how could Blk_295837 be infringing if it is also part of the recipie for two things like The Bible, or The Declaration of Independance?

You may be able do download "The Worst Song Ever" much more quickly, because the blocks it is made from may be scattered all over the network. Partly, because those blocks may be part of the recipie to other files.

Each block can be sent as a UDP type message. Lack of receipt of a particular block simply results in eventually that block being re-requested.

The obvious drawback to this scheme is that downloading "The Worst Song Ever" requires two or more times the bandwidth, because every single part of it is constructed from XOR'ing a minimum of two blocks.

But this leaves unscrupulous organizations with problems. Which blocks are infringing? Is it infringing to merely provide a recipie in response to a search request? Because of the very nature of Mute, which node in the real world did a particular block or recipie originate from?

Another drawback is that this scheme seems to assume that nodes stay up for a long time. Otherwise, the blocks are pointless. If all nodes are short lived, then each node must always provide all of the blocks for any files it offers. This idea seems closer to FreeNet than Mute. This idea of blocks and recipies could be implemented on top of FreeNet.


Screenshot

Project Spotlight

ReciJournal

An open, cross-platform journaling program.

Screenshot

Project Spotlight

Veusz

A scientific plotting package.