Currently IPFS object are static, immutable and unchangeable without changing the CID (content identifier). CID otherwise known as a multihash is a unique content identifier to a particular set of data. Typically most IPFS file hashes start with Qm. This static identifier is very useful for preserving a particular record, such as a transaction ID, a JavaScript library, images (I generally assume they won't change any time soon). It being static makes it also secure when being used to prove the validity of the data itself. However, this presents an issue when file mutability is necessary for an application, for example: collaborative text editing, editable notes, collaborative development (git/GitHub), an updatable Dropbox etc.
Currently there are a few systems designed to solve this issue. Blockchain is one textiles (an IPFS variant) is designed to function as a social media system. If using a Blockchain the system will always be tied into a large database, and high transaction fee regardless of blockchain cause havoc. Which is definitely not an option. Blockchains can be used for security/proof of ownership, but should not be built into the core functionality of a mutable file system.
Summary
Choose the name because IPFS MFS already exists, it acts as an API to interact with IPFS files in a mutable way. It does not provide true file mutability. That is why I am building Truly mutable file system. TMFS is built on top of orbitdb and IPFS. Orbitdb is a database system built on top of IPFS. Orbitdb has a couple of different type of database, TMFS uses a append only (write only) log and keyvalue store for current file states and miscellaneous data. A binary XOR operation calculates the different versions of a file, similar to git. This diff is then added to the append only log. When nodes receive this change, TMFS will calculate the current static hash, headhash and diff hash (points to XOR data). This is the basis for all TMFS files.
Repo: this is where mutable and static file links. Each repo has a unique ID based off of orbitdb log and keystore address. When opened, repo can be represented as an interactable JavaScript object.
TMFSObject: an individual file/object stored on TMFS. Can either be static or dynamic. Dynamic contains last transaction related, current head, current static hash, and path. Can be represented as a interactable JavaScript object. There will be an event emitter that is triggered when modifications are detected.
TMFSAction: an individual transaction designed to update a static or dynamic TMFSObject. This is posted on the append only orbitdb lot. Static simply contains the current hash. Dynamic contains past transaction, path, XOR diff IPFS hash, a static hash (this can be calculated from diff + past static content).
This is a document in the works. Concepts need to be expanded on and consolidated. Source code will be released in the future once standardized API has been created and code clean up. Status is POC. Grammer must be corrected and fully understandable. (And of course not being written on a phone)
Any questions would be appreciated to clear out possible confusion.
-- vaultec
