Why TCP Is Too Semantic for Datom.world

Published Dec 8, 2025

For most distributed systems, the choice between TCP and UDP is straightforward:

• Need reliability? Use TCP.
• Need speed? Use UDP.

For Datom.world, the question is different:

Which substrate preserves Datom.world's semantics with the least distortion?

The answer: UDP, with a custom Datom.world protocol on top.

Here's why.

TCP Forces a Global Total Order

TCP creates the illusion of one linear sequence of bytes, even when the underlying network delivered them out of order.

But Datom.world explicitly rejects global order.

Datom.world streams are:

• Append-only
• Unordered unless interpreted
• Causality is declared, not enforced
• Interpretation sits above transport

TCP's ordering machinery is actually a semantic layer pretending to be transport.

When you use TCP, you're saying: "These bytes have a canonical order that must be preserved." But in Datom.world, order is semantic, not mechanical. Different interpreters might view the same stream in different orders based on their local perspective and needs.

TCP's total order is a lie that becomes truth by enforcement. Datom.world rejects that sleight of hand.

TCP Conflates Interpretation with Transport

TCP comes with built-in:

• ACK logic
• Retransmission
• Congestion control
• Head-of-line blocking
• Connection state

All of these are interpretations about how bytes should behave.

Datom.world does not allow semantics inside the substrate.

A fixed-size datom stream wants a raw flow of packets. The interpreter decides what "reliability" means:

• A transaction log interpreter might require total reliability
• A real-time rendering interpreter might tolerate loss
• A CRDT merge interpreter might need partial ordering only
• A cache invalidation interpreter might want best-effort delivery

TCP makes these decisions for you. That's the problem.

TCP Is Connection-Oriented; Datom.world Is Stream-Oriented

Entanglement in Datom.world uses soft membership, ephemeral nodes, and local views.

Connections introduce:

• Unnecessary coupling
• Global state
• Tight failure semantics
• Slow recovery when connections break

UDP gives you pure message passing: no shared state, no handshake, no connection lifecycle.

Exactly what continuations want when they migrate across nodes.

When an agent migrates from node A to node B, it shouldn't need to tear down a connection and establish a new one. It should just start emitting datoms to a different address. UDP allows this fluidity. TCP fights it.

The Datom Already Encodes Causality

A datom in Datom.world is:

[entity attribute value transaction metadata]

The metadata field is itself an entity reference that can point to other datoms:

;; metadata is an entity ID pointing to other datoms
[datom-42 :caused-by datom-12 tx meta]
[datom-42 :depends-on datom-67 tx meta]

Causality lives fully inside the datom as entity references.

Not in the wire protocol. Not in the stream ordering. Not in the transport semantics.

This means:

• Two datoms can arrive out of order
• The interpreter follows entity references to reconstruct causal relationships
• No global ordering is required
• Different interpreters can form different causal views by traversing the reference graph differently

TCP's ordering would be actively misleading. It would impose a false causality based on network arrival time rather than the logical causality declared in the datom metadata.

Does Embedding Causality Violate External Semantics?

No. Here's the key distinction:

1. Causality metadata lives inside the datom.
2. The meaning of that causality is external.

Storing entity references is not the same as storing semantics.

The datom is a shape, not a meaning.

Even if a datom references another datom:

[datom-42 :caused-by datom-12 tx meta]

that's still just a reference. It doesn't mean anything until an interpreter assigns meaning.

Two different interpreters could read the same datom reference and do completely different things:

• Interpreter A (transaction log): Treats :caused-by as a temporal ordering constraint
• Interpreter B (CRDT): Treats it as a partial order in a version graph
• Interpreter C (visualization): Draws arrows in a timeline UI
• Interpreter D (migration runtime): Treats it as a continuation reference
• Interpreter E (cache): Ignores it entirely

The datom never forces any semantic interpretation. It only contains data.

That's the essence of "semantics is external."

