Infraestructura de descubrimiento

1. Resumen

Encontrar, recuperar y combinar conocimiento en internet depende de forma abrumadora de un puñado de empresas, cada una con su propio índice. Esta página explora una forma distinta: una manera abierta y federada de encontrar, recuperar, superponer, enriquecer e integrar conocimiento a través de muchas fuentes operadas de forma independiente, sin que ninguna empresa sea dueña del índice. Describe cómo varias tecnologías existentes podrían encajar para lograrlo y dónde haría falta un trabajo genuinamente nuevo.

¿Por qué importa quién opera el índice? Quien opera un índice decide qué cubre, cómo se ordenan los resultados, a qué fuentes se puede llegar y en qué términos, y si el acceso continúa. Todas las personas que encuentran cosas a través de él, y toda fuente que quiere ser encontrada a través de él, dependen de esas decisiones. OpenHaven llama a este tipo de dependencia de una única entidad que controla riesgo de captura: el riesgo de que algo en lo que la gente confía pase a estar sustancialmente controlado por una sola parte, de maneras que socavan su carácter abierto o gobernado por la comunidad. Es información estructural, no un veredicto sobre ninguna empresa. La página de Riesgos de las plataformas centralizadas muestra cómo se ve el nivel más alto de ese riesgo en plataformas conocidas.

Es una capacidad de propósito general. No está ligada a ninguna comunidad, tema ni tipo de datos en particular; el objetivo es indexar y poner a disposición una amplia gama de fuentes de datos, información y sitios web. Para conocer las situaciones a las que está destinado este tipo de infraestructura, y el argumento más amplio a favor de la arquitectura descentralizada, véase Por qué una arquitectura descentralizada.

La propuesta se apoya en un directorio curado de más de 60 mapas de ecosistemas, fuentes de datos, herramientas de automatización y esquemas de categorización, compilado a través de la investigación sobre redes y mapeo de ecosistemas. El análisis de fuentes de datos evalúa los mapas y esquemas de ese directorio como fuentes candidatas, incluido cómo podría leerse cada una.

La visión descansa en cinco compromisos:

1. Las fuentes nativas se indexan automáticamente. El resultado es una caché parcial más un «mapa de mapas» federado y parcial: vías para encontrar datos relevantes, superponerlos, enriquecerlos e integrarlos, reutilizando tecnología existente siempre que sea posible.
2. El sistema es federado, con sincronización entre instancias. Una plataforma lo hace práctico, pero se apoya en protocolos. Probablemente haga falta al menos un protocolo genuinamente nuevo, porque la sincronización de entradas de índice, conocimiento en caché, procedencia de la curaduría y confianza entre instancias independientes no tiene un estándar listo para usar.
3. Las fuentes no tienen que publicar en él. Los «controladores» (drivers) por fuente leen cada fuente en su forma nativa y la interpretan. Este es el compromiso de diseño que define la propuesta (véase la sección 3).
4. Los estándares de la web semántica, AD4M y Murmurations son probablemente partes de la solución, no la solución completa. ActivityPods podría ofrecer un bloque de construcción para la capa de plataforma federada, o esa capa podría tener que construirse de otra manera.
5. La especificación final podría vivir fuera de OpenHaven. Podría ser un esfuerzo independiente que otros adopten, amplíen o custodien.

Sea cual sea el resultado de la arquitectura, el trabajo se divide en cinco etapas. Los controladores realizan las tres primeras para una sola fuente; cada instancia realiza las dos últimas y comparte los resultados con otras instancias (sección 6).

• Ingesta: extraer datos de fuentes externas mediante API, scraping, exportación manual y recolección nativa de protocolos.
• Normalización: eliminar duplicados y mapear datos heterogéneos a una forma común.
• Enriquecimiento: aplicar esquemas de categorización, inferir relaciones y etiquetar la geografía.
• Almacenamiento: conservar el conocimiento normalizado y enriquecido en la forma que cada instancia elija.
• Servicio: exponerlo mediante funciones de búsqueda, recorrido y exportación que apoyen la coordinación, el mapeo de tecnologías y la participación de la comunidad.

La sección 8 describe cómo podrían desarrollarse los controladores a lo largo de estas etapas.

2. Estado de esta página

Lea esta página como un conjunto de propuestas.

