OpenHaven Entity Placement — Sovereign Stack Reference

v3 / Selected entities placed against the OpenHaven Sovereign Stack Model

A reference diagram placing a curated selection of OpenHaven-tracked entities at their primary stack-model layers. The layer model used here is the OpenHaven Sovereign Stack Model, developed across the OpenHaven, Collaborative Technology Alliance (CTA), and DWeb working groups. Entities are drawn from the OpenHaven taxonomy weighted toward those with substantive real-world adoption and developer attention. Chip border color indicates entity type (definitions in the reference card below). Hover any chip for a brief description, key attributes, and primary URL. Spanning entities — those whose architectural commitment crosses multiple layers — are marked with one of four spanning visualizations: occupies, abstracts over, subsumes, and suite. This diagram is a sample, not a comprehensive map. Spanning is shown for a few illustrative cases (Holochain, AD4M, NextGraph, the suites); many entities placed here with genuine multi-layer reach are not yet marked as spanning. The comprehensive picture and dynamic functional groupings will be generated programmatically once OpenHaven's data is migrated into a relational database with a complementary graph layer.

Entity placement

Layers run L9 (Application / Interface) at the top down to L1 (Physical / Network) at the bottom, matching the OpenHaven Sovereign Stack Model. Each entity sits at its primary layer; spanning relationships are shown as overlay markers (see legend). The selection is illustrative rather than exhaustive — it includes the most widely-adopted entries from each entity type plus all members of the suites being marked. Scroll horizontally if entity rows extend past the viewport.

Application / Interface

BlueSkyMastodonPeerTubeMobilizonLogseqAFFiNEAnytypeNextcloudHolonsNDN WorkspaceGroup Income

A2A

Federation

ActivityPubATProtoMatrixSolidNostr (relay federation)

KOI-net

Peer Coordination

Holochain

AD4M

NextGraph

Gordian Clubs

VeilidDittoActivityPods

Community Data & Governance

BonfireSemApps

TRQPOpenVTC

Identity & User Sovereignty

XID

FANFedID

Data & Semantic

Gordian Envelope

IPFSFilecoin

JSON-LDMurmurationsValueflowsCeramicWillowIrohMCPERC-8004SIWEERC-4337

RIDsW3C VCs

Overlay Network

Hubert

libp2p

KitsuneTorI2PSnowflakeNostrCashu

DIDCommTSP

Transport / Channel

NoiseReticulumMeshtasticTor (onion routing)I2P (garlic routing)

W3C DIDs

Physical / Network

Chip border — maturity

A chip's border style indicates the entity's maturity level. Border color still encodes entity type (see definitions card below).

Solid

Mature — stable production release with broad adoption and active deployments. Examples: Mastodon, IPFS, libp2p, W3C DIDs.

Dashed

Alpha / Beta — has working implementations but not yet a stable production release. Specifications still evolving; deployments limited or in early adoption. Examples: FAN, FedID, KOI-net, Gordian Envelope.

Dotted

Spec only — specification or draft exists, but no known production-deployed implementations yet. May have reference code only. Examples: TSP (Implementers Draft), TRQP (Public Review), ERC-8004 (ERC Draft).

Spanning markers

Spanning entities are rendered as bands that wrap around their member chips. The band's outline style encodes the kind of spanning. Each (band, row) intersection can carry a small ⓘ indicator — hover it for an explanation of what is happening at that specific layer.

Occupies Solid ink band. One integrated runtime implemented across multiple layers; components inseparable. Examples: Holochain (L4 + L7 + L9), NextGraph (L3 through L9).

Abstracts over Dashed violet band. Provides a unified abstraction layer over pluggable substrates at multiple layers. Example: AD4M.

Subsumes (within band) A crossed-circle marker placed inside the band on a particular row indicates the entity subsumes that layer's traditional function rather than implementing it. Example: AD4M Neighbourhoods replacing federation at L8.

Suite Dashed band in suite-specific color. Co-designed separable components composing into a coherent solution; members remain individually replaceable. Examples: Gordian Suite (gold), KOI (teal), W3C SSI Suite (violet), ToIP Suite (sage).

Entity Type Definitions

P2P Protocol

A formal specification defining message formats, routing, and interaction patterns enabling nodes to communicate and coordinate without prescribing implementation. Wire-level concerns; the protocol is separable from any specific implementation.

P2P Platform

Reusable developer infrastructure built on top of one or more external protocols, providing SDKs, identity, storage, and composable services that applications consume. The platform is built atop, not co-designed with, its underlying protocols.

Integrated P2P Runtime

A technology where data model, sync protocol, security architecture, and application development environment are co-designed as a single inseparable whole. The protocol does not exist independently of its runtime.

P2P Infrastructure

Operational live node networks providing transport, routing, privacy, or access services that other systems depend on. Defined by being a running service rather than a specification, typically designed for adversarial conditions.

Decentralized Data Protocol

A specification for how structured data is named, addressed, replicated, and synchronized across a P2P network. Concerned with content addressing, sync algorithms, and mutability semantics rather than with how nodes communicate or what data means.

Federation Protocol

