Projects / MUTE File Sharing

MUTE File Sharing

MUTE File Sharing is an anonymous, decentralized search-and-download file sharing system. Several people have described MUTE as the "third generation file sharing network" (From Napster to Gnutella to MUTE, with each generation getting less centralized and more anonymous). MUTE uses algorithms inspired by ant behavior to route all messages, include file transfers, through a mesh network of neighbor connections.

Operating Systems

Recent releases

  •  23 Apr 2007 18:02

    Release Notes: This release fixes bugs in MUTE's initial connection to the network upon startup. MUTE has also been upgraded to Crypto++ 5.4, so it should now compile using GCC 4.1.

    •  07 Jun 2006 12:07

      Release Notes: This release adds several major features that have been suggested by the community, including multi-source downloads and download queuing. A new "anonymous friends" feature has been added, complete with human-readable mnemonics generated from each virtual address. Network scalability has been improved, and several security issues have been fixed. Changes have been made to the cryptography code so that it will compile with the latest version of GCC.

      •  18 Apr 2005 15:22

        Release Notes: A widely-publicized anonymity hole was fixed by replacing tail chains for search messages with tail trees. The utility counter behavior on search messages was changed to mimic traditional TTL schemes, thus fixing another similar anonymity hole.

        •  28 Dec 2004 19:26

          Release Notes: Major features include resumable downloads and a "grab hash" button. General improvements include code that makes killing connections and canceling downloads instantaneous.

          •  12 Oct 2004 15:54

            Release Notes: This release adds a translation system.

            Recent comments

            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
            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.


            Project Spotlight


            A Fluent OpenStack client API for Java.


            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.