• No se ha construido ni desplegado nada de lo que aquí se describe. No existe una implementación de referencia.
• No se ha seleccionado ninguna arquitectura. La sección 5 presenta tres arquitecturas candidatas para compararlas; ninguna se recomienda por encima de las otras.
• Las dos especificaciones preliminares resumidas en la sección 7 son propuestas en borrador, no estándares, y nadie ajeno a OpenHaven las ha revisado.
• Nombrar una tecnología aquí no significa que sus autores sean socios, hayan sido consultados ni respalden nada de lo que figura en esta página. Cada descripción de abajo proviene de los materiales públicos de cada proyecto, en el tiempo verbal que corresponde a lo que ese material dice.

3. La pregunta central de diseño: ¿cómo entra el conocimiento?

Las tecnologías de este espacio difieren sobre todo en cómo entra el conocimiento en un sistema compartido. Hay tres enfoques generales:

La propuesta de esta página sigue la columna central. Nada de los antecedentes revisados más abajo ofrece como problema resuelto llegar a fuentes arbitrarias que no cooperan, y ahí está la mayor brecha. Los enfoques no se excluyen mutuamente en los márgenes: el conocimiento que se ha recolectado y normalizado también podría publicarse en otros sistemas más adelante, y un sistema de publicación en red podría tratarse a su vez como una fuente más para recolectar.¹

4. Bloques de construcción

Cada tecnología de abajo se describe por lo que ya hace y luego por lo que esta visión añadiría. Los hechos se verificaron en los materiales públicos de cada proyecto en octubre de 2026.

4.1 Murmurations

Murmurations es un protocolo en el que un participante (un «nodo») aloja un perfil estructurado sobre sí mismo en una URL de su elección, validado contra esquemas JSON compartidos, y pide que se registre en un índice de red. Luego los agregadores consultan el índice y descargan los perfiles para construir mapas y directorios. Su documentación describe el software como de código abierto bajo GPLv3.

Su propia página de hoja de ruta indica que, a diciembre de 2025, el desarrollo adicional de Murmurations está en pausa mientras los mantenedores trabajan en otros proyectos.² La documentación de arquitectura menciona la replicación basada en IPFS solo como una posible mejora futura.

Lo que añade la visión. Murmurations supone que las fuentes publican un perfil. La visión apunta a fuentes que nunca lo harán. Su patrón de índice y agregador sigue siendo una referencia útil para la capa de consulta una vez que un controlador ha convertido una fuente en una forma común.

4.2 KOI-net

KOI-net es un protocolo en borrador para referenciar y sincronizar objetos de conocimiento entre nodos. La especificación publicada está rotulada «Draft v1.0». Define:

• identificadores de recursos (RID); el identificador de un nodo está ligado a un hash de su clave pública;
• tres tipos de eventos, NEW, UPDATE y FORGET, que la especificación describe como mensajes y no como órdenes, de modo que cada nodo decide cómo responder;
• «aristas» dirigidas entre nodos, entregadas por webhook o sondeo, establecidas mediante un protocolo de propuesta y aprobación;
• roles de nodo completos y parciales; y
• claves ECDSA P-256 y envoltorios de mensajes firmados.

La especificación y una implementación de referencia en Python están publicadas bajo la organización Dynamical Systems Group en GitHub; la implementación tiene licencia MIT.

Lo que añade la visión. KOI-net especifica la sincronización entre nodos que ya tienen conocimiento. No especifica cómo una fuente externa arbitraria se convierte en un objeto de conocimiento en primer lugar; esa capa de controladores es el aporte propio de la visión. KOI-net es el candidato existente más cercano para la capa de sincronización entre instancias, y la primera especificación en borrador de la sección 7 se plantea como un posible perfil de él.

4.3 AD4M y Coasys

AD4M, desarrollado por Coasys, tiene licencia Cryptographic Autonomy License 1.0 y está en desarrollo activo. Su documentación describe:

