FreenetWiki: FreenetFS - the Freenet Filesystem

FreenetFS - the Freenet Filesystem

Abstract

FreenetFS is an implementation (currently under development) of an experimental filesystem (or 'virtual disk' to windows folk) which maps Freenet accessibility into a virtual mountable filesystem.

The benefits of such a framework would include:

allow applications such as OpenOffice.org to access freenet without modification, eg you can anonymously write a document, save it to freenet, and make it accessible to others
take greater advantage of the USK@ keytype - which allows for ad-hoc updates to any members of a tree of files
present a language-independent interface to freenet
wrap freenet access details, such as FCP port
owners of 'directories' can publish a key, and allow others to mount these directories in readonly mode

An example application of freenetfs:

Xang, the pro-democracy blogger, needs to be careful about her mainstream web accesses, so can't be caught visiting freenetproject.org, not even via a proxy
Toad can 'own' a freenetfs directory, eg /freenet/software
With each build, Toad can copy the jar to /freenet/software/freenet-cvs-snapshot.jar
Xang can then do 'cp /freenet/software/freenet-cvs-snapshot.jar' to her freenet directory

Sources

Technical Overview

The initial implementation of FreenetFS (aka 'FreeDisk') uses the FUSE userspace filesystem framework, and is written in Python (for speed/ease of development, maintainability, and given Freenet request turnaround time, the overhead of Python becomes negligible).

I can see no reason at this point why FreenetFS would need to be reimplemented into other languages such as C or Java.

Initial versions will only run on platforms supported by FUSE, predominantly the major Linux distros.

There are 'virtual disk' SDKs for Windows, so some keen developer might like to wrap the FreenetFS core class to work within a Windows vdisk environment. Python is an easily extendable and embeddable language, so it should be no trouble to create thin Python shims within a windows vdisk framework, so the main FreenetFS codebase should be usable in both Windows and *nix scenarios.

Directory/File Hierarchy Model

So far, the proposed hierarchy is along the lines of:

/
- The root of the filesystem. All freenet operations are performed by reading from, writing to and creating files and/or directories
/keys/
- a pseudo-directory for direct reading and writing of physical freenet keys, for example:
  - /keys/KSK@fred, /keys/KSK@fred.mimetype - the data and mimetype of key KSK@fred, respectively.
  - Typically, to create a new key, you would write a mimetype to /keys/KSK@fred.mimetype, then you'd write the data to /keys/KSK@fred. Upon closing the file after write, FreenetFS would go ahead and physically insert the key. If you don't first write the mimetype, a guess attempt will be made based on the URI you write to (for example, writing to KSK@gpl.html would default the mimetype to "text/html".
/keys/newchk
- For inserting CHKs. Read from this file to get a unique 'insert id' (say, nnnn) for an upcoming CHK. Then, write the mimetype to /keys/nnnn.mimetype. Then, write the key's data to /keys/nnnn and close the file. Read the resulting CHK URI (say, 'CHK@yadayada') back from /keys/nnnn. Thereafter, you or anyone else on freenet using FreenetFS can read the mimetype from /keys/CHK@yadayada.mimetype and the data from /keys/CHK@yadayada.
/privatekeys/
- This pseudo-directory is for inserting SVK, SSK and USK keytypes - keys where the insert URI differs from the retrieve URI. Write mimetype to /privatekeys/SSK@blah/somename.mimetype, then write data to /privatekeys/SSK@blah/somename.

/cmd/
- A pseudo-directory for sending commands to the filesystem itself, and receiving responses
/cmd/jobid/
- Read from this file to obtain a 'jobid', which is a guaranteed unique filename
/cmd/nnnn
- nnnn is a job id allocated from a prior read of /cmd/jobid. Write to /cmd/nnnn to post a command to the filesystem, and read back from it to get the response
/cmd/genkey
- Read from this pseudo-file to get a new SVK/SSK/USK keypair. This keypair will come back as two lines, the public key followed by the private key.

/usr/
- contains a set of named subdirectories, where the mapping of physical freenet key to logical name is governed by config file settings, such as:

[userdirs]
fred=freenet:USK@privateblah1/name
mary=freenet:USK@privateblah2/name

So reads from '/usr/fred/' become a read to '/keys/USK@publicblah1/name, and writes to /usr/fred become a write to '/privatekeys/USK@privateblah1'. The beauty of using USK keys here is that if you write anywhere in your own tree, a whole new ClientPutComplexDir will occur, and the entire tree will be updated as part of the next filesystem sync.

Why choose /usr/ instead of /home/ for user directories? /usr/ has another "meaning" in the Linux world and since you are targeting that platform (FUSE), it seems just natural to choose /home for user directories