Ubicación de Entidades de OpenHaven — Referencia de la Pila Soberana

v3 / Entidades seleccionadas ubicadas frente al Modelo de Pila Soberana de OpenHaven

Un diagrama de referencia que ubica una selección curada de entidades registradas por OpenHaven en sus capas principales del modelo de pila. El modelo de capas utilizado aquí es el Modelo de Pila Soberana de OpenHaven, desarrollado en conjunto por los grupos de trabajo de OpenHaven, la Collaborative Technology Alliance (CTA) y DWeb. Las entidades se extraen de la taxonomía de OpenHaven, con un peso mayor hacia aquellas con adopción real sustancial y atención de los desarrolladores. El color del borde del chip indica el tipo de entidad (definiciones en la tarjeta de referencia a continuación). Pase el cursor sobre cualquier chip para ver una breve descripción, atributos clave y la URL principal. Las entidades transversales — aquellas cuyo compromiso arquitectónico atraviesa múltiples capas — se marcan con una de cuatro visualizaciones transversales: ocupa, abstrae, subsume y suite. La ubicación indica la responsabilidad arquitectónica principal de cada entidad, no la única o exclusiva — muchas entidades tienen funcionalidad real en otras capas incluso cuando nada en el diagrama las marca como transversales; las bandas transversales explícitas se reservan para un puñado de casos ilustrativos (Holochain, AD4M, NextGraph, las suites), no una lista exhaustiva de cada entidad con alcance multicapa. Trate la ubicación como una ayuda arquitectónica de orientación, no como una clasificación absoluta. Este diagrama es una muestra, no un mapa exhaustivo. El panorama completo y las agrupaciones funcionales dinámicas se generarán de forma programática una vez que los datos de OpenHaven se migren a una base de datos relacional con una capa de grafo complementaria.

Ubicación de entidades

Las capas van desde L4 (Aplicación / Interfaz) en la parte superior hasta L1 (Físico / Red) en la parte inferior, siguiendo el Modelo de Pila Soberana de OpenHaven — de L3.1 a L3.6, en medio, forman la capa de Confianza Comunitaria (ver riel). Cada entidad se ubica en su capa principal; las relaciones transversales se muestran como marcadores superpuestos (ver leyenda). La selección es ilustrativa, no exhaustiva — incluye las entradas más ampliamente adoptadas de cada tipo de entidad, además de todos los miembros de las suites marcadas. Desplácese horizontalmente si las filas de entidades exceden el ancho de la ventana.

L4
Aplicación / Interfaz
BlueSkyMastodonPeerTubeMobilizonLogseqAFFiNEAnytypeNextcloudHolonsNDN WorkspaceGroup IncomeA2A
L3 Confianza Comunitaria
L3.6
Federación
ActivityPubATProtoMatrixSolidNostr (relay federation)KOI-net
L3.5
Coordinación entre Pares
HolochainAD4MNextGraphGordian ClubsVeilidDittoActivityPods
L3.4
Datos Comunitarios & Gobernanza
BonfireSemAppsTRQPOpenVTC
L3.3
Identidad & Soberanía del Usuario
XIDFANFedID
L3.2
Datos & Semántica
Gordian EnvelopeIPFSFilecoinJSON-LDMurmurationsValueflowsCeramicWillowIrohMCPERC-8004SIWEERC-4337RIDsW3C VCs
L3.1
Red de Superposición
Hubertlibp2pKitsuneTorI2PSnowflakeNostrCashuDIDCommTSP
L2
Transporte / Canal
NoiseReticulumMeshtasticTor (onion routing)I2P (garlic routing)W3C DIDs
L1
Física / Red

Borde del chip — madurez

El estilo del borde de un chip indica el nivel de madurez de la entidad. El color del borde sigue codificando el tipo de entidad (ver la tarjeta de definiciones a continuación).

