GitBook: [2.0.0] 13 pages modified

SUMMARY.md

@@ -13,14 +13,8 @@
     * [Marine Repl](knowledge_aquamarine/marine/marine-repl.md)
     * [Marine Rust SDK](knowledge_aquamarine/marine/marine-rs-sdk.md)
 * [Tools](knowledge_tools.md)
-* [Knowledgebase](knowledge_knowledge/README.md)
-  * [Overview](knowledge_knowledge/knowledge_overview.md)
-  * [Concepts](knowledge_knowledge/knowledge_concepts.md)
-  * [Node](knowledge_knowledge/node/README.md)
-    * [Overview](knowledge_knowledge/node/overview.md)
-    * [Services](knowledge_knowledge/node/knowledge_node_services.md)
-  * [TrustGraph](knowledge_knowledge/trustgraph.md)
-  * [Security](knowledge_knowledge/knowledge_security.md)
+* [Builtin Services](knowledge_node_services.md)
+* [Security](knowledge_security.md)
 * [Tutorials](tutorials_tutorials/README.md)
   * [Deploy A Local Fluence Node](tutorials_tutorials/tutorial_run_local_node.md)
   * [Deploy A Private Fluence Network](tutorials_tutorials/running-a-fluence-network.md)
@@ -40,5 +34,4 @@
   * [IPFS](recipes_recipes/ipfs.md)
   * [Data Replication](recipes_recipes/data-replication.md)
 * [Research, Papers And References](research-papers-and-references.md)
-* [FAQ](faq_faq.md)
 

faq_faq.md

@@ -1,20 +0,0 @@
-# FAQ
-
-Coming soon. If you really need this section, contact us through any of the social media channels or Github.
-
-## Setting Up The Development Environment
-
-## Deploying A Node
-
-## Accessing A Network
-
-## Developing Modules & Services
-
-## Securing Services
-
-## AIR
-
-## HLL
-
-## TrustGraph
-

knowledge_knowledge/README.md

@@ -1,2 +0,0 @@
-# Knowledgebase
-

knowledge_knowledge/knowledge_concepts.md