• Languages: protocolos conectables, cada uno un pequeño fragmento de código que define cómo se almacenan, recuperan, direccionan y (para datos compartidos) sincronizan los datos. Una Language se ejecuta en un entorno aislado, se identifica por un hash de su código y da a cada dato una dirección de la forma <language-hash>://<address>. Una Language implementa solo las capacidades que necesita, como servir contenido o responder consultas. Las Languages son el análogo existente más cercano a los «controladores» de esta visión;
• Perspectives: el grafo de conocimiento propio de un agente, hecho de enlaces (origen, predicado, destino), almacenado localmente y consultable con SPARQL;
• Neighbourhoods: Perspectives compartidas entre agentes y sincronizadas por un «lenguaje de enlace» (link language). El lenguaje de enlace predeterminado sincroniza sobre Holochain con una red separada para cada Neighbourhood, y la documentación presenta lenguajes de enlace que envuelven otros sistemas (una base de datos de una empresa, una herramienta de groupware heredada o un protocolo federado como ActivityPub o Matrix) como escenarios de integración. El README también describe un lenguaje de enlace alternativo que sincroniza mediante un servidor autoalojable sobre HTTP y WebSocket; y
• Alojamiento multiusuario: un solo nodo AD4M puede servir a muchas personas, cada una con su propia identidad y datos aislados, de forma muy parecida a como un proveedor de correo aloja buzones. La documentación dice que los usuarios pueden exportar sus datos y pasarse a otro anfitrión o a su propio nodo.

La interfaz de Language (versión 1.0) está especificada en WebAssembly Interface Types junto con una especificación en prosa, de modo que existe una especificación escrita para esa capa.

Lo que añade la visión. Las Languages adaptan protocolos y sistemas de almacenamiento que ya se conocen. Los controladores de la visión deben interpretar fuentes que no cooperan, como un blog, un PDF o una wiki desactualizada, lo cual es un trabajo más difícil y más dependiente de la extracción. Adoptar AD4M también supondría seguir su implementación como fuente de verdad y no como un estándar independiente, e instalar una Language es una decisión de confianza: la documentación señala que hoy una Language puede llegar a cualquier host al que llegue el entorno de ejecución, con un acotamiento más estricto previsto.

4.4 Geo, GRC-20 e Hypergraph

GRC-20 es un estándar de grafos de conocimiento, hoy en borrador (versión 0.1.0, creada en noviembre de 2024) y publicado bajo CC0. Su unidad es un espacio, una agrupación lógica que combina un grafo de conocimiento con un proceso de gobernanza o control de acceso. Los espacios personales pueden permanecer privados o locales; los espacios públicos deben estar en la cadena y con gobernanza pública. Los datos se expresan como tripletas (entidad, atributo, valor) y relaciones, escritas mediante ediciones versionadas o importadas desde otro espacio. Geo Genesis es una herramienta relacionada del ecosistema Geo. Hypergraph es un framework en TypeScript, local-first, para construir aplicaciones sobre GRC-20; su repositorio lo rotula como vista previa para desarrolladores y no apto para producción. Su documentación describe datos guardados en espacios que pertenecen a personas o grupos y no a una aplicación, con los datos privados cifrados en el cliente y los datos públicos legibles a través de un indexador para espacios GRC-20.

Lo que añade la visión. Geo es un diseño de publicación en el sistema: los datos entran al crear o importar dentro de un espacio que alguien ya gobierna, nunca al interpretar una fuente que no coopera. No obstante, es un destino de normalización plausible (su forma de tripletas se parece a lo que emitirían los controladores), una fuente plausible para recolectar por derecho propio y un posible destino posterior para publicar resultados curados.

4.5 ActivityPods

ActivityPods combina ActivityPub (el protocolo de federación del W3C) con pods de datos Solid. Cada usuario recibe un pod con un perfil, una bandeja de entrada, una bandeja de salida y una lista de seguidores. Su página principal lo describe como un «framework to create decentralized social apps» y enumera tres aplicaciones en producción; informa de financiación de los programas NGI0 de NLnet.

Lo que añade la visión. ActivityPods es un transporte de federación para aplicaciones sociales. Sus materiales no tratan la búsqueda ni el descubrimiento en un sentido ni en otro, así que si una federación al estilo ActivityPub podría transportar datos de índice, caché o procedencia es una pregunta abierta y no algo que el proyecto haya abordado.

4.6 La pila de la web semántica

RDF, JSON-LD, SHACL y SPARQL son estándares consolidados del W3C, y Solid se construye sobre ellos. Ofrecen un modelo compartido para la forma común que emitirían los controladores (RDF serializado como JSON-LD), una manera de comprobar esa forma (SHACL) y una manera de consultar a través de muchos puntos de acceso (federación SPARQL). El riesgo aquí no son los estándares sino el costo operativo de ejecutar consultas federadas a escala.

5. Cómo podrían componerse las piezas

