s

collections/tech/primitives/network/mycelium.md

@@ -6,4 +6,6 @@ The planetary network called Mycelium is an overlay network which lives on top o
 
 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:mycelium_incl.md'
+!!wiki.include page:'tech:mycelium0.md'
+
+> [read more about the shortest path routing](tf9_products:shortest_path_routing.md)

collections/tech/primitives/network/mycelium_whiltelist.md

@@ -0,0 +1,54 @@
+![](whitelists.jpeg)
+
+# Mycelium Whitelists
+
+> Rethinking Network Security: Beyond Traditional Firewalls
+
+### The Limitations of Traditional Firewalls
+
+Firewalls have long been the cornerstone of network security, operating as gatekeepers to keep malicious actors out. 
+
+They work by monitoring incoming and outgoing network traffic and applying security rules to block or allow data packets based on predefined criteria. However, while firewalls are effective at creating a barrier, they have inherent limitations:
+
+1. **Perimeter Focus**: Firewalls are designed to protect the perimeter of the network. This approach assumes that threats come from outside the network, but it does not adequately address threats from within.
+2. **Static Rules**: Firewalls rely on static rules that can be bypassed by sophisticated attacks. They do not adapt dynamically to changing threat landscapes.
+3. **Single Point of Failure**: As a centralized barrier, firewalls represent a single point of failure. If a firewall is compromised, the entire network can be exposed.
+
+### The Need for Strong Authentication and Peer-to-Peer Communication
+
+To address these limitations, a more modern approach to network security involves strong authentication and decentralized communication. By ensuring that all participants on the network are strongly authenticated, we can establish trust at the individual level rather than relying solely on perimeter defenses.
+
+#### Strong Authentication
+
+Strong authentication involves verifying the identity of network participants using robust methods such as:
+
+- **Multi-Factor Authentication (MFA)**: Requires multiple forms of verification, such as passwords, biometrics, and hardware tokens.
+- **Public Key Infrastructure (PKI)**: Uses cryptographic keys to authenticate users and devices.
+
+By implementing strong authentication, we can ensure that only legitimate users and devices can access the network, significantly reducing the risk of unauthorized access.
+
+#### Peer-to-Peer Communication Over an Overlay Network
+
+Instead of routing all traffic through a central firewall, participants can communicate directly with each other and applications using a peer-to-peer (P2P) overlay network. An overlay network, called Mycelium, can facilitate this decentralized communication.
+
+- **Mycelium Overlay Network**: This overlay network functions like a mesh, allowing nodes (participants) to connect directly with each other and applications. It provides a resilient and scalable architecture where each node can dynamically find the best path for communication.
+
+### Whitelists and Group-Based Access Control
+
+To further enhance security, applications can use whitelists and group-based access control. This approach involves:
+
+1. **Whitelisting Users**: Only allowing access to users who are explicitly permitted. This can be based on strong authentication credentials.
+2. **Group-Based Access Control**: Organizing users into groups with specific permissions. Each application can define which groups have access based on their source IP addresses and other criteria.
+
+#### Example Scenario
+
+Consider an application hosted on the network. Instead of relying on a firewall to block unauthorized access, the application uses Mycelium to communicate with authenticated peers. It employs a whitelist to specify which users or groups can access the application. For instance:
+
+- **Group A**: Developers with access to development resources.
+- **Group B**: Administrators with access to administrative tools.
+- **Group C**: End-users with access to specific application features.
+
+Each group’s access is controlled by specifying the allowed source IP addresses and other authentication factors. This ensures that only authorized users can access the application, regardless of their location.
+
+> only available in the enterprise edition.
+

collections/tech/primitives/network/rmb.md

@@ -0,0 +1,12 @@
+
+#### Reliable Message Bus
+
+The user sends the contractID and workload through the RMB to the destination Node.
+
+RMB is our Reliable Message Bus, workload definitions don't get registerd on the TFChain but directly send peer2peer, this is more secure and private, the smart contract still controls the overall process.
+
+The Node reads from the [RMB](https://github.com/threefoldtech/rmb) and sees a deploy command, it reads the contractID and workload definition from the payload.
+It decodes the workload and reads the contract from chain using the contract ID, the Node will check if the user that created the contract and the deployment hash on the contract is the same as what the Node receives over RMB. If all things check out, the Node deploys the workload.
+
+> In our ZOS 4.0 RMB will be implemented using our Mycelium network and fully integrated.
+

collections/tech/primitives/network/webgw.md

@@ -1,6 +1,6 @@
 # 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 ZMachines.
+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)
 
@@ -13,7 +13,7 @@ The Web Gateway is a mechanism to connect private networks to the open Internet
 
 ### 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 ZMachines that only have Planetary Network or IPv6 addresses.
+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).
 
@@ -21,9 +21,9 @@ Once the 3Node receives this workload, the network configures proxy for this nam
 
 ### Security
 
-ZMachines 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 ZMachine without the need for a proxy.
+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 ZMachine owner/maintainer to make sure it is secured and that only the required ports are open.
+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
 

collections/tech/primitives/network/znic.md

@@ -1,6 +1,6 @@
 # ZNIC
 
-ZNIC is the network interface which is connected to ZMachine.
+ZNIC is the network interface which is connected to Zero VM.
 
 Can be implemented as interface to