Work in IPFS with a human face
Few have heard about IPFS, even more few got to the detailed study. And very much units plunged into the project more deeply.
In short, IPFS is a chimera created from the technologies underlying git and bittorrent, with one feature - object addressing by content ( CAS ).
Any object, file, or user data is hashed, and the resulting hash becomes the address of this file in the IPFS system. Further, this content may be requested by other nodes of the network, and it will spread across the planet, and ideally, will never disappear again, being accessible by hash. Immunity of objects in the system also follows from this property, because any change in the content creates a new hash address in the network.
Typical object reference: http://ipfs.io/ipfs/QmPQGujZ4K1xPNNcCjBWMoSuYrcJae43dukJP51mbfftDK
But this approach has a minus: a person does not remember hashes. An ordinary person is more accustomed to having a hierarchical file system or tag cloud with the ability to filter.
File system
For this, the ipfs developers have provided the ability to save graphs of objects that look like files and directories to the network, files and directories will have a human name and a familiar file path.
The opportunity is good, it gave life to the next opportunity - hosting static sites directly on the ipfs network, like this https://ipfs.io/ipns/i.ocsf.in/ .
With all this, it is clear from the ipfs documentation that the maximum that a user can do with this virtual file system is to mount the contents of the object database at the start of the local daemon. Perhaps this is enough for some tasks. But for more or less full-fledged work with the FS you need more features.
Of course, in order to fully virtualize the file system, we would need to develop our own driver for fuse, or for Windows dokanY, this is a fascinating process, but for a start, you can do something simpler to evaluate the capabilities of the network and the IPFS file system API.
And what mechanism can work approximately in all ecosystems? Web protocol. For example, WebDAV. In Windows, there is a built-in client, in linux there are in the main graphic file managers and in the console via cadaver.
We will build a ziggurat. On golang. And then, perhaps, on node.js.
Implementation
Out of the box in golang, a webdav service is available with basic functionality and the ability to build your own file system implementation. The interface almost coincides with the file system interface in the standard os package.
But there is a problem. Immunity of IPFS objects leads to the fact that any change in the file system provokes a complete restructuring of the entire hierarchy of directory objects. Together with the root. Unfortunately, this will require storing the root hash in an external (relative to IPFS) storage. And, for now, this is the only configuration parameter of our virtual file system.
WebDAV also supports file locking system. It is used to share the FS of many users. So far, the problem of access to a constantly changing root directory remains unsolved, which changes with every change in the file system.
WebDAV-middleware is implemented as a daemon, which runs next to the go-ipfs daemon and interacts with IPFS via http-api, which imposes restrictions on speed. Therefore, in the future, it makes sense to work with the ipfs network by directly compiling your modules into a go-ipfs daemon.
Also, the virtual FS file object structure built into IPFS lacks the ability to store user attributes of files and directories. A crutch can always be invented, but this is not the way for products that will be even a little steeper than this research project.
findings
During the development process, some weaknesses in WebDAV support in some operating systems, for example, were revealed. Also, WebDAV itself does not work very quickly when working with a large number of small files. And on the IPFS network, there are problems with large files; downloading them to the system takes a relatively long time. For wider use of the IPFS system, along with WebDAV, other drivers are needed to access the file system inside IPFS. Moreover, in recent versions, the functions of a mutable file system have appeared in the API, which is still undocumented, but it will probably give the necessary speed and convenience of work.
Links
')
Source: https://habr.com/ru/post/310554/
All Articles