Solid
Maduro — versión de producción estable con amplia adopción e implementaciones activas. Ejemplos: Mastodon, IPFS, libp2p, W3C DIDs.
Dashed
Alfa / Beta — cuenta con implementaciones funcionales pero aún no una versión de producción estable. Las especificaciones aún están evolucionando; las implementaciones son limitadas o están en adopción temprana. Ejemplos: FAN, FedID, KOI-net, Gordian Envelope.
Dotted
Solo especificación — existe una especificación o borrador, pero aún no hay implementaciones conocidas desplegadas en producción. Puede que solo exista código de referencia. Ejemplos: TSP (Implementers Draft), TRQP (Revisión Pública), ERC-8004 (ERC Draft).

Marcadores transversales

Las entidades transversales se representan como bandas que envuelven sus chips miembros. El estilo del contorno de la banda codifica el tipo de transversalidad. Cada intersección (banda, fila) puede tener un pequeño indicador — pase el cursor sobre él para ver una explicación de lo que ocurre en esa capa específica.

Ocupa Banda de tinta sólida. Un único entorno de ejecución integrado, implementado a través de múltiples capas; componentes inseparables. Ejemplos: Holochain (L3.2 + L3.5 + L4), NextGraph (L3.1 a L4).
Abstrae sobre Banda violeta discontinua. Proporciona una capa de abstracción unificada sobre sustratos intercambiables en múltiples capas. Ejemplo: AD4M.
Subsume (dentro de la banda) Un marcador de círculo cruzado colocado dentro de la banda en una fila particular indica que la entidad subsume la función tradicional de esa capa en lugar de implementarla. Ejemplo: AD4M Neighbourhoods reemplazando la federación en L3.6.
Suite Banda discontinua en el color específico de la suite. Componentes separables co-diseñados que se combinan en una solución coherente; los miembros siguen siendo reemplazables individualmente. Ejemplos: Gordian Suite (dorado), KOI (verde azulado), W3C SSI Suite (violeta), ToIP Suite (verde salvia).

Definiciones de Tipos de Entidad

Protocolo P2P
Una especificación formal que define formatos de mensajes, enrutamiento y patrones de interacción que permiten a los nodos comunicarse y coordinarse sin prescribir la implementación. Preocupaciones a nivel de transmisión; el protocolo es separable de cualquier implementación específica.
Plataforma P2P
Infraestructura reutilizable para desarrolladores, construida sobre uno o más protocolos externos, que proporciona SDKs, identidad, almacenamiento y servicios componibles que las aplicaciones consumen. La plataforma se construye sobre sus protocolos subyacentes, no se co-diseña con ellos.
Entorno de Ejecución P2P Integrado
Una tecnología en la que el modelo de datos, el protocolo de sincronización, la arquitectura de seguridad y el entorno de desarrollo de aplicaciones se co-diseñan como un único todo inseparable. El protocolo no existe de forma independiente de su entorno de ejecución.
Infraestructura P2P
Redes de nodos activas y operativas que proporcionan servicios de transporte, enrutamiento, privacidad o acceso de los que dependen otros sistemas. Se definen por ser un servicio en funcionamiento, no una especificación, y normalmente están diseñadas para condiciones adversas.
Protocolo de Datos Descentralizado
Una especificación sobre cómo se nombran, direccionan, replican y sincronizan los datos estructurados en una red P2P. Se ocupa del direccionamiento por contenido, los algoritmos de sincronización y la semántica de mutabilidad, en lugar de cómo se comunican los nodos o qué significan los datos.
Protocolo de Federación
Una arquitectura de comunicación en la que los usuarios se conectan a servidores operados de forma independiente (instancias), y esos servidores mantienen relaciones entre pares para enrutar mensajes, compartir contenido o coordinar actividades en nombre de sus usuarios.
Protocolo Semántico y de Datos
Una especificación formal para describir, estructurar o enlazar datos de modo que sean interpretables entre sistemas, aplicaciones y organizaciones sin una implementación compartida. Vocabularios, esquemas y modelos de grafos para una semántica portátil.
Protocolo de Identidad
Una especificación formal que define la creación de identificadores, la emisión de credenciales, la autenticación o el establecimiento de confianza, sin prescribir la implementación. La especificación es separable de cualquier kit de herramientas en particular.
Kit de Herramientas / Plataforma de Identidad
Infraestructura para desarrolladores que implementa uno o más Protocolos de Identidad y expone sus capacidades a través de SDKs, API o frameworks. Software funcional para creadores, en lugar de un documento de especificación.
Sistema / Diseño de Identidad
Una arquitectura novedosa que propone un enfoque fundamentalmente nuevo para la identidad, la confianza o la personalidad, articulada como un documento técnico o nota de investigación. La contribución principal es la perspectiva arquitectónica, no el software funcional.
Aplicación Descentralizada
Un producto de software para el usuario final que realiza tareas específicas y acotadas utilizando protocolos descentralizados, con un límite claro entre usar la aplicación y construir sobre ella. Los usuarios consumen la funcionalidad de la aplicación.
Aplicación Descentralizada Extensible
Una aplicación descentralizada en la que el límite entre usar y construir se disuelve por diseño. La composabilidad y la extensión son intrínsecas; los usuarios ensamblan nueva funcionalidad dentro de la propia interfaz de la aplicación.
Estándar de Contrato Inteligente
Una especificación formal cuya realización principal es uno o más contratos implementables en cadena. El contrato desplegado no es una implementación del estándar, sino el estándar mismo, instanciado como estado compartido en cadena.
Red de Almacenamiento Descentralizada
Una red en la que operadores de nodos distribuidos proporcionan capacidad de almacenamiento de datos persistente a los usuarios, sostenida mediante incentivos criptoeconómicos, contribución voluntaria o gobernanza cooperativa. Se define por la custodia persistente como servicio central.
Spanning