@@ -1,44 +0,0 @@
-# Concepts
-
-Distributed, peer-to-peer networks serve a wide variety of constituents and causes but generally with the common goal of providing decentralization benefits: no single point of failure or control. Alas, the programming of and developing for peer-to-peer networks is hard. Distributed service deployment and composition are quite different from the current REST, or GraphQL, microservices model, where discovery tends to be an inherently centralized process. In distributed, peer-to-peer networks, endpoint-based service requests are discovery-based searches across peers comprising the network. The Fluence solution makes peer-to-peer development accessible and productive and empowers developers to quickly and efficiently develop, deploy, manage, and monetize distributed applications and backends.
-
-At the core of the Fluence solution are Aquamarine, a new, open-source language and runtime to choreograph distributed services into robust applications, and the Fluence Compute Engine \(FCE\), an open-source Wasm runtime. These Fluence innovations combine with [libp2p](https://libp2p.io/), [Kademlia DHT](https://en.wikipedia.org/wiki/Kademlia) at the peer-to-peer network level with the portability advantages of Wasm modules to provide developers with a modern, ergonomic p2p network and development model.
-
-For the purpose of mastering peer-to-peer application development and the Fluence solution, developers need to be aware of the following concepts in addition to the Fluence tools and runtimes.
-
-## Module
-
-Modules are logical units of code that can be used individually or in combination to create a service. In Fluence, modules are written in Rust and compiled to [Wasm IT](https://wasi.dev/) for eventual execution by the Fluence Compute Engine \(FCE\). Modules fall into three conceptual categories, which developers need to be aware of as the module type has a direct impact on service configuration:
-
-* Facade Modules
-* Pure Modules
-* Effector modules
-
-Facade modules expose the API of the services comprised of one or more modules. Every service has exactly one facade module.
-
-Pure modules perform computations without side-effects.
-
-Effector modules contain at least one computation with a side-effect, e.g., write to file or database, access eternal binaries, etc.
-
-## Service
-
-Services are logical compute units derived from linking of one or more Wasm modules. The linking of modules is facilitated by the Fluence Compute Engine \(FCE\) using a specially prepared configuration file. The configuration file which governs the
-
-* Order of instantiation
-* Permission to resources
-* Maximum memory allocation
-
-FCE uses a [shared nothing](https://en.wikipedia.org/wiki/Shared-nothing_architecture) linking scheme meaning that modules only expose functions explicitly marked to be publicly available while not sharing memory or any other resources. It should be further noted that services can **not** call on other services directly.
-
-## Blueprint
-
-The configuration map associating modules with service instantiations. This is a higher level construct than the low-level FCE linking described in the services section. Blueprints capture module names, blueprint name, and blueprint id. That allows the tracking and management of modules and services on a per-peer basis.
-
-## Particle
-
-A particle is a data structure combining data, service execution sequence, by means of an AIR script, and additional metadata. According to the AIR script specification, a particle travels through the network triggering execution at pre-defined service stops and peer nodes updating its data at every hop. Not surprisingly, the notion, implementation and processing of particles are a salient aspect of the Fluence solution.
-
-## Application
-
-An application in the Fluence solution is the "frontend" to one or more services and their execution sequence. Applications are developed by coordinating one or more services into a logical compute unit and tend to live outside the Fluence network. They can be executed in various runtime environments ranging from browsers to backend daemons with the help of Fluence command-line tools or the Fluence JS-SDK.
-

knowledge_knowledge/knowledge_overview.md

@@ -1,4 +0,0 @@
-# Overview
-
-Developing peer-to-peer networks and applications are pretty much the only way to decentralize control and curtail censorship. In addition, public peer-to-peer networks can be designed and augmented to offer decentralized fail-over protection and network-level data replication. while proving resistant to several attacks, including Sybil and Eclipse attacks.
-

knowledge_knowledge/node/README.md

@@ -1,2 +0,0 @@
-# Node
-

knowledge_knowledge/node/overview.md

@@ -1,2 +0,0 @@
-# Overview
-

knowledge_knowledge/trustgraph.md

@@ -1,4 +0,0 @@
-# TrustGraph
-
-Coming soon. If you really need this section, contact us through any of the social media channels or Github.
-

knowledge_node_services.md

@@ -1,4 +1,4 @@
-# Services
+# Builtin Services
 
 ## Overview
 
@@ -12,7 +12,7 @@ Each Fluence peer is equipped with a set of "built-in" services that can be call
 6. _op_ – basic operations on data deprecated - namespace for deprecated API Below is the reference documentation for all the existing built-in services. Please refer to the JS SDK documentation to learn how to easily use them from the JS SDK
 7. _deprecated_ - namespace for deprecated API
 
-Please note that the [`fldist`](../../knowledge_tools.md#fluence-proto-distributor-fldist) CLI tool, as well as the [JS SDK](../../knowledge_tools.md#fluence-js-sdk), provide access to node-based services.
+Please note that the [`fldist`](knowledge_tools.md#fluence-proto-distributor-fldist) CLI tool, as well as the [JS SDK](knowledge_tools.md#fluence-js-sdk), provide access to node-based services.
 
 ## API
 

tutorials_tutorials/add-your-own-builtin.md

@@ -1,6 +1,6 @@
 # Add Your Own Builtins
 
-As discussed in the [Node](../knowledge_knowledge/node/knowledge_node_services.md) section, some service functionalities have ubiquitous demand making them suitable candidates to be directly deployed to a peer node. The [Aqua distributed hash table](https://github.com/fluencelabs/fluence/tree/master/deploy/builtins/aqua-dht) \(DHT\) is an example of builtin service. The remainder of this tutorial guides you through the steps necessary to create and deploy a Builtin service.
+As discussed in the [Node](../knowledge_node_services.md) section, some service functionalities have ubiquitous demand making them suitable candidates to be directly deployed to a peer node. The [Aqua distributed hash table](https://github.com/fluencelabs/fluence/tree/master/deploy/builtins/aqua-dht) \(DHT\) is an example of builtin service. The remainder of this tutorial guides you through the steps necessary to create and deploy a Builtin service.
 
 In order to have a service available out-of-the-box with the necessary startup and scheduling scripts, we can take advantage of the Fluence [deployer feature](https://github.com/fluencelabs/fluence/tree/master/deploy) for Node native services. This feature handles the complete deployment process including