Las tres arquitecturas candidatas de abajo usan el mismo desglose de capas: recolección/controlador, destino de normalización, almacenamiento, índice federado (el «mapa de mapas»), enrutamiento de consultas, sincronización entre instancias y confianza y curaduría.

Candidata A: una canalización de referencia de una sola instancia

Esta candidata es una canalización de cinco capas operada por un solo operador.

Casi todo en esta candidata puede construirse con herramientas maduras. Lo que no ofrece es la capa de federación, que es precisamente la parte que ocupa a esta página. Construida tal como se especifica, daría una buena plataforma de conocimiento centralizada, no una federada.

Candidata B: centrada en nodos KOI-net

Cada instancia ejecuta un nodo KOI-net. Los controladores (trabajo nuevo) convierten fuentes externas en objetos de conocimiento direccionables, y los eventos NEW/UPDATE/FORGET llevan los cambios a través de aristas negociadas hasta los nodos suscritos. Cada nodo decide por sí mismo qué guardar en caché, qué indexar y en qué confiar.

El riesgo principal es que KOI-net sigue siendo un borrador de un grupo pequeño, de modo que adoptarlo es apostar por un protocolo que aún no está ampliamente implementado. La ventaja es que los primeros en adoptarlo podrían ayudar a darle forma.

Candidata C: centrada en AD4M

Cada instancia es un nodo AD4M, o un anfitrión multiusuario que sirve a muchas personas. Los controladores son Languages que envuelven fuentes, lo que encuentran se guarda como enlaces en Perspectives, y el índice compartido de una comunidad es un Neighbourhood sincronizado por un lenguaje de enlace.

La candidata C usaría software que existe hoy, y el alojamiento multiusuario de AD4M es un modelo que funciona para instancias operadas en nombre de otros. Los costos son que ata el diseño a la implementación de un solo proyecto y, por defecto, a Holochain; que instalar una Language es una decisión de confianza; que las Languages para fuentes que no cooperan aún tendrían que escribirse; y que no ofrece forma de enrutar una consulta entre Neighbourhoods.

No se ha seleccionado ninguna arquitectura. Ninguna de las tres se recomienda por encima de las otras. La candidata B destaca porque ya tiene un borrador de protocolo escrito para la pieza más difícil, y la candidata C porque existe hoy como software.

6. Muchas instancias independientes, una sola red

La infraestructura que describe esta página no sería un sistema propiedad de una organización y operado por ella. Un único operador que ejecutara todo el cómputo y el almacenamiento recrearía el problema descrito en el Resumen. El objetivo son muchas instancias operadas de forma independiente que se sincronizan entre sí, de modo que cualquiera pueda usar la instancia que elija y llegar, en principio, a un cuerpo de conocimiento indexado en gran medida equivalente.

Qué experimentaría quien busca

• Elegir cualquier instancia. Una persona, una organización o una aplicación consultaría la instancia en la que confíe, o la que opere su comunidad, y obtendría resultados extraídos de lo que esa instancia tiene y de lo que ha recibido de otras.
• Ver de dónde vinieron los resultados. Cada resultado llevaría su procedencia: qué fuente, qué controlador, qué instancia lo interpretó, cuándo y si una persona lo revisó (especificación A). Cuando las instancias interpretan una fuente de manera distinta, pueden mostrarse ambas interpretaciones en lugar de fusionarlas en silencio.
• Seguir funcionando cuando una instancia falla. Si una instancia se desconecta, cambia sus políticas o la opera alguien en quien una persona que busca no confía, otras instancias conservarían gran parte del mismo conocimiento, y pasarse a una de ellas no debería significar empezar de nuevo. El alojamiento multiusuario de AD4M es un análogo documentado: los anfitriones sirven a muchos usuarios, cada usuario conserva su propia identidad y sus datos, y los usuarios pueden exportar sus datos y pasarse a otro anfitrión.
• Esperar una cobertura parcial. Cada instancia guarda una caché parcial: se entera de lo que existe a través de manifiestos difundidos y obtiene los contenidos completos a demanda (especificación A). Los resultados serían amplios pero no se garantiza que estén completos, y esta página no afirma lo contrario.

Cómo podría funcionar en la práctica

