OpenHaven Sovereign Stack Model — Comparative Reference

v3 / TCP/IP, OSI, and OpenHaven Sovereign Stack side by side

A reference diagram comparing three layer models of the networked stack: the four-layer DARPA TCP/IP model that describes the working internet, the seven-layer OSI reference model used pedagogically and in standards work, and the nine-layer OpenHaven Sovereign Stack Model — developed across the OpenHaven, Collaborative Technology Alliance (CTA), and DWeb working groups to make digital-sovereignty architecture decisions legible. Each model carves the same architectural ground for a different purpose. Connectors between the tables show where cross-model analogues are direct, skewed across layers, or absent (dashed stubs to a callout below).

Direct analogue
Skewed analogue
No analogue / distributed

Layer-by-layer comparison

Three models side by side. Connector lines drawn after layout via measured cell positions. Row heights scaled so analogues align horizontally where possible; relationships not aligned are drawn diagonally in rust. The OSI L5 Session row links to a callout card below explaining why session has no Sovereign Stack analogue.

TCP/IP DARPA four-layer
L4
Application
L3
Transport
L2
Internet
OSI Seven-layer reference
L7
Application
L6
Presentation
L5
Session
why no Sov analogue
L4
Transport
L3
Network
L1
Physical
Sov Layer Name
OpenHaven Sovereign Stack Description & examples
L9
Application / Interface
The user-facing layer where applications expose the layers below to people and other agents. Accommodates two paradigms simultaneously: thin "bring your own everything" interfaces that expose data, identity, and protocols from the layers below with minimal added logic; and thicker applications that bundle additional logic, schemas, and storage on top of decentralized substrates. Both currently exist in the ecosystem.
e.g.BlueSky · Holons · Logseq · Mobilizon · PeerTube
L8
Federation
Server-to-server protocols where independently operated instances maintain peer relationships to exchange messages, content, or coordination on behalf of their users. Supports portability of identity and content across server boundaries without a central intermediary. Distinguished from peer coordination by the persistent server layer between protocol and end user.
e.g.ActivityPub · ATProto · Matrix · KOI-net
L7
Peer Coordination
Where decentralized peers coordinate — where P2P platforms expose their developer abstractions, where integrated runtimes do their constitutive work, and where many P2P protocols' interaction patterns live. Some suites and integrated runtimes subsume this layer entirely, replacing its conventional shape with their own architectural commitments.
e.g.Holochain · Veilid · Ditto · NextGraph · Trunk
L6
Community Data & Governance
Where shared community data lives and where governance decisions about that data are made and enforced — the substrate for collectively held knowledge, agreements, and collaborative state. Distinct from individual identity below and federation above; this is where a "we" of many becomes operationally legible to the systems acting on its behalf.
e.g.Holons spaces · CRDT-based community stores
L5
Identity & User Sovereignty
Where identifiers, credentials, and the cryptographic primitives that anchor "who is acting" are established, resolved, and verified. Distinct from data semantics below and from community governance above. The architectural commitment is that identity is rooted in keys held by parties rather than in records held by central registries.
e.g.W3C DIDs · W3C VCs · DIDComm · KERI · XID
L4
Data & Semantic
Specifications for describing, structuring, naming, and linking data so it is interpretable across systems regardless of where it is stored or what reads it. Vocabularies, schemas, identifier registries, content addressing, and selective-disclosure formats live here. The Sovereign Stack treats this as a load-bearing infrastructure layer below identity, on the architectural commitment that meaningful data is the substrate identity-bearing actors operate over.
e.g.JSON-LD · Murmurations · Valueflows · Gordian Envelope · RIDs
L3
Overlay Network
Logical networks built on top of the underlying IP-routed internet — DHTs, onion routing, mesh routing, libp2p-style overlay topologies, censorship-resistant transports. Distinct from the underlying L1/L2 networking substrate: an overlay network adds peer discovery, alternative routing, anonymization, or topology that the base internet does not provide.
e.g.libp2p · Tor · I2P · Snowflake · Conduit
L2
Transport / Channel
Where end-to-end delivery, reliability, encrypted-channel establishment, and transport-protocol choices live. Includes TCP and UDP but also QUIC, WebRTC, WebSockets, encrypted-channel protocols (Noise, WireGuard), and alternative transports for mesh networking (LoRa, packet radio). Sovereignty-relevant transport choices are increasingly load-bearing.
e.g.QUIC · WebRTC · Noise · Reticulum · Meshtastic
L1
Physical / Network
The commoditized substrate of physical media and network-layer routing. Mostly invisible to sovereignty-architecture decisions because the choice of Ethernet vs. Wi-Fi, or of which IP routing protocol is in use, rarely changes a system's sovereignty character. The Sovereign Stack collapses this territory into a single layer to keep the model's resolution focused on the layers above.
e.g.Ethernet · Wi-Fi · Cellular · IP routing
Card 1 / Framing

