DFS (Distributed File System) is an application-oriented distributed storage system.
The idea is simple: Your files belong to you and must remain under your control.
The concept is similar to WebDAV, but both systems pursue different goals.
The objective is to overturn the established status quo where the software provider (SaaS) becomes the de facto owner of the data and its workflow.
While in WebDAV or any proprietary system it is you who authenticates against the storage, in DFS it is the application that pairs with a specific workspace to which you grant permission.
This allows applications to work directly on files that remain under your control without the need to transfer storage ownership to third parties.
Furthermore, the application server does not need to access your files or know your storage credentials. The pairing takes place between the application built in the browser and your DFS, and subsequent communication is carried out using temporary credentials.
To give a simple example:
To open a document in your text editor, there is no technical reason why the developer of that editor should own or control that document.
Nor is it an absolute truth that an FTP, WebDAV, S3, NFS, sshfs repository can only be accessed through the SaaS server...
A workspace is backed by a local directory, but this directory can be mounted over remote files on any system.
Sharing, collaboration, and publishing:
When files are managed by an application, sharing, collaborating, and publishing depend entirely on the features that the SaaS has decided to implement.
DFS decouples both responsibilities.
Applications work with files, but they do not manage them. You manage them.
Each workspace can be configured as public or private, and it is you who decides how to use it and with whom to share it.
This allows sharing folders between work teams, maintaining private repositories, or publishing content for public access using exactly the same mechanism.
A company can publish technical documentation for its products. A university can share models or libraries. A researcher can distribute their papers. Each organization maintains its own files and decides what to share.
DFS decouples file management from the application.
Taken further, you could host your social media posts on your own DFS, and different SaaS providers would compete to see who indexes them better; true competition would exist because there would be no de facto data owner.
Dependencies:
Working connected to the Internet while continuing to rely on files from a single location (your computer or the application server) is becoming increasingly anachronistic.
For years, we have been using links to access pages, services, and resources distributed across the entire network.
DFS utilizes this fundamental concept of the Internet.
Just as you can share files, you can also use those that other people, companies, or institutions have decided to publish.
In addition to direct linking, DFS incorporates a dependency system that allows declaring dependencies between repositories.
Dependencies are recursive. If a library depends on other repositories, these will be automatically discovered by the application.
For example:
My DFS
└─ Library B
└─ Library C
The result is a model closer to the Internet than to a USB drive: each organization maintains its own files, publishes them when it deems appropriate, and other projects can use them directly from their source.
Work continuity
Another element that the file system must support in order to decouple itself from the application is the open file session itself.
This allows recovering the working environment even after closing the application, restarting the browser, or switching computers without consulting the application.
The system distinguishes between files you are editing (active session) and files you have only included as a dependency. The latter can be safely cached because they do not change during editing.
Authentication and security
DFS uses a pairing system between the application and the workspace.
We start from the premise that the user knows the token (workspace identifier) and the access password of their DFS.
The system consists of four phases:
1.- Pairing:
The application password is used to generate:
hash_base = hash(token + pass_app)
Using the DFS password, this hash_base is stored within the DFS itself.
From this moment on, the DFS password is no longer required and does not circulate over the network anymore.
The application discards both the pass_app