• Quién podría operar instancias. Comunidades que quieren que sus propias fuentes estén indexadas, instituciones o grupos de investigación que cubran un tema, bibliotecas y archivos, anfitriones comerciales que lo ofrezcan como servicio y particulares. Distintos operadores elegirían distintos controladores y reglas de curaduría.
• Qué asume cada operador. Ejecutar controladores y mantenerlos funcionando a medida que cambian las fuentes; almacenamiento para su caché y su índice; sincronización con las instancias a las que decida conectarse; moderación y curaduría de lo que publica; y responsabilidad por lo que guarda en caché conforme a la ley de su jurisdicción (véase la pregunta abierta sobre los límites legales).
• Cómo se conectan las instancias. Cada conexión se negociaría entre dos operadores (en términos de KOI-net, una arista establecida por propuesta y aprobación), que deciden qué compartir y en quién confiar. Una instancia nueva se incorporaría conectándose a una o más existentes, y cualquier operador podría descartar localmente una instancia que se comporte mal, sin una decisión central.
• Qué sigue sin resolverse. Cómo se descubren las instancias en primer lugar (el propio índice de alojamiento de AD4M es un registro central, lo que muestra a la vez la necesidad y el riesgo); cómo llega una consulta a las instancias correctas (véase el enrutamiento de consultas en las preguntas abiertas); cómo evitar que unos pocos operadores grandes se conviertan en el nuevo centro; y quién paga el funcionamiento de las instancias.

7. Especificaciones preliminares

De este trabajo salieron dos especificaciones en borrador. Cada una es deliberadamente preliminar, está marcada como «Propuesta en borrador» y está escrita de modo que pueda pasar a su propio repositorio. Todavía no están publicadas; esta página las resume.

Especificación A: Sincronización entre instancias y procedencia. Propone que la sincronización entre instancias se defina como un perfil de KOI-net y no como un transporte nuevo, sujeto a confirmar que los borradores de KOI-net permiten nuevos tipos de objeto (una pregunta abierta). Sus ideas centrales:

• una clave de sujeto derivada solo del localizador canónico de una fuente, de modo que todas las instancias nombren la misma fuente de manera idéntica, mantenida aparte de una derivación por instancia (la interpretación que una instancia hace de esa fuente en un momento dado);
• los eventos existentes NEW/UPDATE/FORGET mapeados al ciclo de vida de la derivación, con manifiestos difundidos ampliamente y contenidos completos obtenidos a demanda, de modo que cada instancia guarde una caché parcial;
• procedencia obligatoria en cada objeto (de dónde vino, cuándo, con qué controlador y método, y si una persona lo revisó), alineada con W3C PROV-O;
• atestaciones firmadas (verificada, disputada, reemplazada) como objetos sincronizados ordinarios; y
• confianza local: la especificación define cómo se representan y verifican las señales de confianza, no en quién confiar, y las interpretaciones en conflicto de una misma fuente coexisten en lugar de fusionarse.

Especificación B: Contrato del controlador y objeto de conocimiento normalizado. Define lo que un controlador recibe y devuelve y la forma de lo que emite. Sus ideas centrales:

• RDF serializado como JSON-LD, comprobado con SHACL, como destino común, con GRC-20 y Murmurations como formatos de exportación y no como forma canónica (GRC-20 sigue siendo un borrador y el mapeo no es sin pérdidas);
• cada afirmación lleva un valor de confianza, su base y un puntero a la fuente que muestra de dónde salió;
• estados de resultado explícitos, de modo que «no se encontró nada» nunca se confunda con «no se pudo leer» o «la fuente cambió»; y
• límites firmes a la extracción asistida por modelos de lenguaje: ninguna afirmación sin un fragmento citado de la fuente, validación antes de emitir y ningún relleno silencioso de lagunas.

8. Cómo podrían desarrollarse los controladores

Un controlador lee una fuente en su forma nativa y emite objetos de conocimiento con la forma que define la especificación B. El trabajo es parecido de una fuente a otra y sigue las tres primeras etapas del Resumen: ingesta, normalización y enriquecimiento. Luego la instancia almacena y sirve el resultado. Un controlador mínimo solo necesita las dos primeras etapas; el enriquecimiento puede añadirse después.

Ingesta: leer la fuente

