Sovereign Stack Model (SSM) — Comparative Reference

v4 / TCP/IP, OSI, and Sovereign Stack side by side

See also: Entity Placement · Feedback: brandon@civicenlightenment.org

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 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).

SSM classifies architectural responsibilities related to digital sovereignty — it is not a protocol-layer model and not a map of required software modules. Its layers represent separable architectural concerns, not implementation boundaries a codebase must respect: a single system may legitimately discharge several layers' responsibilities at once — an integrated P2P runtime doing so is a common, expected pattern, not an exception to the model. Read each layer as a responsibility something in the stack must satisfy, not as a box any one component is required to occupy alone.

At the top level, SSM has four layers: Network (L1), Transport (L2), Community Trust (L3), and Applications (L4). Community Trust gets outsized attention here because it's the layer today's internet never really built — verifying real people, letting groups (not just individuals) act as first-class participants, and letting trust travel across community boundaries all still lack a protocol-level answer. Because so much sovereignty-relevant architecture lives at this one layer, it's further divided into six sub-layers (3.1 through 3.6, shown as the rail alongside them 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

Application

Transport

Internet

Link

OSI Seven-layer reference

Application

Presentation

Session

why no SSM analogue

Transport

Network

Data Link

Physical

SSM Layer Name

Sovereign Stack Description & examples

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. As a design norm rather than just an observed pattern: applications should primarily compose capabilities the layers below already provide rather than rebuilding them, and should stay relatively lightweight whenever the lower-layer sovereignty capabilities they need — identity, governance, data semantics, coordination — already exist. Thickness is a legitimate choice when a genuinely new capability doesn't yet exist below it, not a default.

e.g.BlueSky · Holons · Logseq · Mobilizon · PeerTube

L3 Community Trust

L3.6

Federation

The layer of intermediary-operated instances that maintain canonical state on behalf of users and exchange that state with other instances through server-to-server protocols — coordinating between independently governed systems via federation, gateways, and inter-domain interoperability, rather than direct peer-to-peer coordination. What distinguishes federation from peer coordination (L3.5) is the persistent instance layer between protocol and end user: in federation, an instance owns the user's relationship to the network; in peer coordination, the user owns it directly. Supports portability of identity and content across instance boundaries without a central intermediary — federation protocols should ideally preserve the identities, governance structures, and semantic data already established at L3.3/L3.4/L3.2 rather than redefining them at the federation boundary; portability across federation protocols is itself a stated design objective at this layer, not just a side effect.

e.g.ActivityPub · ATProto · Matrix · KOI-net

L3.5

Peer Coordination

Where decentralized peers coordinate — runtimes and distributed-execution engines synchronizing state, replicating data, and reconciling concurrent changes across peers, plus the developer abstractions P2P platforms expose for this work and the interaction patterns many P2P protocols define. Some suites and integrated runtimes subsume this layer entirely, replacing its conventional shape with their own architectural commitments. Coordination at L3.5 should ideally consume the identity, governance, and semantic-data commitments already established at L3.3/L3.4/L3.2 rather than embedding an incompatible identity model of its own — portability of peers and their state across runtimes is a stated design objective at this level.

e.g.Holochain · Veilid · Ditto · NextGraph

L3.4

Community Data & Governance

Where governance is established for institutions, organizations, communities, and any collective engaged in decision-making — 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. Governance is intentionally a separate layer from L3.3 identity below, not an extension of it: a "we" of many possesses forms of agency that are not reducible to the identities of its individual members, so this is where that collective agency becomes operationally legible to the systems acting on its behalf. Distinct from federation above (L3.6), which coordinates between already-governed systems rather than constituting governance itself.

e.g.Holons spaces · CRDT-based community stores

L3.3

Identity & User Sovereignty

Where sovereign identity is operationally bound to acting parties — individuals, devices, or software agents — the layer at which the question "who is acting?" is answered at the moment of action. Identifier primitives, data structures, and trust messaging have their structural homes at lower layers; L3.3 is where these converge to authenticate a person, the keys they control, and the device or agent acting on their behalf. The architectural commitment is that this binding is rooted in keys held by parties rather than in records held by central registries — and that "who is acting?" must be verifiable at the edge, not delegated to a registry. Governance for collectives lives at the layer above (L3.4), deliberately kept separate — see L3.4 for why.

e.g.FAN · FedID · KERI · XID

L3.2

Data & Semantic

Specifications for describing, structuring, naming, and linking data so that its meaning — not just its structure — is interpretable across independently-built systems, regardless of where it is stored or what reads it. This is more than "structured data": L3.2 establishes shared, interoperable data models and semantics — common vocabularies and schemas that let systems built by different parties agree on what a piece of data actually means. Vocabularies, schemas, identifier registries, content addressing, and selective-disclosure formats live here. Data at this layer is generally impersonal — it has no owner or acting party bound to it yet; that binding happens at L3.3, where identity and authority are established. The Sovereign Stack treats L3.2 as a load-bearing infrastructure layer below identity, on the architectural commitment that meaningful, shared data is the substrate identity-bearing actors operate over.

e.g.JSON-LD · Murmurations · Valueflows · Gordian Envelope · RIDs

L3.1

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

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

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.

