In the "Hello CYFS" series of tutorials, you have understood the basic definitions of NamedObject and NamedData, and found that FileObject has a ChunkList, DirObject is similar to ZIP format, and saves a Map in its Desc to refer to FileObjectId. The Key of the Map is of type String , represents the internal path, and Value is ObjectId, which points to the referenced FileObject. Under the design of DirObject, changes to any files it contains will cause changes to FileObjectId, and finally to changes to DirObjectId.
Therefore, we can either use cyfs://o/$owner_id/$file_obj_id or cyfs://o/$owner_id/$dir_object_id/$inner_path to refer to the same file. The difference in the verification logic is that the second Link will not only verify the contents of the FileObject, but also verify that the FileObject is not a DirObject. This is often discussed with today's blockchain: "Whether a transaction is on the chain" has an equivalent kernel. The so-called transaction on-chain is to judge whether the transaction is stored in a block, and this block must ultimately be stored in a pass through Maintained by the consensus algorithm, only the blocks in the list of blocks that allow Append operations are credible.
On the other hand, all web developers have experienced the complete state expression capabilities of json/xml. The most important data structure in json/xml, and a range of dynamic languages, is the container. There are three basic types of containers: Map, Set, and Array. The elements of the container can be any object or container. Such a recursive structure can express all structural information. Therefore, whether from the perspective of expressing the overall state or from the perspective of expressing the completeness of structured information, CYFS must provide a standard Named Object container, which we call ObjectMap (although it is called Map, its implementation is It includes Map, Set, Array), which is one of the key and commonly used standard objects of CYFS. The usage logic of this object is similar to json, the difference is that its element can only be ObjectId. That is, this is essentially a container for NamedObjectId s.
The following figure is a typical ObjectMap structure:
If there is a json structure
{
"sub_path" : {
"sub_sub_path" : element_obj
}
}The pseudocode for accessing ObjectMap looks like this
map_obj = cyfs.get_named_object(objid);
sub_map_id = map_obj.get("sub_path");
sub_map_obj = cyfs.get_named_object(sub_map_id);
element_obj_id = sub_map_obj.get("sub_sub_path");
element_obj = cyfs.get_named_object(element_obj_id);If this structure is expressed in DirObject, it looks like this. Compared with DirObject, ObjectMap is a more general design (you should not refer to another DirObject in DirObject), and it has a wider range of application scenarios. It should be used in priority at any time. ObjectMap.
{
"sub_path/sub_sub_path" : element_object
}If you have some understanding of how git works, you can find many similarities in the kernel between the two designs. In the following chapters, we will gradually expand the introduction of how to use ObjectMap in different scenarios. For now, it is enough to establish the basic concepts.
From the above chapter, we know that a NamedObject can be referenced by ObjectMapId + sub_path, it should look like this
cyfs://o/$owner_id/$map_id/sub1/sub2
From the experience of git, we require the state preservation on OOD to follow a specification: all states are stored in a root ObjectMap (RootState), and the system tracks the latest version of this and ObjectMap through a configuration file, then you can pass the following URL to express a mutable state more semantically.
cyfs://r/$owner_id/sub1/sub2
We call this URL the CYFS RootState URL, or R Link for short. Through the CYFS name system, after binding a name to a $owner_id, you can get a human-friendly URL that does not contain any hash value: cyfs://$username/sub1/sub , CYFS browser click the following Steps to parse the semantic URL
Step1: Get the OwenrId corresponding to the username through the name system
Step2: Get ZoneConfig through OwnerId, get OOD Device
Setp3: Connect to OOD Device and request the current RootState ObjectMapId (Read rootstate HEAD)
Sete4: Enter the traditional O Link parsing process, parsing cyfs://o/$owner_id/$map_id/sub1/sub2
Based on the CYFS RootState URL, we define a series of basic CoreObject semantic specifications, such as cyfs://r/$ownerid/user/face pointing to the current avatar file of a specific user. With the flexible use of R Link and O Link, Web3 content can be better connected to each other. Since any R Link can be converted to an O Link at one moment (we call this a Pin operation), one can always choose to use an O Link to establish a trusted connection between content.
The element stored in ObjectMap can point to the next level ObjectMap, which forms a "tree structure". This is similar to a traditional file system: every named object in the tree can be represented by a unique path of "/key1/key2/key3". In this structure, the change of any named object will cause its ObjectId to change, and eventually the ObjectId of each layer of ObjectMap will change. Once the ObjectId of the top-level ObjectMap is obtained, the entire tree structure can be reconstructed credibly layer by layer. This first level ObjectMap is called "RootMap". With the basic abstraction of the file system, we can provide App developers with a state storage layer that is more in line with the traditional mental model, and use the basic logic of the file system to isolate the access control layer and application state. The abstraction of the state of the decentralized application service running on OOD is the design of the application data directory. But unlike traditional file systems, RootState FileSystem provides trusted storage.
In contrast to the state storage of smart contracts, Ethereum provides KV storage based on storage tries for each smart contract to manage application data. Semantically, CYFS requires each DEC App to build the App's RootState based on the RootMap. We call this design the 'Named Object File System'. This is also one of the most important basic services on OOD. The RootMap of different apps can be pointed to by $app_id, which together with the voice directory constitutes the root file system RootFS on OOD.
The figure below shows a typical RootFS on OOD
{RootFS}
├── user
│ └── face
├── $appA_id
├── $appB_id
│ ├── message_list
| | └── msg_title
| └── nft_list
| └── nft_title
├── system
│ ├── zone_config
| └── acl
└── caches
└── cache_objA
DEC App is a proper term created by us, referring specifically to the decentralized Internet application defined by CYFS. DEC is the abbreviation of Data Exchange Contract, which is the development of Smart Contract by CYFS, which refers to trusted computing running off-chain (L0). We will give a special introduction to DEC later.
From the user's point of view, the experience of using the DEC app is not very different from today's mobile app. Find the app you like through the app store, click Install, and you can use it after the installation is successful. The experience of the decentralized nature of the DEC App mainly lies in
- As long as the link of the application is obtained, the instant application can be installed successfully even if it is not on the App Store.
- After the DEC App is successfully installed, it can run all the time, and there is no concept of the development team stopping the server. This is because when the DEC App is installed, all resources have been completely saved on the OOD, and the backend (we call the DEC Service) that the DEC App depends on runs on the OOD, and the development team has no control.
- Users can always choose their favorite historical version of DEC App without being forced to upgrade
- The user has absolute control over the permissions and data of the DEC App
- DEC App developers will try their best to share data with the same semantics in different applications.
From the developer's point of view, DEC App has the following characteristics
- Cloud-integrated development. Use one language typescript to complete all development from front-end to back-end
- Serverless, the backend of the DEC App is installed on the user's own OOD, no matter how many users the DEC App has, the developer does not need to purchase a server
- OOD's RootFS storage engine achieves high reliability and high availability, and developers can focus on the development of product logic
- The release of DEC App is completely decentralized, and developers always have the right to release and update their own DEC App.
As shown in the figure above, the development team builds the AppObject with the main NamedObject, and the obtained ObjectId is the dec_id. AppObject must be on the chain, and its Body contains all historical versions of AppObject, the default version, and the version corresponds to DirObjectId.
The user installs the application using cyfs://o/$owner_id/$dec_id, and after selecting the version, the corresponding DirObject will be downloaded from the AppObject's developer OOD to his own OOD. The OOD System will create a separate RootState for the DEC Service during installation.
Starting the DEC App is to let the OOD System start the corresponding dec service container and load the docker image packaged in DirObject. After the startup is successful, the user can see that the DEC App is running.
Users can always access client-side resources already saved on OOD through the app store, most commonly by opening a Web Page in a CYFS browser.
The CYFS App URL points to the inner page of the DEC App Client, and its full form is
cyfs://$dec_id.a/$dir_obj_id/inner_path/page.htm&parm1=xxx
- We put dec_id in the domain name field to better utilize the browser's domain security control.
- Open this page in the CYFS browser, if $dec_id is not installed, it will trigger an interactive installation process, if it is installed, it will openversion page.
- $dir_obj_id is not filled in most of the time, which means to open the current version of inenr_path/page.
- We believe that most of the new users of DEC App are brought by A Link sharing.
Through the study of this chapter, you have a basic understanding of some key concepts of the CYFS DEC App. In the following chapters, you will gradually learn more details based on actual combat, and finally fully master the development of DEC App.