A Vision of A Global Operating System: Filesystem
Imagine a future Ethereum EVM Operating System that has its own filesystem. The EVM would have access to the directory tree and set the privileges by consensus. The pointer to each file is available in the global scope. It could even have transparent “drivers” to various decentralized file storages: Swarm, IPFS, etc.
How could you start the directory structure for such a filesystem? Of course, you will want to begin by adopting a structure that has already achieved consensus through use, from desktop OSes like Linux, MacOS, or Windows. Then evolve the structure further by governance.
Let us look at the current high-level filesystem structures that are currently used.
Linux directory structure
A more detailed description of the latest standard can be found at http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html.
/ — Root directory
/bin — Essential command binaries
/boot — Static files of the boot loader
/dev — Device files
/etc — Host-specific system configuration
/lib — Essential shared libraries and kernel modules
/media — Mount point for removable media
/mnt — Mount point for mounting a filesystem temporarily
/opt — Add-on application software packages
/run — Data relevant to running processes
/sbin — Essential system binaries
/srv — Data for services provided by this system
/tmp — Temporary files
/usr — Secondary hierarchy
/var — Variable data files
/home — User home directories (optional)
/root — Home directory for the root user (optional)
/lib<qual> — Alternate format essential shared libraries (optional)MacOS directory structure
A more detailed description of the latest standard, APFS, can be found here.
/Applications — Apps intended for use by all users of a computer
/Library — App-specific (or system-specific) resources
/Network — List of computers in the local area network
/System — System resources required by macOS to run
/Users — One or more user home directories
/bin — Essential command-line binaries
/dev — Essential device files - e.g. mount points
/etc — Host-specific configuration files
/sbin — Essential system binaries
/tmp — Temporary files created by apps and the system
/usr — Non-essential binaries, libs, header files, data
/var — Variable data files - e.g. log files
/Volumes — Contains a subdirectory for each mounted disk/Users/Applications — User-specific apps
/Users/Desktop — Items on the user’s desktop
/Users/Documents — User documents and files
/Users/Downloads — Files downloaded from the Internet
/Users/Library — User-specific app files
/Users/Movies — User’s video files
/Users/Music — User’s music files
/Users/Pictures — User’s photos
/Users/Public — Content the user wants to share
/Users/Sites — Web pages used by the user’s personal site
Decentralized Filesystem
However, most of these folders are meant to be used internally, by various services and applications, when they are installed on an operating system. They might not even be touched by a normal user.
In our case, we can consider that we are always using 3rd party services and apps that have a clear “mounting” point and are system-independent. We do not need to install them. These dapps can be hosted on Swarm, for example, and the user can play with them directly or download them on his OS.
We can omit for now the system-driven folders and focus more on functionality-driven user needs. A starting point for our filesystem structure could be:
/apps — Pointers to independent applications
/data — Pointers to public use data
/sources — Pointers to various resource sourcesPersonal User Files
While the above folders keep pointers to general, publicly used resources, the personal and private resources of each user can be encrypted and hosted fully off-chain. They can be mounted on the fly in the Filesystem App’s /homedirectory, like any other folder that is registered on-chain.
Imagine having encrypted data on your devices that can only be decrypted with a set of private keys that you store in a wallet. If you don’t have the wallet, you can still access the rest of the files, but not the encrypted ones. If you do have the wallet, it can connect to Swarm, to your /home folder, sync your files and decrypt them.
This is a step up from your OS encryption systems, that for example, Apple provides. On MacOS, you can encrypt your entire hard drive with FileVault, but this means you cannot access anything without knowing the password or the recovery key. The password itself can be a weak link in the chain — users usually memorize it, so they frequently choose words that they can remember and are easy to find by brute force.
Now imagine mounting your private folders not only on your computer’s OS, but also in your browser. Brave and Opera have already started to integrate cryptocurrency in-browser wallets, so having a filesystem app that connects to your browser wallet and decrypts your files based on your private key is technically sound now. You can have your work environment replicated on any computer if the browser is trustworthy enough.
Global Filesystem
But let’s go back to our general filesystem idea. There are a couple of points worth highlighting now:
- you can have on-chain registration & file management for public, high-level folders
- you can have off-chain file management for private resources and public resources that do not need consensus
- off-chain resources can have a pointer to them on-chain, if needed
Why would we need a publicly governed filesystem component?
By having the backbone of the filesystem on-chain, users can collaborate with one another and they can set different consensus rules for each file or folder.
If we have a global system for registering our resources, we can integrate them within a larger ecosystem. This is what Github has also done for git. And a filesystem with permissions and versioning is the base for git itself.
The filesystem can be used for actual governance resources. Think about publicly available government laws or even rules for various groups of people. You can eventually add plugins for voting, discussing and planning these rule proposals — both on and off-chain.
/apps
The filesystem can store pointers to various applications that we can use. This is a general registry of apps, where users can search and choose the apps that they want to add to their personal filesystem, as soft links.
Imagine opening your workspace in a browser and having at hand your preferred/starred applications, along with a simplified app categories tree, based on what apps you chose.
You can always go to the public app categories tree and add more.
Then, you can open an app (hosted on Swarm), use your browser wallet to connect to it and use it. You can store on your personal filesystem any side effects produced by that app. Remember the Linux / MacOS folder structure? Apps integrate with an OS by knowing where to store various configuration, cache, data etc. files. Your Swarm app could also do that and store these resources on your personal filesystem.
/data
As mentioned above, we need a place to store pointers to publicly available data — governance proposals, research articles, statistics data, etc.
This folder can also exist at your /home/data and keep pointers to your app data and anything else that your heart wants.
/sources
This folder can keep pointers to actual code sources that make your environment run. Libraries, apps, smart contracts, etc. These pointers will be referenced in all the places they are needed. Remember the /apps folder? Each app can internally use pointers from /sources and share the resources with other apps (like MacOS does with /Library/Frameworks).
One more thing
This vision was inspired by our work on dType — a Decentralized Type System for EVM. Read about it here: https://medium.com/@loredana.cirstea/dtype-decentralized-type-system-functional-programming-on-ethereum-4f7666377c9f.
We are currently researching filesystem types and adaptors, that can be globally reused by projects. Work in progress: https://github.com/pipeos-one/dType-fs. But this will be covered in more detail in the next blog post.
Want to give feedback, propose types or just say hi? Head over to https://gitter.im/pipeos-one/dType.
