s

collections/tech/primitives/compute/corex.md

@@ -3,9 +3,9 @@
 
 ![](img/corex.jpg)
 
-This tool allows you to manage your ZMachine over web remotely.
+This tool allows you to manage your Zero VM over web remotely.
 
-ZMachine process manager:
+Zero VM process manager:
 
 - Provides a web interface and a REST API to control your processes
 - Allows you to watch the logs of your processes

collections/tech/primitives/compute/zero_image.md

@@ -0,0 +1,7 @@
+
+## Zero-Images
+
+> A New Way Of Dealing With OS Images
+
+!!wiki.include page:zero_image_inno.md
+

collections/tech/primitives/compute/zkube.md

@@ -4,22 +4,20 @@ TFGrid is compatible with Kubernetes Technology.
 
 ![](img/kubernetes_0_.jpg)
 
-Each eVDC as shown above is a full blown Kubernetes deployment.
-
 ### Unique for our Kubernetes implementation
 
-- The Kubernetes networks are on top of our [ZNet](znet) technology which means all traffic between containers and kubernetes hosts is end2end encrypted independent of where your Kubernetes nodes are deployed.
-- You can mount a QSFS underneath a Kubernetes Node (VM), which means that you can deploy containers on top of QSFS to host unlimited amounts of storage in a super safe way.
+- The Kubernetes networks are on top of our [Mycelium](mycelium.md) technology which means all traffic between containers and kubernetes hosts is end2end encrypted independent of where your Kubernetes nodes are deployed.
+- You can mount a Quantum Safe Storage System underneath a Kubernetes Node (VM), which means that you can deploy containers on top of QSFS to host unlimited amounts of storage in a super safe way.
 - You Kubernetes environment is for sure 100% decentralized, you define where you want to deploy your Kubernetes nodes and only you have access to the deployed workloads on the TFGrid.
 
 ### Features
 
-*   integration with znet (efficient, secure encrypted network between the zmachines)
+*   integration with znet (efficient, secure encrypted network between the zero_vms)
 *   can be easily deployed at the edge
 *   single-tenant!
 
 <!-- 
-### ZMachine Benefits
+### Zero VM Benefits
 
 *   [ZOS Protect](zos_protect): no hacking surface to the Zero-Nodes, integrate silicon route of trust
 *   [ZNet](znet) and [Planetary Net](planetary_network): a true global single backplane network connecting us all -->

collections/tech/primitives/compute/zmachine.md

@@ -1,6 +1,6 @@
-# ZMachine
+# Zero VM
 
-![](img/zmachine_zos_.jpg)
+![](img/zero_vm_zos_.jpg)
 
 
 ### Features
@@ -12,5 +12,5 @@
 *   minimal hacking surface to the Zero-Nodes, integrate silicon route of trust
 *   ZOS Filesystem: dedupe, zero-install, hacker-proof
 *   Webgateway: intelligent connection between web (internet) and container services
-*   integration with Mycelium (efficient, secure encrypted network between the zmachines)
+*   integration with Mycelium (efficient, secure encrypted network between the zero_vms)
 

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
 

collections/tech/primitives/primitives.md

@@ -11,10 +11,10 @@ Any application which can run on linux can run on the TFGrid.
 
 - [ZKube](zkube.md)
     - kubernetes deployment
-- [ZMachine](zmachine.md)
+- [Zero VM](zero_vm.md)
     - the container or virtual machine running inside ZOS
 - [CoreX](corex.md) 
-    - process manager (optional), can be used to get remote access to your zmachine
+    - process manager (optional), can be used to get remote access to your zero_vm
 
 A 3Node is a Zero-OS enabled computer which is hosted by any cloud operator.
 

collections/tech/primitives/storage/qsfs.md

@@ -2,7 +2,7 @@
 
 ![](img/zos_zstor.jpg)
 
-presents itself as a filesystem to the ZMachine.
+presents itself as a filesystem to the Zero VM.
 
 ### Benefits
 

collections/tech/primitives/storage/storage.md

@@ -1,7 +1,7 @@
 # Storage Primitives
 
 - [ZOS Filesystem](zos_fs.md) : deduped immutable filesystem
-- [ZOS Mount](zmount.md) : a part of a SSD (fast disk), mounted underneath your zmachine
+- [ZOS Mount](zmount.md) : a part of a SSD (fast disk), mounted underneath your zero_vm
 - [Quantum Safe Filesystem](qsfs.md) : unbreakable storage system (secondary storage only)
 - [Zero-DB](zdb.md) : the lowest level storage primitive, is a key value stor, used underneath other storage mechanisms typically
 - [Zero-Disk](zdisk.md) : OEM only, virtual disk format

collections/tech/primitives/storage/zos_fs.md

@@ -9,9 +9,9 @@ A deduped filesystem which is more efficient compared to images as used in other
 
 ## Uses FLIST Inside
 
-In Zero-OS, `flist` is the format used to store zmachine images. This format is made to provide a complete mountable remote filesystem, but downloading only the files contents that you actually needs.
+In Zero-OS, `flist` is the format used to store zero_vm images. This format is made to provide a complete mountable remote filesystem, but downloading only the files contents that you actually needs.
 
-In practice, Flist itself is a small database which contains metadata about files and directories, file payload are stored on a tfgrid hub. You only need to download payload when you need it, this dramatically reduce zmachine boot time, bandwidth and disk overhead.
+In practice, Flist itself is a small database which contains metadata about files and directories, file payload are stored on a tfgrid hub. You only need to download payload when you need it, this dramatically reduce zero_vm boot time, bandwidth and disk overhead.
 
 ### Why this ZFlist Concept