OFFSystem

The Owner-Free File System (OFF System, or OFFS for short) is a peer-to-peer distributed file system in which all shared files are represented by randomized multi-used data blocks. Instead of anonymizing the network, the data blocks are anonymized and therefore, only data garbage is ever exchanged and stored and no forwarding via intermediate nodes is required. OFFS claims to have been created with the expressed intention "to cut off some gangrene-infested bits of the copyright industry."

History
OFFS development started within the hacktivism group The Big Hack in 2003 by the hackers Cheater512, CaptainMorgan, Aqlo and WhiteRaven. In 2004, a rudimentary version was finished, written in PHP, which was distributed as two demo CDs. Following these, SpectralMorning re-implemented the functionality in 2004 in C++, which led to the current "mainline" OFFS client.

On August 14, 2006, CaptainMorgan posted a letter of "closing" addressed to the "Copyright Industry Associations of America", such as the RIAA and MPAA, stating that they have created OFFS with the purpose of ending "all of your problems with consumer copyright infringement."

Today we announce a massively distributed copy-less file system. A place where all content is available instantly, anonymously and to everyone, without breaking any laws. Today we announce the Owner-Free File System. An island of sanity in your sea of madness.

In 2008, the network consisted of around 50 nodes. On April 11, 2008, a beta test was held with a network size of over 100 nodes. Since SpectralMorning stopped work on OFFS in late 2008, only minor bug fix releases were made to mainline OFF.

Starting from 2007, an alternative, but compatible client was developed, called BlocksNet. Written in Ruby and well-maintained, it saw major improvements over recent time. It has been under development until 2011.

The client OFFLoad is a fork from mainline OFFS, which seemingly adds no features. Reasons for the fork are unclear. Another distantly related program is Monolith, which uses a similar principle to OFFS. It was created after OFFS and features no multi-use of blocks and no networking.

Functional Principle
The OFF System is a kind of anonymous, fully decentralized P2P file sharing program and network. In contrast to other anonymous file sharing networks, which derive their anonymity from forwarding their data blocks via intermediate network nodes, OFFS derives its anonymity from anonymizing the data files. Thus, the system refers to itself as a brightnet to contrast its method of operation with that of private file sharing systems known as darknets and with traditional, forwarding anonymous P2P programs.

Store Procedure
In order to store a file into the local OFFS storage, resp. block cache, choose the tuple size $$t$$ (default 3), split the source file $$s$$ into blocks $$s_i$$ of size 128 KiB (pad with random data to fit) and for each, do the following: Finally, store the descriptor list in its own block (or blocks, if the list is larger than 128 KiB) and insert these blocks $$d_i$$ into the block cache and generate an OFFS URL for referencing the source file and output it to the user or into the local OFFS URL database.
 * 1) Select $$t-1$$ blocks for use as randomizer blocks, or for short, randomizers, from the existing OFFS cache, which have not been used in previous iterations. If not enough randomizers exist in the cache, generate them using a random number generator.
 * 2) Calculate $$o_i = s_i \oplus r_1 \oplus r_2 \oplus ... \oplus r_{t-1}$$ and store the resulting block $$o_i$$ in the cache, $$\oplus$$ being the XOR operation.
 * 3) Update the descriptor list, which contains the information on how to restore each source block $$s_i$$, with a new entry, which is a set of size $$t$$: $$\{o_i, r_1, r_2 ... r_{t-1}\}$$.

Retrieve Procedure
To retrieve, obtain the descriptor block or blocks and for each contained set of size $$t$$, do the following:
 * 1) Obtain the listed blocks $$b_1, b_2 ... b_t$$. Though they have no identity any more at this point, they could be called $$o_i, r_1, r_2 ... r_{t-1}$$.
 * 2) Perform $$s_i = b_1 \oplus b_2 \oplus ... \oplus b_t$$ and output the resulting source data block $$s_i$$ to a viewer program or to storage.

Anonymity
OFFS derives its anonymity from the following:
 * 1) No source file content is stored in the block cache, only blocks that consist of probably random data.
 * 2) No source file content is searched for on the network.
 * 3) No source file content is transmitted over the network.
 * 4) (No block in the cache is copyrightable by itself, because numbers - however large - cannot be subject to copyright (and neither would be small parts of a copyrighted work).)
 * 5) The original uploader remains unknown, because blocks are dispersed into the network and therefore downloading is done from multiple sources.
 * 6) During disperse, the usage of the block cannot be stated, because blocks are re-used in other contexts to re-assemble other source file blocks. (TODO that is true also for retrieve)
 * 7) (No block can be copyrighted without logical contradictions, because blocks used for re-assembling a source file block are re-used for re-assembly of other source file blocks. It is undecidable who would have copyright on a block, which has several meanings. Everyone would have copyright on everything.)
 * 8) If the OFF-internal search function is used, search terms are untraceable to its originator, because the search request is forwarded to the next node and its results back to that node instead of directly to the originator. It is thus not possible to decide whether a node is the originating node or a node doing a search request on behalf of another node.
 * 9) TODO add digital copyright note

Efficiency
Because OFFS anonymizes the data blocks being exchanged instead of the network, no forwarding via intermediate nodes is required. Therefore, this method has a higher degree of efficiency than traditional, forwarding-based anonymous P2P systems.

The forwarding method requires that a data block is uploaded and downloaded several times before it reaches its destination, which happens between 5 and 15 times., which, according to the resulting formula $$s * (hi + ho + 1) * 2 - s$$, is equivalent to an overhead of 900 to 2900%, while the overhead of OFFS without optimizations is about 200%. ($$s$$ is the source file size, $$hi$$ the inbound tunnel length and $$ho$$ the outbound tunnel length. Plus 1 for the hop between the Outbound Endpoint and the Inbound Gateway.)

Efficiency can be further increased:
 * 1) Re-use some of the result blocks $$o_i$$ and randomizer blocks, which reduces the overhead to $$s * (t-1) * \frac {e}{100}$$, where $$s$$ is the source file size, $$t$$ the tuple size and $$e$$ the percentage of unrelated blocks used in the randomizing step during the store procedure. By default, $$e$$ is chosen 75 (and $$t$$ chosen 3), which leads to an overhead of 150%.
 * 2) If some of the blocks required to fully retrieve, resp. re-assemble, the source file are already present in the block cache from other transfers or stored files because of the multi-use nature of OFFS blocks, the degree of efficiency is increased further.
 * 3) Use of the targeted store feature leads to the blocks of specific other files to be chosen as randomizers for this file with higher probability and therefore a reduction in overhead. This is especially useful when storing a group of related files.