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.
Uma especificação formal de como os nós se comunicam, roteiam e se coordenam em um sistema distribuído — implementável por qualquer pessoa apenas a partir do documento, independentemente de qualquer kit de ferramentas ou ambiente de execução específico.
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
- Plataforma P2P : 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.
- Ambiente de Execução P2P Integrado : 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.
- Infraestrutura P2P : A protocol is a set of rules; infrastructure is the live, operated network of nodes actually running those rules.
- Protocolo de Dados Descentralizado : 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.
Exemplos: Nostr, Meshtastic, Noise Protocol Framework
Infraestrutura para desenvolvedores — SDKs, ferramentas e serviços de execução — para construir aplicativos descentralizados sobre um ou mais protocolos externos que a própria plataforma não 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
- Protocolo P2P : A protocol is something you implement from scratch; a platform is something you build on top of.
- Ambiente de Execução P2P Integrado : 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.
- Aplicativo Descentralizado : A platform's primary artifact is developer infrastructure; applications are built on it, not the platform itself.
Exemplos: Ditto, Trunk, SemApps
Uma tecnologia em que o modelo de dados, o protocolo de sincronização, a arquitetura de segurança e o ambiente de desenvolvimento são projetados em conjunto como um todo inseparável — você não usa o protocolo, você constrói dentro do ambiente de execução.
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
- Protocolo P2P : A P2P Protocol's implementations are separable and interoperate freely; a runtime's toolkit is a constitutive part of what the protocol even is.
- Plataforma P2P : 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.
- Aplicativo Descentralizado : A runtime is developer infrastructure — an environment apps are built within — not an end-user product itself.
Exemplos: NextGraph, Holochain, ADAM
Um produto de software para o usuário final com um limite definido entre o aplicativo e os usuários — as pessoas consomem sua funcionalidade, não a estendem nem a reprogramam.
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
- Aplicativo Descentralizado Extensível : A D App keeps a real boundary between using it and building on it; an Ext D App dissolves that boundary by design.
- Plataforma P2P : A platform's primary artifact is infrastructure for other developers; a D App's primary artifact is the end-user product itself.
- Ambiente de Execução P2P Integrado : A D App is built on top of an external protocol or platform; it isn't inseparable from one the way a runtime is.
Exemplos: AFFiNE, Logseq, Appflowy
Um aplicativo descentralizado em que usá-lo e construir sobre ele são o mesmo ato — extensão e composição são intrínsecas à arquitetura, não um sistema de plugins acrescentado depois.
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
- Aplicativo Descentralizado : A D App has an intentional boundary between user and developer; an Ext D App treats that boundary as a design flaw to eliminate.
- Plataforma P2P : 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.
- Ambiente de Execução P2P Integrado : 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.
Exemplos: Holons, NDN Workspace
Redes de nós ativas e operadas que fornecem serviços de transporte, roteamento, privacidade ou acesso sobre os quais outros protocolos e aplicativos são construídos — um serviço em funcionamento, não uma especificação.
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
- Protocolo P2P : A protocol specifies rules; infrastructure runs those rules as an always-on service other systems connect to.
- Rede de Armazenamento Descentralizada : Infrastructure moves data between endpoints without necessarily keeping it; a storage network's whole point is persistent custody.
- Plataforma P2P : Infrastructure provides a substrate developers may build on, but no SDKs or dev abstractions of its own.
Exemplos: Conduit, Tor relay nodes, Snowflake, I2P
Uma arquitetura de comunicação em que servidores operados de forma independente (instâncias) se federam diretamente entre si, de modo que usuários em servidores diferentes possam interagir sem um intermediário central.
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
- Protocolo P2P : In a P2P Protocol, clients speak directly to peers. In a federated protocol, a persistent server layer speaks on the user's behalf.
- Rede de Armazenamento Descentralizada : A federated protocol is about communication and social interaction, not persistent storage capacity.
Exemplos: Activity Pub, ATProto, Matrix
Uma especificação formal para descrever, estruturar ou vincular dados de modo que sejam interpretáveis entre sistemas sem uma implementação compartilhada — uma camada de significado, não um mecanismo de comunicação.
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
- Protocolo P2P : 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.
- Protocolo de Identidade : Identity Protocols govern identifiers and credentials specifically; Semantic & Data Protocols govern how any data — identity included — is structured, and aren't domain-specific.
- Aplicativo Descentralizado : A Semantic & Data Protocol is consumed by developers and protocol designers, not directly by end users.
Exemplos: Valueflows, Atomic Data, Murmurations
Uma especificação formal sobre como identificadores descentralizados são criados e resolvidos, credenciais são emitidas e verificadas, ou a confiança é estabelecida — implementável apenas a partir do documento, como um Protocolo P2P, mas para identidade.
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
- Kit de Ferramentas / Plataforma de Identidade : 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.
- Sistema / Design de Identidade : A protocol usually emerges from a standards process; a system/design proposes a wholly new architecture that may not have a formal spec yet.
- Protocolo Semântico e de Dados : An Identity Protocol is concerned with who parties are; a Semantic & Data Protocol is concerned with what data means, across any domain.
Exemplos: Iden3, FAN, FedID
Infraestrutura para desenvolvedores que implementa um ou mais Protocolos de Identidade e expõe suas capacidades por meio de SDKs ou APIs, de modo que os desenvolvedores de aplicativos não precisem reimplementar a especificação por conta própria.
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
- Protocolo de Identidade : A single protocol can have multiple competing toolkit implementations — the toolkit is packaged software, the protocol is the spec it implements.
- Sistema / Design de Identidade : A toolkit makes existing standards usable; its contribution isn't a novel architecture the way an Identity System's is.
- Plataforma P2P : Purpose-built for identity/credential/auth use cases specifically, even though it could in principle support other data types.
Exemplos: SpruceID, walt.id, Animo
Uma arquitetura inédita de ponta a ponta que propõe uma abordagem fundamentalmente nova para a identidade — personalidade, delegação de confiança, estrutura de credenciais — em vez de implementar um padrão existente.
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
- Protocolo de Identidade : A protocol operates within an established paradigm and defines precise interoperability rules; a system/design questions the paradigm itself.
- Kit de Ferramentas / Plataforma de Identidade : 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.
Exemplos: IdentiKey, First Person Project, GreenCheck
Uma especificação realizada como um ou mais contratos ou registros implantáveis on-chain — uma vez implantado, o padrão e seu mecanismo de aplicação se tornam literalmente o mesmo artefato.
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
- Protocolo P2P : 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.
- Aplicativo Descentralizado : A standard defines shared infrastructure — registries, interfaces — that apps build on; it doesn't deliver end-user functionality itself.
- Rede de Armazenamento Descentralizada : A standard enforces rules and shared state; it doesn't provide distributed storage capacity for arbitrary user data.
Exemplos: ERC-8004
Uma rede em que operadores de nós distribuídos fornecem armazenamento persistente de dados como sua função principal, sustentada por incentivos, voluntariado ou governança cooperativa.
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
- Infraestrutura P2P : Infrastructure moves data between endpoints without necessarily retaining it; a storage network's defining commitment is retaining it.
- Protocolo P2P : 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.
- Aplicativo Descentralizado : A storage network provides capacity consumed by other apps and protocols, not end-user functionality of its own.
Exemplos: Filecoin, Arweave, Storj
Uma especificação formal sobre como dados estruturados são nomeados, endereçados, replicados e sincronizados em uma rede P2P — as regras da camada de dados, não as da camada de transporte.
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
- Protocolo P2P : 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.
- Protocolo Semântico e de Dados : 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.
- Rede de Armazenamento Descentralizada : 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.
- Ambiente de Execução P2P Integrado : 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.
Exemplos: IPFS, Willow, MCP
Uma especificação formal sobre como o valor é emitido, contabilizado, avaliado e colocado em circulação entre os participantes — a própria lógica monetária, independentemente do substrato que a realiza.
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
- Padrão de Contrato Inteligente : 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.
- Protocolo P2P : 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.
- Protocolo de Dados Descentralizado : 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.
- Protocolo de Identidade : Identity protocols govern who participants are; monetary protocols govern how value moves between identified participants, typically depending on but not defining identity infrastructure.
Exemplos: Credit Commons Protocol, Commitment Pooling Protocol (Sarafu / Grassroots Economics), Sardex mutual credit clearing, Augmented Bonding Curve (Commons Stack), Quadratic Funding