GitBook: [2.0] 56 pages and 2 assets modified

README.md

@@ -1,12 +1,20 @@
 # Introduction
 
-Fluence Labs builds distributed networks, development tools, components and support systems to allow developers to efficiently and reliably build, operate, maintain, and monetize distributed and decentralized services and applications. An integral component of the Fluence solution is [Aquamarine](https://github.com/fluencelabs/aquamarine), a programming language enabling peer-to-peer coordination for distributed applications and backends.
+Fluence provides an open Web3 protocol, framework and tooling to develop and host applications, interfaces and backends on permissionless peer-to-peer networks.
 
-Fluence is also developing [Marine](https://github.com/fluencelabs/marine) - a general purpose compute runtime for multi-module WebAssembly applications with WASI support and a [shared-nothing](https://en.wikipedia.org/wiki/Shared-nothing_architecture) linking scheme. FCE allows for the rapid development and deployment of portable Wasm services which can be composed and coordinated with Aquamarine into secure applications. Furthermore, Fluence has implemented innovations at the p2p [node](https://github.com/fluencelabs/fluence) level, such as [TrustGraph](https://github.com/fluencelabs/trust-graph), local development and testing tools, such as [Marine-Repl](https://github.com/fluencelabs/marine/tree/master/tools/repl), and support tooling, such as [Fluence Distributor](https://github.com/fluencelabs/proto-distributor).
+The Fluence Web3 stack enables
 
-In combination, Aquamarine and the Fluence runtimes and tools allow developers to avoid the typical peer-to-peer development challenges and accelerate the development and deployment of distributed services and applications.
+* programmable network requests 
+* distributed applications from composition without centralization
+* communication, access and transactional security as first class citizens
+* extensibility through adapter/wrapper services
+* efficiencies and improved time to market arising from the reuse of deployed services and significantly reduced devops requirements
 
-The remainder of this document introduces a set of incremental, hands-on tutorials developing with Aquamarine on the Fluence stack.
+by decoupling business logic from composition, security from business logic and resource management from infrastructure. See Figure 1.
+
+Figure 1: Decentralized Applications Composed From Distributed Services On P2P Nodes ![](https://i.imgur.com/XxC7NN3.png)
+
+An integral component of the Fluence solution is the Aquamarine stack comprised of Aqua and Marine. Aqua is a programming language and runtime environment for peer-to-peer workflows. Marine, on the other hand, is a general purpose runtime and associated tooling for multi-module Wasm applications with WASI support and a shared-nothing linking scheme. That is, Marine runs hosted code on nodes and Aqua facilitates the programming of workflows composed from hosted code. In combination, Aqua and Marine enable any distributed application.
 
 Additional resources and support are available:
 

knowledge_knowledge/knowledge_aquamarine/hll/knowledge_aquamarine_air.md

@@ -23,7 +23,7 @@ AIR instructions are intended to launch the execution of a service method as fol
 4. The arguments specified by the argument list are passed to the method
 5. The result of the method returned under the name output name
 
-**Figure 2: Sequential Instruction** ![Execution](../../../.gitbook/assets/air_sequential_2%20%281%29%20%281%29%20%281%29%20%281%29%20%281%29%20%282%29%20%283%29%20%284%29%20%284%29%20%284%29%20%282%29.png)
+**Figure 2: Sequential Instruction** ![Execution](../../../.gitbook/assets/air_sequential_2%20%281%29%20%281%29%20%281%29%20%281%29%20%281%29%20%282%29%20%283%29%20%284%29%20%284%29%20%284%29%20%281%29.png)
 
 The _**seq**_ instruction takes two instructions at most as its arguments and executes them sequentially, one after the other.
 

p2p.md

@@ -1,16 +1,28 @@
 # Thinking In Distributed
 
-Building and operating distributed networks, backends and applications are non-trivial undertakings not only posing technical challenges but also requiring a significant shift in how to view and think in distributed.
+Permissionless peer-to-peer networks have a lot to offer to developers and solution architects such as decentralization, improved request-response data models and zero trust security at the application and service level. Of course, these capabilities and benefits don't just arise from putting libp2p to work. Instead, a peer-to-peer overlay is required. The Fluence protocol provides such an overlay enabling a powerful distributed data routing and management protocol allowing developers to implement modern and secure Web3 solutions.
 
-Consider a workflow tasked with calling multiple REST endpoints, in sequence, where the response of the previous call is the input to the current call. As illustrated in Figure 1, the application is the focal point and data relay.
+**Improved Request-Response Model**
 
-![Figure 1: Stylized Data Flow For Application With Multiple Endpoint Calls](.gitbook/assets/image%20%283%29.png)
+In some network models, such as client server, the request-response model generally entails a response returning to the request client. For example, a client application tasked to conduct a credit check of a customer and to inform them with a SMS typically would call a credit check API, consume the response, and then call a SMS API to send the necessary SMS.
 
-Programming a frontend application in the Fluence peer-to-peer solution, an application is not a workflow intermediary but merely the initiator of a workflow as workflow logic and data traverses the network from service to service. See Figure 2 for an illustration and please note that services may be deployed to different nodes as well as to more than one node.
+Figure 2: Client Server Request Response Model
 
-![Figure 2: Stylized Data Flow For Application With Fluence Distributed Services ](.gitbook/assets/image%20%284%29.png)
+ ![](https://i.imgur.com/ZYLUzne.png)
 
-In Fluence parlance, we call the workflow + data construct a _particle_ where the workflow is expressed in an AIR script.
+The Fluence peer-to-peer protocol, on the other hand, allows for a much more effective Request-Response processing pattern where responses are forward-chained to the next consuming service\(s\) without having to make the return trip to the client. See Figure 3.
 
-This is a rather cursory overview of probably the most salient conceptual difference developers need to take into consideration in order to succeed in a distributed ecosystem. Luckily, Aquamarine and the Fluence stack eliminate most, if not all, of the heavy lifting necessary to develop high-value per-to-peer networks, backends, and applications.
+Figure 3: Fluence P2P Protocol Request Response Model
+
+ ![](https://i.imgur.com/g3RGBRf.png)
+
+In a Fluence p2p implementation, our client application would call a credit check API deployed or proxy-ed on some peer and then send the response directly to the SMS API service possibly deployed on another peer -- similar to the flow depicted in Figure 1.
+
+Such a significantly flattened request-response model leads to much lower resource requirements for applications in terms of bandwidth and processing capacity thereby enabling a vast class of "thin" clients ranging from browsers to IoT and edge devices truly enabling decentralized machine-to-machine communication.
+
+**Zero Trust Security**
+
+The [zero trust security model](https://en.wikipedia.org/wiki/Zero_trust_security_model) assumes the worst reality, i.e., a breach, and proposes a "never trust, always verify" approach. This approach is inherent in the Fluence peer-to-peer protocol and Aqua programming model as every service request can be authenticated at the service API level.
+
+Overall, the Fluence solution enables a modern Web3 runtime and development environment on top of a peer-to-peer stack that allows developers to build powerful and secure distributed applications on thin clients and powerful servers alike.