DaoStream Across Network Layers: From Ethernet to Applications

Published Dec 28, 2025

The Question: Where Should Datoms Live?

Most network protocols are locked to a specific layer of the OSI model. HTTP lives at Layer 7 (application). IP lives at Layer 3 (network). Ethernet lives at Layer 2 (data link). But DaoStream's datom packets are fundamentally layer-agnostic—they're just structured messages that need routing.

This raises an interesting question: what happens if we run DaoStream at different network layers?

The answer reveals deep insights about network architecture, content-addressed routing, and the trade-offs between theoretical elegance and practical deployment.

Layer 7: Application Layer (Current Approach)

Currently, DaoStream operates at Layer 7, running over UDP. The datom packet format looks like this:

┌─────────────────────────────────────────┐
│ Stream ID (32 bytes)                    │
├─────────────────────────────────────────┤
│ Sequence Number (8 bytes)               │
├─────────────────────────────────────────┤
│ Flags (1 byte)                          │
├─────────────────────────────────────────┤
│ Datom: [e a v t m]                      │
└─────────────────────────────────────────┘

This packet travels inside UDP datagrams, which travel inside IP packets, which travel inside Ethernet frames. The full stack looks like:

Application Layer (L7):  DaoStream datom packet
Transport Layer (L4):    UDP header + datom packet
Network Layer (L3):      IP header + UDP + datom
Data Link Layer (L2):    Ethernet header + IP + UDP + datom
Physical Layer (L1):     Electrical signals

Advantages of Layer 7

Works over existing infrastructure — DaoStream can run over any network: WiFi, 4G/5G, Ethernet, satellite. No special hardware needed.
NAT traversal — Layer 7 protocols can tunnel through NAT and firewalls using techniques like STUN, TURN, or WebRTC.
Easy deployment — Just install software. No need to control routers, switches, or physical infrastructure.
Composability — Can run over WebSockets for browser compatibility, HTTP/3 for QUIC benefits, or raw UDP for efficiency.

Disadvantages of Layer 7

Overhead — Every datom packet carries Ethernet header (14 bytes) + IP header (20 bytes) + UDP header (8 bytes) = 42 bytes of overhead. For small datoms, this is significant.
Unnecessary layers — IP provides global addressing, but DaoStream uses content-addressed stream IDs. The IP layer is redundant.
Conceptual mismatch — IP assumes location-based addressing (192.168.1.1). DaoStream uses content-addressed routing (stream hash). We're forcing one model into another.

Layer 3: Network Layer (Like WireGuard)

At Layer 3, we'd encapsulate datom packets directly in IP-like packets. Instead of IP addresses, we'd use stream IDs as the addressing scheme:

┌─────────────────────────────────────────┐
│ DaoStream Header:                       │
│   - Version (4 bits)                    │
│   - Flags (4 bits)                      │
│   - Packet Length (16 bits)             │
│   - Destination Stream ID (32 bytes)    │
│   - Source Stream ID (32 bytes)         │
│   - Sequence Number (8 bytes)           │
├─────────────────────────────────────────┤
│ Datom: [e a v t m]                      │
└─────────────────────────────────────────┘

This would replace IP entirely. Routers would route based on stream IDs instead of IP addresses.

How Layer 3 Routing Would Work

Routers would maintain routing tables like:

Stream ID Prefix → Next Hop
a3f2...          → Interface eth0
b7c1...          → Interface eth1
default          → Gateway router

This is similar to how IP routing works, but using content hashes instead of hierarchical addresses.

Advantages of Layer 3

Less overhead — No UDP header. Only ~72 bytes of DaoStream header vs 42 bytes of Ethernet+IP+UDP.
Content-addressed routing — Stream IDs encode content identity. Routing naturally follows content, not arbitrary IP allocation.
Similar to WireGuard philosophy — WireGuard operates at Layer 3, providing stateless, cryptographically-routed tunnels. DaoStream at Layer 3 would have similar properties.

Disadvantages of Layer 3

Can't run over existing internet — The internet routes IP packets. You'd need DaoStream-aware routers everywhere between source and destination.
Still has overhead — Layer 3 still requires routing headers. The 72-byte DaoStream header is larger than the 20-byte IP header.
NAT problems remain — You'd still need address translation at the edge where DaoStream meets the IP internet.
Harder deployment — Requires control of routing infrastructure, not just endpoints.

Layer 2: Data Link Layer (Most Elegant)

At Layer 2, datom packets would replace Ethernet frames entirely. This is where things get really interesting.

Instead of MAC addresses (48 bits identifying network interfaces), we'd use stream IDs (256 bits identifying content streams):

┌─────────────────────────────────────────┐
│ Destination Stream ID (32 bytes)        │
├─────────────────────────────────────────┤
│ Source Stream ID (32 bytes)             │
├─────────────────────────────────────────┤
│ Sequence Number (8 bytes)               │
├─────────────────────────────────────────┤
│ Flags (1 byte)                          │
├─────────────────────────────────────────┤
│ Datom: [e a v t m]                      │
└─────────────────────────────────────────┘

No IP. No UDP. No Ethernet. Just datom frames on the wire.

