...

docs/key_innovations_overview/network_inno/mycelium.md

@@ -0,0 +1,16 @@
+---
+sidebar_position: 2
+title: Mycelium
+description: Our Planetary Network
+---
+
+
+# Mycelium: Our Planetary Network
+
+![alt text](../../img/mycelium.png)
+
+The planetary network called Mycelium is an overlay network which lives on top of the existing Internet or other peer-to-peer networks created. 
+
+In the Mycelium network, everyone is connected to everyone. End-to-end encryption between users of an app and the app runs behind the network wall.
+
+!!wiki.include page:'tech:mycelium0.md'

docs/key_innovations_overview/network_inno/mycelium_inno.md

@@ -5,6 +5,16 @@ sidebar_position: 2
 
 ![](../../img/peer2peer_network.jpg)
 
+# Mycelium: Our Planetary Network
+
+![alt text](../../img/mycelium.png)
+
+The planetary network called Mycelium is an overlay network which lives on top of the existing Internet or other peer-to-peer networks created. 
+
+In the Mycelium network, everyone is connected to everyone. End-to-end encryption between users of an app and the app runs behind the network wall.
+
+!!wiki.include page:'tech:mycelium0.md'
+
 ## Mycelium: A New Network Layer for the Internet
 
 ![](../../img/mycelium00.png)

docs/key_innovations_overview/network_inno/networking.md

@@ -0,0 +1,35 @@
+---
+sidebar_position: 1
+---
+
+
+# Network Technology Overview
+
+Our decentralized networking platform allows any compute and storage workload to be connected together on a private (overlay) network and exposed to the existing Internet network. The peer-to-peer network platform allows any workload to be connected over secure encrypted networks, which will look for the shortest path between nodes.
+
+### Secure Mesh Overlay Network (Peer-to-Peer)
+
+ZNet is the foundation of any architecture running on the TF Grid. It can be seen as a virtual private data center and the network allows all of the *N* containers to connect to all of the *(N-1)* other containers. Any network connection is a secure network connection between your containers, it creates a peer-to-peer network between containers. 
+
+![alt text](../../img/net1.png)
+
+No connection is made with the Internet. The ZNet is a single tenant network and by default not connected to the public Internet. Everything stays private. For connecting to the public Internet, a Web Gateway is included in the product to allow for public access, if and when required.
+
+### Redundancy
+
+As integrated with Web Gateway
+
+![alt text](../../img/net2.png)
+
+- Any app can get (securely) connected to the Internet by any chosen IP address made available by ThreeFold network farmers through WebW
+- An app can be connected to multiple web gateways at once, the DNS round robin principle will provide load balancing and redundancy
+- An easy clustering mechanism where web gateways and nodes can be lost and the public service will still be up and running
+- Easy maintenance. When containers are moved or re-created, the same end user connection can be reused as that connection is terminated on the Web Gateway. The moved or newly created Web Gateway will recreate the socket to the Web Gateway and receive inbound traffic.
+
+### Network Wall
+
+![](../../img/network_wall.png)
+
+For OEM projects we can implement a cloud deployment without using TCP-IP or Ethernet this can lead to super secure environments, ideal to battle the Cuber Pandemic.
+
+

docs/key_innovations_overview/network_inno/virtual_browser.md

