An OpenHaven Entity is a discrete, nameable technology component that is
developed, maintained, and described with sufficient independence that it can be meaningfully
compared with others of its class, tested in isolation or combination, and referenced by a
consistent name and primary URL as a shared anchor of understanding within its community. An
entity may encompass one or more of the following: a collaborative project, a code repository,
a standards document, or a deployed artifact — but what makes it an entity is not its internal
complexity, but the degree to which it functions as a coherent, identifiable unit of the
decentralized technology landscape.
- Referentiability
- a stable name and URL that practitioners use to mean the same thing
- Comparable class membership
- it can be evaluated against peers of the same type (hence entity types)
- Operational testability
- you can get it running and observe its behavior
- Relative independence
- it has its own development lifecycle, governance, and documentation, even if it depends on other entities
A quick side-by-side reference — see each entry below for the full picture.
A formal specification for how nodes communicate, route, and coordinate in a distributed system — implementable by anyone from the document alone, independent of any particular toolkit or runtime.
Key Properties
- Independently publishable spec — a document, not a piece of software 📄
- Message format & serialization rules are explicitly defined
- Routing, discovery, or synchronization rules are part of the spec
- Conformant implementations interoperate without coordinating with each other
- The wire format, reference implementation, and dev tooling are separable artifacts that evolve independently
Differs from
- P2P Platform : A protocol defines what nodes say to each other; a platform is what developers build on top of an existing protocol to make that easier.
- Integrated P2P Runtime : A protocol is separable from its implementation — reference code, SDKs, and the wire format can evolve independently. A runtime co-designs all of that as one inseparable whole.
- P2P Infrastructure : A protocol is a set of rules; infrastructure is the live, operated network of nodes actually running those rules.
- Decentralized Data Protocol : A P2P Protocol's concern is how nodes communicate and discover each other; a Decentralized Data Protocol's concern is how the data itself is named, synced, and reconciled once communication already exists.
Examples: Nostr, Meshtastic, Noise Protocol Framework
Developer infrastructure — SDKs, tooling, and runtime services — for building decentralized apps on top of one or more external protocols the platform doesn't itself define.
Key Properties
- Built on external protocols, not its own wire format
- Provides an SDK or API developers build against 🧰
- Adds identity, sync, and storage abstractions apps would otherwise reimplement
- Multiple independent apps can coexist on the same network
Differs from
- P2P Protocol : A protocol is something you implement from scratch; a platform is something you build on top of.
- Integrated P2P Runtime : A platform's underlying protocol is, in principle, separable and could be reimplemented by other tools. In a runtime, the protocol only exists for and because of that runtime.
- Decentralized Application : A platform's primary artifact is developer infrastructure; applications are built on it, not the platform itself.
Examples: Ditto, Trunk, SemApps
A technology where the data model, sync protocol, security architecture, and dev environment are co-designed as one inseparable whole — you don't use the protocol, you build inside the runtime.
Key Properties
- Protocol and toolkit are inseparable — neither exists independently of the other
- User-sovereign data ownership is an architectural guarantee, not a policy 🔐
- App logic is decoupled from storage — data outlives any one app
- Identity is baked into the protocol layer, not bolted on
Differs from
- P2P Protocol : A P2P Protocol's implementations are separable and interoperate freely; a runtime's toolkit is a constitutive part of what the protocol even is.
- P2P Platform : A platform is built atop a protocol it didn't define; a runtime owns and defines its protocol as an intrinsic part of its own design.
- Decentralized Application : A runtime is developer infrastructure — an environment apps are built within — not an end-user product itself.
Examples: NextGraph, Holochain, ADAM
An end-user software product with a defined boundary between the app and users — people consume its functionality, they don't extend or reprogram it.
Key Properties
- End-user product, not developer infrastructure
- Bounded, specific tasks — messaging, publishing, file sharing, coordination
- Works for end users without exposing the underlying protocol
- Decentralization is an implementation choice, not a user-facing surface
Differs from
- Extensible Decentralized App : A D App keeps a real boundary between using it and building on it; an Ext D App dissolves that boundary by design.
- P2P Platform : A platform's primary artifact is infrastructure for other developers; a D App's primary artifact is the end-user product itself.
- Integrated P2P Runtime : A D App is built on top of an external protocol or platform; it isn't inseparable from one the way a runtime is.
Examples: AFFiNE, Logseq, Appflowy
A decentralized app where using it and building on it are the same act — extension and composition are intrinsic to the architecture, not a bolted-on plugin system.
Key Properties
- User-composable building blocks let non-developers assemble new functionality 🧩
- Exposed data model other apps/agents can read, write, or build on directly
- No hard line between consuming and creating in the same environment
- Immediately useful to end users while also being an extension platform
Differs from
- Decentralized Application : A D App has an intentional boundary between user and developer; an Ext D App treats that boundary as a design flaw to eliminate.
- P2P Platform : A platform's apps are built on top of it as separate things; an Ext D App is itself the working application, with platform-like properties emerging from within it.
- Integrated P2P Runtime : A runtime's defining trait is a unified protocol-plus-environment at the infrastructure layer; an Ext D App's defining trait is a user-facing app that happens to dissolve the user/dev boundary.
Examples: Holons, NDN Workspace
Live, operated node networks providing transport, routing, privacy, or access services that other protocols and apps build on — a running service, not a specification.
Key Properties
- A live network, not a document — value comes from nodes actually running
- Designed for adversarial conditions: censorship, surveillance, traffic analysis 🛡️
- Volunteer- or incentive-run relay/routing nodes
- Shared resource consumed by many different apps, not a single-purpose product
Differs from
- P2P Protocol : A protocol specifies rules; infrastructure runs those rules as an always-on service other systems connect to.
- Decentralized Storage Network : Infrastructure moves data between endpoints without necessarily keeping it; a storage network's whole point is persistent custody.
- P2P Platform : Infrastructure provides a substrate developers may build on, but no SDKs or dev abstractions of its own.
Examples: Conduit, Tor relay nodes, Snowflake, I2P
A communication architecture where independently operated servers (instances) federate directly with each other, so users on different servers can interact with no central intermediary.
Key Properties
- Independently operated instances implement the same spec
- A server-to-server protocol, distinct from the client-to-server one
- Any conformant server can federate with any other, no permission required 🌐
- Identity is anchored to a server (with or without portability)
Differs from
- P2P Protocol : In a P2P Protocol, clients speak directly to peers. In a federated protocol, a persistent server layer speaks on the user's behalf.
- Decentralized Storage Network : A federated protocol is about communication and social interaction, not persistent storage capacity.
Examples: Activity Pub, ATProto, Matrix
A formal spec for describing, structuring, or linking data so it's interpretable across systems without a shared implementation — a meaning layer, not a communication mechanism.
Key Properties
- Defines vocabularies, ontologies, schemas, or graph models — not message formats
- Machine-readable, enabling automated interpretation or inference 🧠
- Adoptable independently of any particular implementation
- Used as a shared layer beneath multiple higher-level protocols or apps
Differs from
- P2P Protocol : A P2P Protocol defines how nodes communicate; a Semantic & Data Protocol defines what the data they exchange means. A protocol can adopt a data protocol's model without becoming one.
- Identity Protocol : Identity Protocols govern identifiers and credentials specifically; Semantic & Data Protocols govern how any data — identity included — is structured, and aren't domain-specific.
- Decentralized Application : A Semantic & Data Protocol is consumed by developers and protocol designers, not directly by end users.
Examples: Valueflows, Atomic Data, Murmurations
A formal spec for how decentralized identifiers are created and resolved, credentials issued and verified, or trust established — implementable from the document alone, like a P2P Protocol but for identity.
Key Properties
- Standards-track document — often via W3C, IETF, DIF, or ToIP 📜
- Defines identifier syntax, resolution, credential formats, or exchange flows
- Has a conformance model implementations can be tested against
- Works without a central authority controlling registration or validity
Differs from
- Identity Toolkit / Platform : A protocol defines what conformant systems must do; a toolkit is the software that does it. You read the protocol to understand the standard; you install the toolkit to implement it.
- Identity System / Design : A protocol usually emerges from a standards process; a system/design proposes a wholly new architecture that may not have a formal spec yet.
- Semantic & Data Protocol : An Identity Protocol is concerned with who parties are; a Semantic & Data Protocol is concerned with what data means, across any domain.
Examples: Iden3, FAN, FedID
Developer infrastructure that implements one or more Identity Protocols and exposes their capabilities via SDKs or APIs, so app developers don't reimplement the spec themselves.
Key Properties
- SDK/API surface for DID resolution, credential issuance, verification, authentication 🔧
- Conforms to published Identity Protocols rather than inventing new ones
- Targets application developers, not protocol researchers
- Reusable across multiple apps and deployment contexts unmodified
Differs from
- Identity Protocol : A single protocol can have multiple competing toolkit implementations — the toolkit is packaged software, the protocol is the spec it implements.
- Identity System / Design : A toolkit makes existing standards usable; its contribution isn't a novel architecture the way an Identity System's is.
- P2P Platform : Purpose-built for identity/credential/auth use cases specifically, even though it could in principle support other data types.
Examples: SpruceID, walt.id, Animo
A novel end-to-end architecture proposing a fundamentally new approach to identity — personhood, trust delegation, credential structure — rather than implementing an existing standard.
Key Properties
- The contribution is an architectural idea, not (yet) a spec or toolkit 💡
- Explicitly critiques or departs from existing identity paradigms
- May produce protocols/tooling later, as the idea matures
- Proposes mechanisms for personhood, trust, or credential lifecycle not reducible to extending existing standards
Differs from
- Identity Protocol : A protocol operates within an established paradigm and defines precise interoperability rules; a system/design questions the paradigm itself.
- Identity Toolkit / Platform : A toolkit's primary value is software developers use; a system/design's primary value is the architectural insight, which tooling may not embody yet.
Examples: IdentiKey, First Person Project, GreenCheck
A spec realized as one or more on-chain deployable contracts or registries — once deployed, the standard and its enforcement mechanism become literally the same artifact.
Key Properties
- Deployed, not just implemented — the running contract IS the standard ⛓️
- Permissionless read/write access by any conformant participant
- Usually an EIP, ERC, or equivalent spec with a reference implementation
- Shared infrastructure other apps build on, most valuable when widely adopted
Differs from
- P2P Protocol : A P2P Protocol is implemented separately by many independent parties; a Smart Contract Standard is deployed once (or as a few canonical instances) and exists thereafter as shared on-chain state.
- Decentralized Application : A standard defines shared infrastructure — registries, interfaces — that apps build on; it doesn't deliver end-user functionality itself.
- Decentralized Storage Network : A standard enforces rules and shared state; it doesn't provide distributed storage capacity for arbitrary user data.
Examples: ERC-8004
A network where distributed node operators provide persistent data storage as their primary function, sustained by incentives, volunteering, or cooperative governance.
Key Properties
- Persistent custody — data placed in it stays retrievable over time 💾
- Storage proof/audit mechanisms confirm operators actually hold the data
- A compensation or incentive model for node operators is a first-class concern
- Retrieval guarantees range from cryptoeconomic enforcement to best-effort
Differs from
- P2P Infrastructure : Infrastructure moves data between endpoints without necessarily retaining it; a storage network's defining commitment is retaining it.
- P2P Protocol : A protocol specifies how storage/retrieval should work; a storage network is the operational network actually running those specs, with live nodes and economic models.
- Decentralized Application : A storage network provides capacity consumed by other apps and protocols, not end-user functionality of its own.
Examples: Filecoin, Arweave, Storj
A formal spec for how structured data is named, addressed, replicated, and synced across a P2P network — the data layer's rules, not the transport layer's.
Key Properties
- Content-addressing or self-certifying naming scheme 🔗
- Defined sync/replication algorithm — gossip, CRDT merge, DAG propagation, etc.
- Explicit mutability semantics — append-only, versioned, CRDT-mergeable, last-writer-wins
- Independent of any specific blockchain, storage incentive, or transport
Differs from
- P2P Protocol : A P2P Protocol governs how nodes communicate and discover each other; a DD Pro governs how data is structured and reconciled once communication already exists.
- Semantic & Data Protocol : A Semantic & Data Protocol defines what data means across systems; a DD Pro defines the operational mechanics of how data moves and lives on a P2P substrate, independent of its meaning.
- Decentralized Storage Network : A DD Pro is the spec any party can implement to participate in a storage-like network; it doesn't itself run nodes or require an incentive model the way a DSN does.
- Integrated P2P Runtime : A DD Pro's spec is separable from its implementation, with interoperating independent implementations; a runtime co-designs the data model and dev environment as one inseparable whole.
Examples: IPFS, Willow, MCP
A formal spec for how value is issued, accounted, valued, and circulated among participants — the monetary logic itself, independent of whichever substrate realizes it.
Key Properties
- Substrate-independent — realizable on-chain, off-chain, agent-centric, or institutionally 💱
- Defines issuance, accumulation, settlement, and valuation rules
- Explicit federation logic where multiple instances interoperate
- Different substrates implementing the same protocol can interoperate at the monetary-logic level
Differs from
- Smart Contract Standard : A Smart Contract Standard's running contract and the standard are the same on-chain artifact; a DM Pro's monetary logic can be realized on-chain, off-chain, or institutionally, with the protocol conceptually prior to any one substrate.
- P2P Protocol : A P2P Protocol governs how nodes communicate; a DM Pro governs how value flows once communication is already established, over any P2P or federated transport.
- Decentralized Data Protocol : A DD Pro governs how data is named and reconciled; a DM Pro governs how value claims are issued, transferred, and bounded — the data layer is incidental to it, not constitutive.
- Identity Protocol : Identity protocols govern who participants are; monetary protocols govern how value moves between identified participants, typically depending on but not defining identity infrastructure.
Examples: Credit Commons Protocol, Commitment Pooling Protocol (Sarafu / Grassroots Economics), Sardex mutual credit clearing, Augmented Bonding Curve (Commons Stack), Quadratic Funding