In the last days one could have seen some git code changes around HFS. Since we do not have a documentation yet (but in progress! :), here comes a small sneak&peek about HFS.
The HFS is a tree structured database which collects all information about the system. It collects and stores events and values. Also files could be uploaded into it and downloaded from it.
##Why is it needed?
Since HyperBorg is a decentralised system, one of the key component is to keep the statuses and values synchronized all around the system. The base concept here is to provided a central data structure that kept in sync transparently. This approach has some good sides: it is not relevant, who is modifying a given node, it would be propagated all over the system and will have effects. For example, you would like to have a family photo as a background and you want that to be changed in every minute.
You can deploy a HyperBorg instance on a Linux storage server that keeps pushing the family photos into HFS, which triggers a background change on a Windows or WebAssembly client.
##Why it is designed this way?
The HyperBorg system aims multiple operating systems: Linux, WebAssemly, Windows and Android.
These operating systems have different constraints. For example WebAssembly cannot reach out to the local filesytem, thus it can rely only on its network communication (and that is also somehow limited: COEP & co) To minimalize OS related differences, this database is kept in memory and it acts as a quasi-filesystem-virtualization while keeping the possibility for given nodes to attach HFS to real file sytems.
##Snapshots?
One of the good side of the HFS, that it stores all information in an isolated model (QModel). It has two major advantage: it is possible to attach a treeview anytime, so all of its content is visible and modifiable real-time. The second advantage is that the whole “database” could be saved at any given point, thus could be backed up or analyzed in a convinient way.