@@ -1,76 +0,0 @@
----
-title: Virtual Browser
-sidebar_position: 5
----
-
-![](../../img/virtual_browser.jpg)
-
-## Secure Remote Browser Concept
-
-### Overview
-
-In this concept, users interact with a secure web application through their web browsers without running JavaScript locally. 
-
-Instead, the actual browser logic and JavaScript execution occur in a secure, remote virtual browser hosted in a secure part of a private cloud. This setup provides enhanced security and control, ensuring that users are protected from malicious scripts and other threats.
-
-### Key Components
-
-1. **Client-Side Browser (Local Browser)**
-   - **Rendering Only**: The user's local browser is responsible only for rendering content. It draws the user interface using technologies like HTML5 Canvas.
-   - **No Local JavaScript Execution**: No JavaScript code runs on the local browser, eliminating the risk of client-side script attacks.
-
-2. **Remote Browser (Virtual Browser)**
-   - **Secure Execution Environment**: The remote browser runs within a secure container in the cloud. For example, this could be within the secure network of a bank.
-   - **JavaScript Execution**: All JavaScript execution happens in the remote browser. This environment is tightly controlled and monitored.
-   - **Context Validation**: Each JavaScript file executed is checked to ensure it originates from the original, built application. This prevents unauthorized or malicious scripts from running.
-
-3. **Session Management**
-   - **Ephemeral Sessions**: Each user session is temporary. After a session ends, the context is destroyed and rebuilt for the next session, ensuring a clean state each time.
-   - **Session Recording**: Sessions can be recorded, similar to screen CCTV, for auditing and security purposes. This allows for detailed monitoring and review if needed.
-
-4. **Network Service Lists and Mycelium Integration**
-   - **Secure Communication**: The connection between the local browser and the remote browser uses end-to-end encryption. The Mycelium overlay network ensures the shortest path and secure, peer-to-peer communication.
-   - **Access Control**: Network service lists and group-based access control manage which users can access specific applications, enhancing security and control.
-
-### Example Workflow
-
-1. **User Initiates Connection**
-   - The user opens their local browser and navigates to the bank's application URL.
-   - The local browser connects to the remote browser hosted in the bank's secure cloud environment.
-
-2. **Remote Browser Setup**
-   - A new, secure container is instantiated for the user's session.
-   - The remote browser loads the bank's application and validates all JavaScript files.
-
-3. **Rendering in Local Browser**
-   - The remote browser executes the JavaScript and sends the rendered output to the local browser.
-   - The local browser draws this output on the canvas, providing a seamless user experience.
-
-4. **Session Management**
-   - Throughout the session, all interactions are processed by the remote browser.
-   - User interactions (e.g., clicks, form submissions) are sent to the remote browser, which processes them and updates the rendered output accordingly.
-
-5. **Session Termination**
-   - When the user finishes their session, the remote browser context is destroyed.
-   - Any recorded session data is stored securely for auditing purposes.
-
-### Benefits
-
-1. **Enhanced Security**
-   - By not running JavaScript locally, the risk of client-side attacks such as cross-site scripting (XSS) is eliminated.
-   - The remote browser's secure environment ensures that only validated scripts execute.
-
-2. **Controlled Environment**
-   - The bank has full control over the execution environment, allowing for stringent security policies and monitoring.
-   - Ephemeral sessions ensure that each user starts with a clean slate, reducing the risk of persistent threats.
-
-3. **Auditing and Compliance**
-   - Session recording provides a detailed audit trail, which is valuable for security reviews and compliance with regulatory requirements.
-
-4. **Improved User Experience**
-   - Users benefit from a secure browsing experience without performance degradation, as rendering is offloaded to the client's local browser.
-
-### Integration with Mycelium and Network Service Lists
-By combining this remote browser concept with Mycelium and network service lists, we can ensure secure and efficient communication:
-- **Mycelium Overlay Network**: Ensures that the connection between the local and remote browser is routed through the most efficient path, leveraging peer-to-peer connections where possible.
-- **Network Service Lists**: Manage which users and groups can access the remote browser and specific applications, providing fine-grained access control.

docs/key_innovations_overview/network_inno/webgw.md

@@ -0,0 +1,43 @@
+---
+sidebar_position: 3
+title: Web Gateway
+---
+
+# Web Gateway
+
+The Web Gateway is a mechanism to connect private networks to the open Internet in such a way that there is no direct connection between the Internet and the secure workloads running in the Zero VMs.
+
+![](../../img/webgateway.jpg)
+
+### Key Benefits
+
+- Separation between where compute workloads are and where services are exposed
+- Redundancy: Each app can be exposed on multiple web gateways at once
+- Support for many interfaces
+- Helps resolve shortage of IPv4 addresses
+
+### Implementation
+
+Some 3Nodes support gateway functionality (this is configured by the farmers). A 3Node with gateway configuration can then accept gateway workloads and forward traffic to Zero VMs that only have Planetary Network or IPv6 addresses.
+
+The gateway workloads consist of a name (prefix) that first needs to be reserved on the blockchain. Then, the list of backend IPs. There are other flags that can be set to control automatic TLS (please check Terraform documentation for the exact details of a reservation).
+
+Once the 3Node receives this workload, the network configures proxy for this name and the Planetary Network IPs.
+
+### Security
+
+Zero VMs have to have a Planetary Network IP or any other IPv6 (IPv4 is also accepted). This means that any person connected to the Planetary Network can also reach the Zero VM without the need for a proxy.
+
+So it's up to the Zero VM owner/maintainer to make sure it is secured and that only the required ports are open.
+
+### Redundant Network Connection
+
+![](../../img/redundant_net.jpg)
+
+### Unlimited Scale
+
+![](../../img/webgw_scaling.jpg)
+
+The network architecture is a pure scale-out network system. It can scale to unlimited size, there is simply no bottleneck. Network "supply" is created by network farmers, and network "demand" is done by TF Grid users.
+
+Supply and demand scale independently. For supply, there can be unlimited network farmers providing web gateways on their own 3Nodes, and unlimited compute farmers providing 3Nodes for compute and storage. The demand side is driven by developers creating software that runs on the grid, system integrators creating solutions for enterprises, and so on. Globally, there is exponentially-growing demand for data processing and storage use cases.