What the Sovereign Stack Model is and isn't

The Sovereign Stack Model is not a generic networking model. It is an opinionated model of the layers at which architectural choices about digital sovereignty get made. That framing distinguishes it from TCP/IP (which models the working internet) and from OSI (which models networking layers for pedagogy and standards development).

The model collapses lower layers — physical media, data link, IP-layer routing — into a single L1 because those layers are largely commoditized for sovereignty purposes. It elaborates the upper layers because that is where adopters' sovereignty commitments actually live: identity, community data, governance, federation, application paradigm.

The trade-off is intentional. The model has high resolution where adopters need it (six layers above transport, where most decentralization-relevant decisions get made) at the cost of lower resolution at layers most adopters don't decide about (physical and IP-layer infrastructure).

Card 2 / Comparison

How the three models relate

TCP/IP, OSI, and the Sovereign Stack are three ways of carving the same architectural ground for different purposes.

TCP/IP optimizes for the working internet — minimal layers, focus on what implementers actually build to. OSI optimizes for pedagogical and standards-development clarity — more layers, more granular separation of concerns. The Sovereign Stack optimizes for digital-sovereignty decision-making — different layers entirely above the transport substrate, focused on where adopters' sovereignty commitments actually live.

None of the three is "more correct" than the others. They answer different questions. A network engineer debugging an issue reaches for TCP/IP. A standards body designing a new protocol reaches for OSI. An adopter trying to decide which decentralized stack to bet on reaches for something like the Sovereign Stack.

Card 3 / Analogues

Where the analogues are clean and where they're not

Direct horizontal analogues are clean for the transport layer — TCP/IP Transport, OSI L4 Transport, and Sov L2 Transport / Channel all agree on what transport is. Below transport, the three models carve differently but share the territory.

Skewed (diagonal) analogues appear at OSI L3 Network and TCP/IP Internet, which sit just below Sov L3 Overlay Network — the Sovereign Stack's overlay networks are built on top of the routed internet, not at the same layer. Similarly, OSI L6 Presentation is mostly absorbed into Sov L4 Data & Semantic, since the Sovereign Stack treats data format and data semantics as integrated rather than separately layered.

For the third major asymmetry — OSI L5 Session having no Sovereign Stack analogue — see the dedicated card below.

Card 4 / OSI L5 Session

Why OSI Session has no Sovereign Stack analogue

OSI's Session layer handles establishing, maintaining, and recovering long-running interactions between endpoints — synchronization checkpoints, dialog control, and session resumption after interruption. The Sovereign Stack does not extract these concerns into a single layer, because in the decentralized-systems landscape session is handled at different layers depending on the entity:

QUIC handles connection-session at Sov L2 Transport / Channel — connection migration, 0-RTT resumption, per-stream flow control. Willow's sync sessions live at Sov L4 Data & Semantic — area-of-interest negotiation, reconciliation rounds, resumption support. DIDComm's threaded-message continuity lives at Sov L5 Identity & User Sovereignty — thread IDs, parent thread IDs, message rotation. ActivityPub instance peering handles its own session-equivalents at Sov L8 Federation — server-to-server delivery semantics.

The choice of which layer handles session is itself a sovereignty-architecture decision. Pulling session into a single Sov layer would obscure that choice — collapsing meaningfully different architectural commitments into a deceptive uniformity. The Sovereign Stack's omission is deliberate: session is real and important, but it is properly understood as a concern that crosses layers rather than as a layer of its own.

Card 5 / Origins

Where this model came from

The OpenHaven Sovereign Stack Model emerged from collaborative work across three overlapping working-group communities, each contributing complementary framing.

The Collaborative Technology Alliance (CTA) is a coalition of organizations and individuals working on prosocial, decentralized, and commons-oriented technology. OpenHaven is CTA's peer-to-peer technologies breakout group — the same project under a working name — and is the primary site where this model is maintained and refined as new entities surface and the taxonomy evolves. DWeb (the Internet Archive's Decentralized Web project, including DWeb Camp and DWeb Working Groups) provides a broader convening space for decentralized-tech practitioners and contributes the social-and-political framing of "digital sovereignty" that motivates the model's upper layers.

The model is attributed to this collaborative effort rather than to any single organization. As the entity catalog grows and new architectural patterns emerge in the ecosystem, the model is expected to evolve through the same working-group process — with revisions surfaced for community review rather than imposed unilaterally.