Why Layer 2 is Architecturally Beautiful

1. Content-Addressed Streaming

Ethernet switches learn MAC address tables dynamically—when a frame arrives, the switch records "MAC address X is reachable via port 3." DaoStream switches would do the same with stream IDs:

;; Switch learns which streams flow through which ports
(defn handle-datom-frame [switch frame port]
  (let [stream-id (:stream-id frame)
        datom (:datom frame)]
    ;; Learn: this stream flows through this port
    (swap! (:stream-ports switch)
           update stream-id (fnil conj #{}) port)
    ;; Forward datom to all ports subscribed to this stream
    (doseq [out-port (get @(:stream-ports switch) stream-id)]
      (when (not= out-port port)  ;; Don't send back to source
        (send-frame out-port frame)))))

This is pure stigmergic forwarding. Switches observe which streams flow through which ports and multicast datoms accordingly. Interpreters attach to streams by sending subscription datoms. The network just forwards datom flows. No routing to interpreters—interpreters read from streams.

2. Eliminates Address Resolution

In IP networks, you need ARP (Address Resolution Protocol) to map IP addresses to MAC addresses. In DaoStream Layer 2, stream IDs are the addresses. There's nothing to resolve:

No ARP — Stream ID is the only identifier needed
No DNS — Content-addressed means names are hashes
No DHCP — No centralized address allocation

3. Natural Mesh Topology

Ethernet is inherently a broadcast medium—switches learn topology by observing traffic. DaoStream at Layer 2 inherits this property, making mesh networks natural:

BLE mesh devices broadcast datom frames
Nearby switches/routers learn which streams are reachable via which neighbors
Topology adapts automatically as devices move or connections change
No centralized coordination needed

4. Direct Hardware Efficiency

Network interface cards (NICs) operate at Layer 2. A DaoStream Layer 2 implementation could:

Implement datom frame handling in hardware (FPGA or ASIC)
Filter frames by stream ID at wire speed
Avoid copying data through multiple protocol layers
Enable zero-copy forwarding in switches

Advantages of Layer 2

Minimal overhead — Only 73 bytes of header (2×32 for stream IDs + 8 for sequence + 1 for flags). No IP, no UDP, no Ethernet preamble needed.
Content-addressed networking — Stream IDs replace MAC addresses. Routing follows content identity, not arbitrary hardware addresses.
Stigmergic topology discovery — Switches learn routing tables by observing traffic. Zero configuration.
Perfect for mesh networks — BLE mesh, sensor networks, and IoT devices naturally operate at Layer 2. DaoStream maps directly to their communication model.
No protocol baggage — No IP subnets, no routing protocols, no NAT, no ARP, no DHCP. Just stream IDs and datoms.
Hardware acceleration potential — Layer 2 frames can be processed in NICs and switches at wire speed.

Disadvantages of Layer 2

Can't run over existing internet — The internet routes IP packets, not arbitrary Layer 2 frames. You'd need DaoStream-native hardware everywhere.
Limited physical scope — Layer 2 is inherently local. Ethernet broadcasts don't cross routers. You'd need Layer 2 tunneling for wide-area networking.
Requires specialized hardware — Network cards, switches, and routers would need DaoStream firmware. Can't deploy with software alone.
Bootstrap problem — No one has DaoStream Layer 2 hardware yet. Chicken-and-egg problem for deployment.

The Pragmatic Hybrid: Layer 2 + Layer 7

The ideal architecture isn't choosing one layer—it's using the right layer for the right context:

┌──────────────────────────────────────────────┐
│ Local Mesh Network (BLE, IoT sensors)       │
│ → DaoStream Layer 2 (datom frames)          │
│ → Hardware switching, zero config           │
└──────────────────┬───────────────────────────┘
                   │
          ┌────────▼─────────┐
          │ Gateway Router   │
          │ (L2 ↔ L7 bridge) │
          └────────┬─────────┘
                   │
┌──────────────────▼───────────────────────────┐
│ Internet / Wide Area Network                 │
│ → DaoStream Layer 7 over UDP                 │
│ → Tunnels through IP infrastructure          │
│ → NAT traversal via WebRTC/STUN              │
└──────────────────┬───────────────────────────┘
                   │
          ┌────────▼─────────┐
          │ Remote Gateway   │
          │ (L7 → L2 bridge) │
          └────────┬─────────┘
                   │
┌──────────────────▼───────────────────────────┐
│ Remote Local Network                         │
│ → DaoStream Layer 2 (datom frames)          │
└──────────────────────────────────────────────┘

Where to Use Layer 2

BLE mesh networks — Sensors, wearables, smart home devices
Local IoT deployments — Factory floors, building automation, agricultural sensors
Offline-first environments — Remote research stations, ships, disaster areas
High-performance local clusters — Datacenter racks, HPC clusters

Where to Use Layer 7

Internet connectivity — Cloud services, mobile apps, web browsers
NAT traversal — Home networks, mobile carriers, firewalls
Legacy integration — Connecting to existing IP infrastructure
Rapid deployment — Software-only rollout, no hardware changes needed

The Gateway Bridge

The critical component is the gateway that bridges Layer 2 and Layer 7:

(defn gateway-bridge []
  {:layer2-interface
   ;; Receives native DaoStream frames from local mesh
   (fn [datom-frame]
     (let [stream-id (:destination-stream-id datom-frame)]
       (if (local-stream? stream-id)
         ;; Forward locally via Layer 2
         (forward-l2 datom-frame)
         ;; Tunnel to remote via Layer 7
         (tunnel-l7 datom-frame))))

   :layer7-interface
   ;; Receives UDP packets from internet
   (fn [udp-packet]
     (let [datom-frame (unwrap-udp udp-packet)
           stream-id (:destination-stream-id datom-frame)]
       (if (local-mesh-stream? stream-id)
         ;; Deliver to local mesh via Layer 2
         (forward-l2 datom-frame)
         ;; Continue routing via Layer 7
         (route-l7 datom-frame))))})

;; Transparent bridging—apps don't know if they're L2 or L7

Applications are layer-agnostic. They open streams, read/write datoms, close streams. The gateway handles the complexity of bridging local Layer 2 efficiency with global Layer 7 reachability.

Why Layer 2 is the Ideal Endpoint

While Layer 7 is necessary for internet connectivity, Layer 2 reveals DaoStream's true potential:

1. Zero Configuration Networking

No IP addresses to assign. No subnets to configure. No routing protocols to set up. Devices broadcast datom frames. Switches observe traffic and learn topology. Networks self-organize.

2. Content Follows Routes

Stream IDs are content hashes. When a switch learns "stream X is via port 3," it's learning where content lives, not where an arbitrary device happens to be connected. Routing naturally follows content, enabling:

Caching at switches (just store popular streams locally)
Multicast by default (multiple subscribers = same stream ID = natural multicast)
Content-aware load balancing (route to nearest copy of data)

3. Mobility Without Pain

IP assumes devices stay at fixed addresses. When you move, you need mobile IP, tunneling, or re-authentication. Layer 2 DaoStream just works:

Device moves to new switch? Switch learns the new port automatically.
BLE device hops between access points? Frames find it via broadcast/learning.
No concept of "home network" vs "foreign network"—just streams and reachability.

4. Perfect Match for Embedded Systems

Microcontrollers and embedded devices are resource-constrained. Layer 2 DaoStream minimizes overhead:

No TCP/IP stack needed (saves kilobytes of code and RAM)
No DNS, DHCP, ARP clients (simpler software)
Hardware can process frames directly (zero-copy forwarding)
Minimal headers (73 bytes vs 42+ bytes for Ethernet/IP/UDP)

An ESP32 or nRF52 BLE chip could run a complete DaoStream Layer 2 stack in under 10KB of code.

Real-World Deployment Path

You can't deploy Layer 2 globally overnight. The realistic path is:

Phase 1: Layer 7 Everywhere (Today)

DaoStream over UDP for maximum compatibility
Works on existing internet infrastructure
Software-only deployment
Proves the datom model works at scale

Phase 2: Layer 2 in Controlled Environments

Custom firmware for BLE mesh devices
Dedicated IoT networks (factories, buildings, farms)
Datacenter racks with DaoStream-native switches
Gateways bridge Layer 2 islands via Layer 7 tunnels

Phase 3: Hardware Acceleration

FPGA-based DaoStream switches for enterprise
ASIC NICs with native datom frame processing
OS kernel support for DaoStream sockets
Layer 2 becomes the fast path, Layer 7 the fallback

Phase 4: Native Infrastructure (Future)

ISPs offer DaoStream Layer 2 peering
Consumer routers support datom routing natively
IP becomes the legacy compatibility layer
The internet runs on content-addressed streams

Each phase builds on the previous one. Layer 7 proves the model. Layer 2 optimizes where you control hardware. Eventually, Layer 2 becomes the default, and IP/UDP is just for legacy compatibility.

Conclusion: Layer-Agnostic by Design

DaoStream's power comes from being layer-agnostic. The datom packet format works at Layer 2, 3, or 7. You choose based on your constraints:

Need internet compatibility? Use Layer 7 over UDP.
Control local infrastructure? Use Layer 2 for efficiency.
Building new hardware? Layer 2 is the ideal target.

This flexibility mirrors DaoStream's broader philosophy: simple primitives that work everywhere, interpretation at the edges. The network layer doesn't dictate how you use it. It just routes datoms. Whether those datoms travel in Ethernet frames, IP packets, or UDP datagrams doesn't change the fundamental model.

Layer 2 reveals the ideal—content-addressed, zero-config, stigmergic networking. Layer 7 provides the pragmatic path to get there. And because the datom format is the same at every layer, you can bridge between them transparently.

This is the beauty of keeping the protocol minimal. When the core is just "route datoms by stream ID," you can run it anywhere—from BLE mesh to datacenter fabric to the global internet. One protocol, infinite deployment contexts.

To understand how DaoStream simplifies Plan 9's 9P protocol while preserving its philosophy, read DaoStream: Inspired by Plan 9, Simpler Than 9P. To see how DaoStream's universal interface unifies all resources, explore DaoStream.