Why Not QUIC?

QUIC is:

• User-space
• UDP-based
• Multiplexed
• Encrypted
• Reliable
• Ordered (per stream)

It's far better than TCP, but still too opinionated.

The biggest mismatches:

• QUIC forces reliable, ordered delivery within each stream
• QUIC requires handshake and global connection state
• QUIC integrates TLS tightly (not optional)
• QUIC's recovery mechanisms embed semantics Datom.world wants at the interpreter level

Datom.world could adopt QUIC as an optional transport for specific interpreters, but never as the foundation.

The foundation must be maximally unopinionated. UDP provides that.

The Datom.world Transport Layer: Datom Reliable Datagram Streams (DRDS)

Raw UDP is not enough. Datoms need a minimal reliability layer that matches the axioms.

Enter DRDS: Datom Reliable Datagram Streams.

DRDS Properties

• No global order: ordering is per-substream, optional, and interpreter-defined
• Appendability without coordination: nodes can append datoms to streams without the transport layer negotiating state
• Local observation: retransmission is scoped to the local observer's window
• Causality is declared: references between datoms carry meaning; transport doesn't enforce causality
• No global state: endpoints maintain only ephemeral local buffers, not "connections"

DRDS Features

• Sequence numbers (per substream, not global)
• Optional ACK vectors
• Optional reordering
• Optional retransmission policies
• Optional flow control
• Optional forward error correction
• Encrypted payloads (DTLS or custom symmetric)
• Multiplexed paths
• Pluggable congestion algorithms per interpreter

This gives Datom.world:

• Freedom
• Symmetry
• Minimal assumptions
• Transport-level composability

TCP gives you one interpretation of a stream. DRDS gives you all possible interpretations selectable by the interpreter.

The Packet Format

A DRDS packet is simple:

[transport-header, encoded-datom[e a v t m]]

The transport header is minimal:

• Stream/path ID
• Local sequence number (for this sender/stream)
• Optional ACKs / windowing
• Key ID for decryption (optional)

And crucially, never:

• "This packet is causally after that one"

That's the datom's job, not the transport's.

The WireGuard Analogy: Architectural Discipline

WireGuard, one of the cleanest network protocol designs in modern engineering, provides a perfect model for how Datom.world packets should work.

WireGuard packets have two defining properties:

1. Fixed, simple binary layout (predictable, minimal, rigorous)
2. All interpretation is outside the packet (the format encodes no semantics or behavior)

A WireGuard packet is just keys, counters, encrypted blobs, and IDs. What the peer does with the payload is entirely external to the packet format.

A Datom.world packet mirrors this philosophy:

[stream-id | ephemeral-key-id | local-seq | encrypted-datom[e a v t m]]

Both systems treat the packet as an inert object, not a semantic instruction.

The Shared Philosophy

WireGuard says:

"This packet is a cryptographically protected blob tied to a peer and a counter. What the peer does with it is external."

Datom.world says:

"This packet is a cryptographically protected datom. What an interpreter does with it is external."

Both separate transport from semantics:

Where Datom.world Extends the Model

WireGuard packets are purely ephemeral transport units.

Datom packets are persistent interpretable units.

The key differences:

• WireGuard payloads are opaque. Datom payloads have structural invariance, the five-element tuple.
• WireGuard packets carry no semantics. Datom packets carry potential causal references in metadata, but semantics remain external.
• WireGuard supports point-to-point tunnels. Datom.world supports partial ordering, multiple interpreters, entangled clusters, continuation migration, and append-only streams.

But the foundational purity of WireGuard's protocol is exactly the right inspiration.

Five Shared Principles

1. Small fixed-size header → predictable performance

WireGuard uses minimal headers with peer IDs and counters.

Datom.world uses:

• Stream ID (nonce-based, like WireGuard peer IDs)
• Sequence number (like WireGuard counters)
• Ephemeral key ID
• Optional capability token