Cuatro tipos de entidades que abarcan múltiples capas

OpenHaven reconoce cuatro formas arquitectónicamente distintas en que una entidad puede abarcar múltiples capas de la Pila Soberana. Cada entidad transversal se representa como una banda que envuelve sus chips miembros y atraviesa las filas que abarca; el estilo del contorno de la banda identifica de qué tipo de transversalidad se trata.

  • Ocupa — la entidad es un único entorno de ejecución integrado cuyos componentes en cada capa son inseparables entre sí (Holochain en L3.2 + L3.5 + L4; NextGraph abarcando de L3.1 a L4).
  • Abstrae sobre — la entidad proporciona una capa de abstracción unificada sobre sustratos intercambiables, permitiendo que las implementaciones específicas de cada capa subyacente se reemplacen sin cambiar la abstracción (AD4M).
  • Subsume — aparece como un marcador dentro de otra banda en una fila específica, indicando que la entidad reemplaza la función tradicional de esa capa con un mecanismo diferente. Los Neighbourhoods de AD4M, por ejemplo, reemplazan la federación en lugar de implementarla.
  • Suite — una familia de componentes separables co-diseñados, cada uno en su propia capa, diseñados en conjunto para componer una solución coherente mientras permanecen reemplazables individualmente (Gordian Suite, KOI, W3C SSI Suite, ToIP Suite, Protocol Labs Suite).

Cada intersección (banda, fila) puede tener un indicador , que muestra información contextual específica de la intersección al pasar el cursor — útil para casos como la relación de AD4M con la federación, donde el compromiso arquitectónico en esa capa específica necesita explicación. La gramática unificada de bandas permite que los cuatro tipos de transversalidad compartan una única lógica visual.

Pathways

Vías de adopción y agrupaciones funcionales

Las entidades en OpenHaven suelen adoptarse a través de agrupaciones funcionales, en lugar de como componentes aislados. Las agrupaciones que han surgido en la práctica actual del ecosistema incluyen:

  • SSI / confianza digital — DID, VC, DIDComm en las capas inferiores, con TSP y TRQP como protocolos transversales.
  • Fediverso social — aplicaciones basadas en ActivityPub (Mastodon, PeerTube, Mobilizon, Bonfire) y protocolos adyacentes.
  • Coordinación cívica y financiación colectiva — Murmurations, Valueflows, Bonfire, Holons, y la infraestructura emergente de organización del conocimiento como KOI.
  • Economía de agentes — MCP, A2A, x402, ERC-8004; una agrupación joven que se forma en torno al momento de la IA agéntica.
  • Autocustodia y datos personales — las herramientas de la Gordian Suite para la autosoberanía criptográfica.
  • Almacenamiento descentralizado y entrega de contenido — la Protocol Labs Suite (libp2p, IPFS, Filecoin) para datos direccionados por contenido y almacenamiento descentralizado persistente.