A communication architecture where users connect to independently-operated servers (instances), and those servers maintain peer relationships to route messages, share content, or coordinate activity on behalf of their users.

Semantic & Data Protocol

A formal specification for describing, structuring, or linking data so it is interpretable across systems, applications, and organizations without shared implementation. Vocabularies, schemas, and graph models for portable semantics.

Identity Protocol

A formal specification defining identifier creation, credential issuance, authentication, or trust establishment, without prescribing implementation. The specification is separable from any particular toolkit.

Identity Toolkit / Platform

Developer infrastructure implementing one or more Identity Protocols and exposing their capabilities through SDKs, APIs, or frameworks. Working software for builders rather than a specification document.

Identity System / Design

A novel architecture proposing a fundamentally new approach to identity, trust, or personhood, articulated as a white paper or research note. The primary contribution is the architectural insight rather than working software.

Decentralized Application

An end-user software product performing specific bounded tasks using decentralized protocols, with a clear boundary between using the application and building on it. Users consume the application's functionality.

Extensible Decentralized App

A decentralized application where the boundary between using and building is dissolved by design. Composability and extension are intrinsic; users assemble new functionality within the application's own interface.

Smart Contract Standard

A formal specification whose primary realization is one or more on-chain deployable contracts. The deployed contract is not an implementation of the standard but the standard itself, instantiated as shared on-chain state.

Decentralized Storage Network

A network where distributed node operators provide persistent data storage capacity to users, sustained through cryptoeconomic incentives, volunteer contribution, or cooperative governance. Defined by persistent custody as the core service.

Spanning

Four kinds of layer-spanning entities

OpenHaven recognizes four architecturally distinct ways an entity can span multiple layers of the Sovereign Stack. Each spanning entity is rendered as a band that wraps around its member chips and passes through the rows it spans; the band's outline style identifies which kind of spanning it is.

Occupies — the entity is a single integrated runtime whose components at each layer are inseparable from each other (Holochain at L4 + L7 + L9; NextGraph spanning L3 through L9).
Abstracts over — the entity provides a unified abstraction layer over pluggable substrates, allowing the underlying layer-specific implementations to be swapped without changing the abstraction (AD4M).
Subsumes — appears as a marker inside another band on a specific row, indicating that the entity replaces that layer's traditional function with a different mechanism. AD4M's Neighbourhoods, for instance, replace federation rather than implementing it.
Suite — a co-designed family of separable components, each at its own layer, designed together to compose into a coherent solution while remaining individually replaceable (Gordian Suite, KOI, W3C SSI Suite, ToIP Suite, Protocol Labs Suite).

Each (band, row) intersection can carry an ⓘ indicator, surfacing intersection-specific contextual information on hover — useful for cases like AD4M's relationship to federation, where the architectural commitment at that specific layer needs explanation. The unified band grammar lets all four spanning types share a single visual logic.

Pathways

Adoption pathways and functional clusters

Entities in OpenHaven are typically adopted through functional clusters rather than as solo components. Clusters that have emerged in current ecosystem practice include:

SSI / digital-trust — DIDs, VCs, DIDComm at the lower layers, with TSP and TRQP as spanning protocols.
Fediverse social — ActivityPub-based applications (Mastodon, PeerTube, Mobilizon, Bonfire) and adjacent protocols.
Civic-coordination & peer-funding — Murmurations, Valueflows, Bonfire, Holons, and emerging knowledge-organization infrastructure like KOI.
Agent economy — MCP, A2A, x402, ERC-8004; a young cluster forming around the agentic-AI moment.
Self-custody and personal data — the Gordian Suite's tools for cryptographic self-sovereignty.
Decentralized storage and content delivery — the Protocol Labs Suite (libp2p, IPFS, Filecoin) for content-addressed data and persistent decentralized storage.

These clusters are not mutually exclusive — a single deployment commonly composes across pathways (SSI plus Fediverse, or civic-coordination plus self-custody). Functional groupings will be more legible in dynamic diagrams once OpenHaven's data is migrated into a graph-queryable layer; this static reference does not attempt to render them.

Gaps

Coverage gaps the diagram reveals

Surveying the diagram surfaces a few places where OpenHaven's entity coverage or taxonomy could grow.

Supporting libraries are invisible — CRDT engines, cryptographic primitives, and serialization libraries (Loro, Yjs, Automerge, BLAKE3 implementations, libsodium) run in-process inside the entities OpenHaven currently classifies but have no entity type of their own. Whether to add a Sub-layer Component or Sync Engine type is an open question deferred until after the database migration.
The agent-economy cluster fits awkwardly in P2P Pro — MCP, A2A, and x402 are client-server specifications rather than peer-to-peer in the architectural sense. Their inclusion follows the precedent set by adjacent open multi-implementor specifications, but the fit is structural rather than ideal.
L2 Transport / Channel is sparsely populated relative to the layer's growing importance. QUIC, WebRTC, WebSockets, and the encrypted-channel protocols beyond Noise are sovereignty-relevant but not yet individually tracked.

These observations are conservative — they identify gaps OpenHaven's contributors are already aware of rather than making claims about deployment scale or community size that would require independent verification.