Everything else is encrypted payload.

2. Everything meaningful is in the payload

• WireGuard: encrypted IP packet
• Datom.world: encrypted datom

3. No global connection state

• WireGuard: stateless roaming
• Datom.world: entanglement with no membership

4. Minimal moving parts

• WireGuard: 4 packet types total
• Datom.world: 1 packet type (a datom)
• Transport-level state is minimal and ephemeral

5. Interpretation is ALWAYS outside the transport layer

This is the shared philosophical core.

WireGuard does not tell you what your IP packet means.

Datom.world does not tell you what a datom means.

Why This Fits Datom.world's Axioms Perfectly

WireGuard's success comes precisely from its refusal to do anything except transport securely.

Datom.world packets behave the same way:

• Axiom 1: Stream = append-only sequence. Transport just moves datoms; it does not determine sequence meaning.
• Axiom 5: Interpretation is external. Metadata m is raw data. Semantics come from interpreters.
• Axiom 6: Causality is referential. Transport is agnostic to causality, exactly how WireGuard treats routing logic.
• Axiom 7: No global state. WireGuard-like statelessness fits entanglement beautifully.

WireGuard is a model of architectural discipline. Datom.world generalizes that philosophy to universal computation.

The Punchline

WireGuard says:

"A packet is a cryptographically authenticated blob."

Datom.world says:

"A packet is a cryptographically authenticated datom."

The structural analogy is deep and correct.

Two Paths: Layering on WireGuard vs. Native Protocol

Datom.world can either layer its packets on top of WireGuard or provide VPN-like functionality with its own native protocol. These aren't mutually exclusive choices, they're stages in an evolution.

Path 1: Layer Datom.world on WireGuard (Pragmatic Path)

What this looks like:

• Underneath: UDP → WireGuard (Noise protocol, key exchange, roaming, NAT traversal)
• On top: Datom packet header + encrypted [e a v t m]
• To the OS: Just another WireGuard tunnel (TUN/TAP, IP ranges)
• To Datom.world: A "secure datagram channel" interface

Why this is good for early deployment:

• Battle-tested crypto and security audits "for free"
• NAT traversal, roaming, key rotation without reinventing anything
• Clean integration with existing OS routing and VPN UX
• Focus on DaoDB, Yin.VM, agents, and entanglement, not protocol minutiae

Crucially: Datom.world's design still holds because WireGuard is just a secure pipe. The semantics, causality, interpreters, and entanglement all live above it.

You treat WireGuard as one adapter that implements:

SecureDatagramChannel:
  send(packet)
  recv() -> packet

The stack is:

UDP → WireGuard → Datom.packet → DaoDB/Yin/Agents

Path 2: Native Datom.world Protocol (Long-Term Vision)

This is the "Datom.world becomes its own mesh/VPN fabric" path.

What this would mean:

• Define a Noise-like handshake and session format directly in the packet header
• Manage peer identity, key rotation, roaming, NAT traversal directly
• Define a Datom-native overlay instead of tunneling IP:
  • Entanglement = overlay network
  • Stream path hierarchy = DNS + routing
  • Capabilities/keys = address + ACL

Why you'd want this eventually:

• No longer think in terms of "IP packets in a tunnel"
• Think in terms of streams of datoms across entangled nodes
• Collapse the stack from UDP → WireGuard → IP → App → Datom.packet to UDP → Datom.sec → Datom.packet
• Secure continuations and datoms directly, not virtual interfaces
• Match the kernel story: crypto-protected memory + crypto-protected streams, same philosophy

But this is a larger surface area:

• More code to write and maintain
• More ways to make cryptographic mistakes
• Needs serious security review and audit if internet-facing

The Recommended Approach: Start with WireGuard, Evolve to Native

The pragmatic path is not to choose between these options, but to evolve through them:

Near/Mid-term:

1. Standardize the Datom packet format and a generic SecureDatagramChannel trait
2. Implement that trait using WireGuard first
3. Stack: UDP → WireGuard → Datom.packet → DaoDB/Yin/Agents

Long-term:

1. Add Datom.sec: a native, Noise-style secure transport over UDP
2. Also implements SecureDatagramChannel
3. WireGuard becomes one of several backends (or a compatibility mode for OS-level VPN use)

This way you don't have to choose "WireGuard vs custom" as a binary decision:

• Standardize the datom packet + channel abstraction
• Start with WireGuard for immediate practical deployment
• Grow into your own secure transport when the complexity is justified

The abstraction layer (SecureDatagramChannel) means the rest of Datom.world (DaoDB, interpreters, agents) doesn't care which backend provides the secure channel. The semantics remain external. The architecture stays clean.

Clean Separation of Concerns

The transport treats the datom payload as an opaque blob. It never looks inside. It never interprets metadata. It just moves bytes.

This keeps the seven axioms intact: interpretation is external, causality is referential, no global state.

Mitigations for UDP's Rough Edges

UDP is minimal, which means some work shifts to the application:

Reliability

Implement selective retransmits at the DRDS level, keyed on transaction/metadata hashes. Only refetch missing causal prerequisites.

An interpreter that needs total reliability can request it. An interpreter that tolerates loss doesn't pay the cost.

Congestion

Use app-level rate limiting (e.g., tied to Shibi tokens) or lightweight helpers like LEDBAT.

Congestion control becomes an economic question, not a transport mandate.

NAT Traversal

Pair with WebRTC (UDP-based) for NAT traversal and ICE, common in browser/device ecosystems.

This makes Datom.world practical for peer-to-peer, local-first, mobile-friendly deployments.

Security

Encrypt datom payloads (e.g., via Noise Protocol) without relying on transport.

Security becomes pluggable. Different streams can have different security policies based on interpreter needs.

The Architectural Answer

The Core Insight

TCP says:

"I will decide the shape of the stream for you."

Datom.world says:

"The shape of the stream is always the datom; everything else is interpretation."

UDP gives you the raw substrate where the stream is just packets.

DRDS gives the minimal structure compatible with Datom.world axioms.

Interpreters bring the semantics.

That separation is the power.

Why This Matters

This isn't academic. The choice between TCP and UDP determines whether Datom.world can:

• Support mobile agents: Continuations that migrate between nodes without tearing down connections
• Enable local-first computation: Nodes that collaborate opportunistically without central coordination
• Allow multiple causal interpretations: Different agents viewing the same stream with different ordering assumptions
• Scale to IoT and mesh networks: Ephemeral, low-power, intermittent connectivity scenarios
• Preserve semantic clarity: Transport never lies about what it guarantees

TCP would force Datom.world into a client-server, connection-oriented, globally-ordered model. That's the opposite of what the system is designed to be.

UDP with DRDS keeps the substrate clean and lets interpreters make their own choices about reliability, ordering, and semantics.

Conclusion

The choice of UDP over TCP isn't about performance. It's about philosophical alignment.

TCP embeds semantics that Datom.world rejects:

• Global order
• Mandatory reliability
• Connection state
• Transport-level causality

UDP provides a clean slate:

• No assumptions
• No hidden semantics
• No global state
• Just raw packet delivery

DRDS adds the minimal structure needed to make datom streams practical while preserving their fundamental nature.

Causality lives in the datom. Semantics live in the interpreter. Transport is just transport.

That's how it should be.

Learn more:

• Structure vs Interpretation (why semantics must be external)
• The Power of Restriction (why the five-element tuple enables freedom)
• Continuations as Universal Semantic Kernel (why continuations is rich enough to represent semantics of all languages)
• Computation Moves, Data Stays: The Yin.vm Continuation Model (how continuations become lightweight enough to migrate)
• DaoDB (the stream database powering Datom.world)