• Métodos de acceso. Se llega a las fuentes mediante API nativas de protocolo (como el índice de Murmurations, la API GraphQL de Hylo o la API MediaWiki de la wiki de la P2P Foundation), scrapes programados de páginas estructuradas, exportaciones públicas (como Kumu JSON), importaciones manuales o por lotes (CSV o exportaciones de bóvedas de notas) y API de datos geográficos. El análisis de fuentes de datos enumera el método de acceso de cada fuente candidata.
• Conservar el resultado en bruto. Los datos recuperados deberían caer en un área de preparación simple antes de transformar nada, de modo que una normalización fallida pueda volver a ejecutarse sin obtener de nuevo la fuente. Los estados de resultado de la especificación B mantienen «no se pudo leer» distinto de «no se encontró nada».
• Orquestación. Programar y encadenar estos pasos puede hacerse con un motor de flujos de trabajo autoalojado (por ejemplo n8n), un servicio de automatización en la nube (por ejemplo Make) o scripts propios en un programador de tareas. El equilibrio es entre esfuerzo operativo, costo por operación y flexibilidad.

Normalización: una forma común

• Destino. El controlador mapea lo que lee al objeto de conocimiento normalizado de la especificación B. Un vocabulario de entidades como persona, organización, proyecto, tecnología, marco, lugar y medio es un punto de partida viable para lo que describen los objetos.
• Resolución de entidades. La misma entidad suele aparecer con nombres distintos («Life Itself» y «Life-Itself»). Funciona bien un enfoque en dos pasadas: coincidencia difusa de cadenas (por ejemplo con RapidFuzz) para encontrar candidatas, y luego similitud de embeddings (por ejemplo con sentence-transformers) para atrapar duplicados con nombres distintos, con los casos dudosos pasando a una cola de revisión humana. Una fusión confirmada mantiene los registros de origen vinculados al registro canónico, de modo que la procedencia sobrevive. Como instancias independientes pueden resolver de manera distinta, las fusiones son locales y las interpretaciones en conflicto coexisten.
• Resolución asistida por modelos. Para pares ambiguos, se puede preguntar a un modelo de lenguaje si dos registros describen la misma entidad. Es costoso a escala y debe respetar los límites de la especificación B: ninguna afirmación sin un fragmento citado de la fuente y validación antes de emitir.

Enriquecimiento: añadir significado

• Categorización. Un esquema de categorización puede aplicarse como un trabajo de etiquetado por lotes: definir las categorías del esquema, clasificar cada entidad relevante según ellas y guardar cada etiqueta junto con el esquema que la produjo. El análisis de fuentes de datos enumera esquemas candidatos.
• Inferencia de relaciones. Además de las relaciones que declara una fuente, un controlador puede inferir coafiliación (organizaciones compartidas), proximidad temática (embeddings cercanos), coubicación geográfica y afinidad basada en esquemas (etiquetas compartidas entre esquemas). Las relaciones inferidas deben marcarse como inferidas y nunca presentarse como afirmadas por la fuente.
• Embeddings. Generar embeddings de cada registro permite la búsqueda semántica y el agrupamiento, con un servicio gestionado (por ejemplo Nomic Atlas) o con modelos locales.
• Geografía. Las entidades con ubicación pueden etiquetarse con biorregión y límites administrativos, usando una taxonomía de biorregiones como la de One Earth, geocodificación mediante OpenStreetMap Nominatim y búsquedas de punto en polígono.

Qué hace cada instancia con el resultado

• Almacenar. Cada instancia elige su almacenamiento. Un almacén de grafos se adapta a datos con muchas relaciones (ejemplos: Neo4j, SurrealDB, Apache AGE), y un almacén de vectores se encarga de la búsqueda por similitud (ejemplos: Qdrant, pgvector, Chroma). Las Perspectives de AD4M son la alternativa centrada en el agente descrita en la candidata C.
• Servir. Las funciones que una instancia expondría son descubrimiento y búsqueda de entidades; recorrido de relaciones hasta una profundidad elegida; consulta por categoría y etiqueta; similitud semántica; consultas geográficas; un flujo de cambios para entidades nuevas, actualizadas e inferidas; y exportación en formatos estándar (perfiles Murmurations, CSV, JSON-LD), de modo que lo que aprendan las instancias pueda volver a fluir hacia el ecosistema más amplio.

9. Preguntas abiertas

Estas son las preguntas que las especificaciones en borrador no pueden resolver por sí solas.