Estas agrupaciones no son mutuamente excluyentes — una sola implementación suele componerse a través de varias vías (SSI más Fediverso, o coordinación cívica más autocustodia). Las agrupaciones funcionales serán más legibles en diagramas dinámicos una vez que los datos de OpenHaven se migren a una capa consultable como grafo; esta referencia estática no intenta representarlas.

Gaps

Brechas de cobertura que revela el diagrama

Al examinar el diagrama surgen algunos puntos donde la cobertura de entidades o la taxonomía de OpenHaven podría crecer.

  • Las bibliotecas de soporte son invisibles — los motores CRDT, las primitivas criptográficas y las bibliotecas de serialización (Loro, Yjs, Automerge, implementaciones de BLAKE3, libsodium) se ejecutan dentro del proceso de las entidades que OpenHaven clasifica actualmente, pero no tienen un tipo de entidad propio. Si conviene agregar un tipo de Componente de Subcapa o Motor de Sincronización es una pregunta abierta, aplazada hasta después de la migración de la base de datos.
  • La agrupación de la economía de agentes encaja de forma incómoda en P2P Pro — MCP, A2A y x402 son especificaciones cliente-servidor en lugar de peer-to-peer en el sentido arquitectónico. Su inclusión sigue el precedente establecido por especificaciones abiertas adyacentes con múltiples implementadores, pero el encaje es estructural, no ideal.
  • L2 Transporte / Canal está escasamente poblado en relación con la creciente importancia de la capa. QUIC, WebRTC, WebSockets y los protocolos de canal cifrado más allá de Noise son relevantes para la soberanía, pero aún no se rastrean individualmente.

Estas observaciones son conservadoras — identifican brechas de las que los colaboradores de OpenHaven ya son conscientes, en lugar de hacer afirmaciones sobre la escala de implementación o el tamaño de la comunidad que requerirían verificación independiente.

DID Ecosystem

Por qué "W3C DIDs" no es una sola capa

Los identificadores descentralizados a menudo se presentan como una sola tecnología, pero el ecosistema DID en realidad abarca varias capas de la Pila Soberana, cada una con una responsabilidad arquitectónica distinta.

  • DID Core — L2. El chip W3C DIDs (fila L2) se ubica ahí porque DID Core proporciona principalmente identificadores descentralizados, sintaxis DID, Documentos DID y resolución de identificadores — infraestructura fundacional de nomenclatura y resolución. DID Core en sí no define la soberanía del usuario, las relaciones de confianza, las carteras, el intercambio de credenciales, la gobernanza ni los mecanismos de recuperación; esos son compromisos arquitectónicos separados que se superponen.
  • DIDComm — L3.1. DIDComm pertenece principalmente a L3.1 porque establece relaciones seguras entre pares y canales de comunicación entre partes identificadas por DID, no los identificadores ni la identidad en sí.
  • Credenciales Verificables — L3.2. Las VC del W3C y los modelos de datos semánticos relacionados pertenecen principalmente a L3.2 porque definen representaciones interoperables de afirmaciones y pruebas — una cuestión de datos y semántica, distinta de la identidad o el transporte.
  • Carteras y agentes de identidad — L3.3. La gestión de claves, la recuperación, la delegación, los marcos de confianza y la identidad controlada por el usuario pertenecen principalmente a L3.3. Ningún chip dedicado representa esta clase de herramientas en la selección actual de entidades del diagrama.
  • Los métodos DID varían en su alcance de capa. Los métodos ligeros como did:key o did:web funcionan en gran medida como mecanismos de identificación y permanecen cerca de L2. Los ecosistemas DID más sofisticados — métodos respaldados por un libro mayor con gestión de ciclo de vida, delegación o recuperación incorporadas — asumen cada vez más responsabilidades de identidad de capa superior que se acercan a L3.3.

La lección general: clasifique una tecnología relacionada con DID según la responsabilidad arquitectónica específica que proporciona — resolución de identificadores, mensajería segura, semántica de credenciales o soberanía de identidad — en lugar de tratar a "W3C DIDs", o a los "DID" en general, como una única tecnología monolítica que vive en una sola capa.