Explicit mapping to OSI and TCP/IP. SSM L1 absorbs OSI L1–L3 and TCP/IP L1–L2 — the physical, link, and routing substrate — because those layers are commoditized for sovereignty purposes. SSM L2 (Transport / Channel) is a direct analogue of OSI L4 / TCP/IP L3. SSM L3.1 (Overlay Network) has no OSI or TCP/IP analogue; it sits above the routed internet rather than at the same level, and it is optional — systems that don't use overlay networks pass through it. The rest of SSM's upper stack — L3.2 through L3.6 (the remaining five Community Trust sub-layers) plus L4 (Application / Interface) — zoom into what OSI calls the application layer (L7) and what TCP/IP calls its own, separately-numbered Application layer (also labeled L4 in that model, distinct from SSM's L4): they exist because that is where sovereignty decisions live.

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 SSM L2 Transport / Channel all agree on what transport is. Below transport, the three models carve differently but share the territory.

Skewed (diagonal) analogues appear in two places. OSI L3 Network and TCP/IP Internet are absorbed into SSM L1 — the Sovereign Stack collapses the IP-routing substrate into a single foundational layer rather than separating physical, link, and network routing. SSM's L3.1 Overlay Network is a different concept entirely (overlay networks built on top of the routed internet, not the routed internet itself). Similarly, OSI L6 Presentation is mostly absorbed into SSM L3.2 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 SSM L2 Transport / Channel — connection migration, 0-RTT resumption, per-stream flow control. Willow's sync sessions live at SSM L3.2 Data & Semantic — area-of-interest negotiation, reconciliation rounds, resumption support. DIDComm's threaded-message continuity lives at SSM L3.3 Identity & User Sovereignty — thread IDs, parent thread IDs, message rotation. ActivityPub instance peering handles its own session-equivalents at SSM L3.6 Federation — server-to-server delivery semantics.

The choice of which layer handles session is itself a sovereignty-architecture decision. Pulling session into a single SSM 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 / Methodology

How SSM differs from generic capability mapping

There are two ways to organize a description of what a complex system does. One is capability mapping — identifying the discrete capabilities a system provides and laying them out as a graph or hierarchy, with relationships between them. The other is layered modeling — committing to a small number of ordered layers, each with a defined role, and placing capabilities within them. SSM is the latter.

Capability mapping has real strengths. It captures complexity faithfully, accommodates new capabilities easily, and doesn't force commitments where they aren't yet warranted. The cost is that each map is bespoke — comparison across maps is hard, and the lack of overarching structure makes capability maps difficult to use for decision-making.

SSM commits to a layered structure with a defined schema: nine numbered layer-positions — L1, L2, the six-part Community Trust layer (L3.1–L3.6), and L4 — each with a specific role, and entities placed at their primary home layer (sometimes spanning multiple). The cost of this approach is that some information gets lost — particularly cross-cutting concerns and capabilities that don't fit cleanly into a single layer. The benefit is that comparison becomes possible: two architectures can be examined for what they place at L3.3, what they place at L3.6, what they leave empty.

That comparison is the purpose. SSM is designed for adopters trying to choose between decentralized stacks, contributors trying to understand where their work fits, and researchers trying to identify gaps in the landscape. All three benefit from a shared layered vocabulary in ways that a bespoke capability map cannot provide.

The methodological choice is intentional and load-bearing. SSM trades faithfulness for legibility — choosing structure that enables comparison over structure that captures every nuance.

Card 6 / Cross-cutting concerns

Properties that don't belong at any single layer

Some architectural properties cut across layers rather than living at one. Immutable history, content addressing, Merkle-linked audit trails, versioning, and replayable state are protocol-level choices that may be implemented at L3.2 (Data & Semantic), L3.3 (Identity & User Sovereignty), L3.4 (Community Data & Governance), L3.5 (Peer Coordination), or L3.6 (Federation) depending on the protocol. None of these properties has a single layer where it always lives.

The layer at which a protocol implements such a property is itself a sovereignty-relevant architectural commitment. Content addressing implemented at L3.2 produces verifiable data structures that any layer above can rely on. Implemented at L3.5, it produces a peer-coordination substrate with built-in tamper-evidence. Implemented at L3.6, it produces federation with cryptographic accountability between instances. These are meaningfully different architectural worlds, even though the underlying technique — hashing content to address it — is the same.

SSM does not pull these concerns into a layer of their own because doing so would obscure exactly the choices that matter most. A reader encountering content addressing in an SSM placement should ask: at which layer does this protocol implement it, and what does that placement commit the architecture to? The same question applies to immutable history, audit trails, and versioning. The cross-cutting nature of these properties is a feature of the model, not a gap.

A note on language: when an entity description mentions one of these properties, the property is being implemented at the entity's primary layer unless otherwise noted. Entities that implement cross-cutting properties at multiple layers — common for integrated runtimes — surface this in their entity profile rather than in the layer model itself.

Card 7 / Origins

Where this model came from

The 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.

Card 8 / Version history

Versions and contributors

The Sovereign Stack Model is a working artifact developed through iterative drafts and community review.

V1 (2025) was produced by the World Wise Web working group with contributors Brad deGraf, Josh Field, Day Waterbury, and Brandon Nørgaard.

V2 (2026) was presented at the Internet Identity Workshop XLII (IIW 42), where it received feedback that informed subsequent revisions.

V3 (2026) incorporates revisions from the V2 review cycle and ongoing input from the broader Collaborative Technology Alliance, OpenHaven, and DWeb communities.

V4 (current, 2026) regroups the middle six layers under a subdivided Community Trust layer (3.1–3.6) and renumbers Application / Interface to L4, aligning the model's top level to four layers: Network, Transport, Community Trust, and Applications.

Feedback is welcome. To suggest revisions, raise an issue, or contribute to future versions, contact Brandon Nørgaard at brandon@civicenlightenment.org.