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 (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. SSM L4 through L9 zoom into what OSI calls the application layer (L7) and what TCP/IP calls Application (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 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 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 SSM L2 Transport / Channel — connection migration, 0-RTT resumption, per-stream flow control. Willow's sync sessions live at SSM L4 Data & Semantic — area-of-interest negotiation, reconciliation rounds, resumption support. DIDComm's threaded-message continuity lives at SSM L5 Identity & User Sovereignty — thread IDs, parent thread IDs, message rotation. ActivityPub instance peering handles its own session-equivalents at SSM 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 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 layers, 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 L5, what they place at L8, 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 L4 (Data & Semantic), L5 (Identity & User Sovereignty), L6 (Community Data & Governance), L7 (Peer Coordination), or L8 (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 L4 produces verifiable data structures that any layer above can rely on. Implemented at L7, it produces a peer-coordination substrate with built-in tamper-evidence. Implemented at L8, 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 (current, 2026) incorporates revisions from the V2 review cycle and ongoing input from the broader Collaborative Technology Alliance, OpenHaven, and DWeb communities.
Feedback is welcome. To suggest revisions, raise an issue, or contribute to future versions, contact Brandon Nørgaard at brandon@civicenlightenment.org.