Mesh-Native Chat

What you'll build

Vertical stack context: DOSFIUniversity (research) → DOSFI Academy (this course) → MeshNativeExchange (publishing & monetizing). Students progress from Learning → Building → Publishing → Monetizing. This course introduces the fundamentals of Mesh-Native architecture through the design and implementation of a Chat application. Learners will explore core components such as the DIU, Transport Layer, Node, Adapter, and Workflow, understanding their interaction within the Mesh-Native ecosystem. Practical exercises will reinforce the concepts of message routing, privacy management via Privacy Tiers, and the State Machine controlling message flow, enabling a solid foundation for developing distributed, subsystem-aware applications.

Skills you'll practice

• Understand the architecture and core components of Mesh-Native relevant to chat applications
• Implement message routing and privacy policies within the Mesh-Native environment
• Configure and deploy a simple Mesh-Native Chat application demonstrating subsystem interactions
• Analyze system behavior through state transitions and data flow diagrams

Before you start

• Basic understanding of distributed systems
• Familiarity with Mesh-Native concepts (DOSFI, MeshInfer, MNE)
• Knowledge of architecture and APIs of DIU and Adapter components

Lab steps6 steps

1. 1
   Architecting the Mesh-Native Chat Ecosystem

   Welcome to the Mesh-Native Chat lab. In this module, we establish the foundational principles of distributed communications using the DOSFI Transport Layer. Traditional chat applications rely on centralized servers to handle message relay, which introduces single points of failure. In a mesh-native architecture, every node serves as a peer in a distributed network, facilitating bundle propagation without requiring a master authority. Our architecture relies on the Identity Fabric for authentication, ensuring that every participant has a cryptographically verifiable public key that maps to their Identity object. The Transport Layer utilizes gossiping protocols to ensure that bundles are delivered across the mesh even in partition-prone environments. Architecture Diagram: [User A] <-> [Mesh Transport Layer] <-> [User B]. The Transport Layer functions by encapsulating messages into discrete 'Bundles'. A bundle consists of a metadata header and a payload encrypted for specific peers. Implementing this requires defining a schema that the mesh can inspect to perform routing without decrypting the payload. Pseudocode for a basic Bundle: { 'header': { 'origin_id': '...', 'destination_id': '...', 'timestamp': '...', 'ttl': 64 }, 'payload': { 'content': '...' } }. For this exercise, students must initialize an Identity Fabric instance and configure the Transport Layer to advertise their node address. Common pitfalls include failing to set correct TTL (Time-To-Live) values, leading to infinite message loops; ensure you validate your bundle header before propagation. This module prepares you to integrate the DIU-based settlement layer in the next lesson.

2. 2
   Defining the Chat Bundle Schema and Identity Fabric

   To build a robust chat, we must standardize how information travels. The Identity Fabric acts as our gatekeeper, mapping public keys to identity objects. In this lesson, we define the JSON schema for our chat bundle to ensure cross-node compatibility. The schema includes fields for Identity IDs, payload types, and cryptographic signatures. Schema: { 'msg_id': 'UUID', 'sender_id': 'IdentityFabric_ID', 'timestamp': 'ISO8601', 'payload': 'ENCRYPTED_BLOB' }. Implementation involves utilizing the Identity Fabric API to sign the bundle header. When a node receives a bundle, it performs a signature verification check. If the signature is invalid, the node drops the bundle immediately to prevent resource exhaustion. Exercise: Create an identity object and generate a signature for a dummy bundle. Pitfall: Avoid caching unverified signatures; this leads to identity spoofing. Connect this to the next lesson by preparing our node to route these bundles through the MeshInfer gateway.

3. 3
   Transport Layer Routing and Bundle Propagation

   Now we configure the Transport Layer to propagate bundles across the distributed topology. Unlike traditional socket-based connections, the Transport Layer manages a dynamic routing table based on peer availability. Architecture: [Bundle Generator] -> [Routing Engine] -> [Mesh Transport Fabric] -> [Remote Node]. We use a cost-optimized routing policy where bundles are prioritized based on the urgency flag. Example Configuration: { 'routing_policy': { 'mode': 'gossip', 'replication_factor': 3, 'timeout': '500ms' } }. You will implement a routing function that selects peer connections based on 'node_health' metrics provided by the Fabric. Practical exercise: Simulate a network partition by dropping a node and observing if the Transport Layer reroutes the bundle. Avoid the 'Split-Brain' syndrome by enforcing a strict consensus on the routing table state. This routing mechanism sets the stage for implementing the Vital settlement layer, where message relay costs are tracked.

4. 4
   Integrating Vital for Message Settlement

   Mesh-native communication is not free; it requires a mechanism to discourage spam and incentivize relay. We use Vital, the DIU-based settlement layer, to attach a small cost to every bundle propagation. This prevents nodes from flooding the mesh with useless traffic. The settlement flow: 1. Sender signs a bundle with a Vital header. 2. Relay nodes verify the DIU balance. 3. Settlement is finalized once the message is delivered. Configuration for a chat room: { 'vital_cost_per_bundle': '0.005_DIU', 'escrow_limit': '10_DIU' }. Implementation: Wrap your bundle generation logic with a DIU deduction call. If the sender's Vital balance is insufficient, the Transport Layer will reject the bundle at the source. Pitfall: Always check for 'insufficient_funds' error codes returned by the MeshNativeExchange interface. This prepares us for the next lesson: optimizing real-time message delivery latency.

5. 5
   Real-time Delivery and MeshInfer Integration

   For a chat application, latency is king. We integrate MeshInfer to optimize the path taken by the bundle through the network. MeshInfer analyzes the latency of various routes and adjusts the Transport Layer’s routing policy dynamically. Diagram: [Chat App] -> [MeshInfer Optimizer] -> [Transport Layer]. By predicting network congestion, MeshInfer ensures that chat messages take the path of least resistance. You will implement a callback handler in your chat application that refreshes the routing table every 5 seconds. Code: 'mesh_infer.get_optimized_route(peer_id)'. Practical exercise: Measure end-to-end latency with and without the optimizer. Common mistake: Setting the optimizer refresh interval too low, causing excessive overhead. This is the final performance step before we wrap everything in the MNE economic policy.

6. 6
   Enforcing Privacy Tiers and Economic Policy

   In our final lesson, we enforce privacy using the Identity Fabric's tiered access control. We define three privacy tiers: 'Public', 'Private-Encrypted', and 'Zero-Knowledge-Verified'. Using the MeshNativeExchange (MNE), we define a pricing policy where high-privacy messages cost more DIU to propagate. Configuration: { 'privacy_tiers': { 'tier_1_public': '0.001_DIU', 'tier_2_private': '0.01_DIU', 'tier_3_zk': '0.05_DIU' } }. This economic structure balances privacy needs with mesh utility. Implementation: Modify your chat bundle to include a 'privacy_level' header field. The receiver node logic must check this flag and verify the required cryptographic proof against the MNE policy. Exercise: Successfully send a tiered message across three nodes with proper settlement and decryption. Pitfall: Ensure your crypto keys for tier 3 are rotated regularly to maintain security. You have now completed the Mesh-Native Chat lab.