• ¿Qué contienen los «resúmenes estructurados fáciles de recorrer», con la precisión suficiente para validarlos entre instancias independientes que nunca acordaron un formato?
• ¿Cuánto mantenimiento de controladores puede automatizarse? Los controladores se rompen cuando cambian las fuentes. ¿Cuánta reparación pueden hacer con seguridad los modelos de lenguaje y dónde debe volver a revisar una persona?
• ¿La nueva capa de sincronización es un protocolo nuevo o un perfil de KOI-net? Eso depende de lo que permita el borrador de KOI-net.
• ¿Cómo funciona el enrutamiento de consultas en una red de instancias? ¿Cada nodo sondea todas las aristas suscritas, o existe un mecanismo de descubrimiento más inteligente?
• ¿Cómo se tratan los duplicados y los conflictos cuando dos controladores independientes recolectan la misma fuente de manera distinta?
• ¿Cómo se representa y se verifica la confianza entre nodos que nunca se han encontrado, sin convertirse en un concurso de popularidad ni en un blanco fácil para identidades falsas?
• ¿Cuáles son los límites legales de guardar en caché y volver a servir contenido recolectado, y de manejar datos personales en él? Difieren según la jurisdicción y aquí no se resuelven.

10. Créditos

La investigación sobre mapeo de ecosistemas de la que surgió esta propuesta fue patrocinada originalmente por el Institute of Applied Metatheory. Las comunidades de la Collaborative Technology Alliance y de DWeb aportaron ideas e investigación útiles que contribuyeron a este informe.

11. Referencias

Estándares y especificaciones

• W3C. RDF 1.1 Concepts and Abstract Syntax. w3.org/TR/rdf11-concepts
• W3C. JSON-LD 1.1. w3.org/TR/json-ld11
• W3C. Shapes Constraint Language (SHACL). w3.org/TR/shacl
• W3C. SPARQL 1.1 Query Language. w3.org/TR/sparql11-query
• W3C. PROV-O: The PROV Ontology. w3.org/TR/prov-o
• W3C. Web Annotation Data Model. w3.org/TR/annotation-model
• W3C. ActivityPub. w3.org/TR/activitypub

Proyectos y protocolos

• Murmurations. Documentation. docs.murmurations.network (arquitectura: about/architecture; hoja de ruta: about/roadmap)
• KOI-net Protocol Specification, Draft v1.0. dynamicalsystemsgroup.github.io/koi-net-spec; implementación de referencia: github.com/DynamicalSystemsGroup/koi-net
• AD4M. Coasys. Documentación: docs.ad4m.dev (Languages, Perspectives, Neighbourhoods y Multi-User Mode); código fuente: github.com/coasys/ad4m; coasys.org/adam
• GRC-20 Knowledge Graph (Draft, v0.1.0). The Graph improvement proposals. github.com/graphprotocol/graph-improvement-proposals
• Hypergraph. github.com/graphprotocol/hypergraph
• ActivityPods. activitypods.org
• Solid Project. solidproject.org

Herramientas citadas en la sección 8

• n8n (orquestación de flujos de trabajo). n8n.io
• Make (automatización de flujos de trabajo en la nube). make.com
• RapidFuzz (coincidencia difusa de cadenas). github.com/maxbachmann/RapidFuzz
• sentence-transformers (embeddings locales). sbert.net
• Nomic Atlas (embeddings y agrupamiento). atlas.nomic.ai
• One Earth. Navegador de biorregiones. oneearth.org/navigator
• OpenStreetMap Nominatim (geocodificación). nominatim.openstreetmap.org
• Neo4j. neo4j.com; SurrealDB. surrealdb.com; Apache AGE. age.apache.org
• Qdrant. qdrant.tech; pgvector. github.com/pgvector/pgvector; Chroma. trychroma.com

Footnotes

1. Un tercer modo, la federación basada en el consentimiento, es otro mecanismo de convergencia distinto: los dominios independientes siguen siendo soberanos y se conectan solo a través de puentes acordados. Se incluye en la comparación porque es un diseño distinto, no porque aquí se proponga ni se respalde ningún proyecto. Su principal límite para esta visión es que nunca llega a las fuentes que no participan. ↩

2. La página de la hoja de ruta se leyó en octubre de 2026. Si el desarrollo se reanuda, y de qué forma, es una decisión de los mantenedores. La documentación de Murmurations usa «el índice» en singular mientras que el sitio principal del proyecto habla de «índices»; por eso esta página describe el patrón (un índice más agregadores que lo consultan) sin afirmar cuántos índices independientes existen. ↩