Infraestrutura de descoberta

1. Visão geral

Encontrar, recuperar e combinar conhecimento na internet depende, de forma esmagadora, de um punhado de empresas, cada uma com o seu próprio índice. Esta página explora uma forma diferente: um modo aberto e federado de encontrar, recuperar, sobrepor, enriquecer e integrar conhecimento em muitas fontes operadas de forma independente, sem que nenhuma empresa seja dona do índice. Ela descreve como várias tecnologias existentes poderiam se encaixar nessa direção e onde seria preciso um trabalho genuinamente novo.

Por que importa quem opera o índice? Quem opera um índice decide o que ele cobre, como os resultados são ordenados, quais fontes podem ser alcançadas e em que termos, e se o acesso continua. Todas as pessoas que encontram coisas por meio dele, e toda fonte que quer ser encontrada por meio dele, dependem dessas decisões. A OpenHaven chama esse tipo de dependência de uma única entidade controladora de risco de captura: o risco de que algo em que as pessoas confiam passe a ser substancialmente controlado por uma só parte, de maneiras que prejudicam seu caráter aberto ou governado pela comunidade. É informação estrutural, não um veredito sobre nenhuma empresa. A página de Riscos das plataformas centralizadas mostra como é o nível mais alto desse risco em plataformas conhecidas.

Esta é uma capacidade de propósito geral. Não está ligada a nenhuma comunidade, área temática ou tipo de dado em particular; o objetivo é indexar e disponibilizar uma ampla gama de fontes de dados, informações e sites. Para as situações a que esse tipo de infraestrutura se destina, e o argumento mais amplo a favor da arquitetura descentralizada, veja Por que uma arquitetura descentralizada.

A proposta se apoia em um diretório curado com mais de 60 mapas de ecossistemas, fontes de dados, ferramentas de automação e esquemas de categorização, compilado por meio de pesquisa sobre redes e mapeamento de ecossistemas. A análise de fontes de dados avalia os mapas e esquemas desse diretório como fontes candidatas, inclusive como cada uma poderia ser lida.

A visão se apoia em cinco compromissos:

1. As fontes nativas são indexadas automaticamente. O resultado é um cache parcial mais um «mapa de mapas» federado e parcial: caminhos para encontrar dados relevantes, sobrepô-los, enriquecê-los e integrá-los, reutilizando tecnologia existente sempre que possível.
2. O sistema é federado, com sincronização entre instâncias. Uma plataforma torna isso prático, mas ele se apoia em protocolos. Provavelmente é preciso pelo menos um protocolo genuinamente novo, porque a sincronização de entradas de índice, conhecimento em cache, proveniência da curadoria e confiança entre instâncias independentes não tem um padrão pronto para uso.
3. As fontes não precisam publicar nele. «Drivers» por fonte leem cada fonte em sua forma nativa e a interpretam. Este é o compromisso de design que define a proposta (veja a seção 3).
4. Os padrões da web semântica, o AD4M e o Murmurations são provavelmente partes da solução, não a solução inteira. O ActivityPods pode oferecer um bloco de construção para a camada de plataforma federada, ou essa camada pode precisar ser construída de outra forma.
5. A especificação final pode viver fora da OpenHaven. Pode ser um esforço independente que outros adotem, ampliem ou custodiem.

Seja qual for o resultado da arquitetura, o trabalho se divide em cinco etapas. Os drivers realizam as três primeiras para uma única fonte; cada instância realiza as duas últimas e compartilha os resultados com outras instâncias (seção 6).

• Ingestão: puxar dados de fontes externas por meio de APIs, scraping, exportação manual e coleta nativa de protocolos.
• Normalização: eliminar duplicatas e mapear dados heterogêneos para uma forma comum.
• Enriquecimento: aplicar esquemas de categorização, inferir relações e etiquetar a geografia.
• Armazenamento: guardar o conhecimento normalizado e enriquecido na forma que cada instância escolher.
• Serviço: expô-lo por meio de funções de busca, percurso e exportação que apoiem a coordenação, o mapeamento de tecnologias e o engajamento da comunidade.

A seção 8 descreve como os drivers poderiam ser desenvolvidos ao longo dessas etapas.

2. Situação desta página

Leia esta página como um conjunto de propostas.

• Nada do que é descrito aqui foi construído ou implantado. Não existe uma implementação de referência.
• Nenhuma arquitetura foi selecionada. A seção 5 apresenta três arquiteturas candidatas para comparação; nenhuma é recomendada em relação às outras.
• As duas especificações preliminares resumidas na seção 7 são propostas em rascunho, não padrões, e não foram revisadas por ninguém de fora da OpenHaven.
• Citar uma tecnologia aqui não significa que seus autores sejam parceiros, tenham sido consultados ou endossem algo desta página. Cada descrição abaixo vem dos materiais públicos de cada projeto, no tempo verbal que corresponde ao que esse material diz.

3. A questão central de design: como o conhecimento entra?

As tecnologias desse espaço diferem sobretudo em como o conhecimento entra em um sistema compartilhado. Há três abordagens gerais:

A proposta desta página segue a coluna do meio. Nada nos antecedentes revisados abaixo oferece como problema resolvido alcançar fontes arbitrárias que não cooperam, e é aí que está a maior lacuna. As abordagens não são mutuamente exclusivas nas margens: o conhecimento que foi coletado e normalizado também poderia ser publicado em outros sistemas adiante, e um sistema de publicação em rede poderia, ele próprio, ser tratado como mais uma fonte a coletar.¹

4. Blocos de construção

Cada tecnologia abaixo é descrita pelo que já faz e depois pelo que esta visão acrescentaria. Os fatos foram verificados nos materiais públicos de cada projeto em outubro de 2026.

4.1 Murmurations

O Murmurations é um protocolo em que um participante (um «nó») hospeda um perfil estruturado sobre si mesmo em uma URL de sua escolha, validado contra esquemas JSON compartilhados, e pede que ele seja registrado em um índice de rede. Em seguida, os agregadores consultam o índice e baixam os perfis para construir mapas e diretórios. Sua documentação descreve o software como de código aberto sob a GPLv3.

Sua própria página de roadmap afirma que, em dezembro de 2025, o desenvolvimento adicional do Murmurations está pausado enquanto os mantenedores trabalham em outros projetos.² A documentação de arquitetura menciona a replicação baseada em IPFS apenas como uma possível melhoria futura.

O que a visão acrescenta. O Murmurations pressupõe que as fontes publicam um perfil. A visão mira fontes que nunca o farão. Seu padrão de índice e agregador continua sendo uma referência útil para a camada de consulta depois que um driver transformou uma fonte em uma forma comum.

4.2 KOI-net

O KOI-net é um protocolo em rascunho para referenciar e sincronizar objetos de conhecimento entre nós. A especificação publicada está rotulada «Draft v1.0». Ela define:

• identificadores de recursos (RIDs); o identificador de um nó está vinculado a um hash de sua chave pública;
• três tipos de evento, NEW, UPDATE e FORGET, que a especificação descreve como mensagens e não como comandos, de modo que cada nó decide como responder;
• «arestas» direcionadas entre nós, entregues por webhook ou polling, estabelecidas por meio de um protocolo de proposta e aprovação;
• papéis de nó completos e parciais; e
• chaves ECDSA P-256 e envelopes de mensagem assinados.

A especificação e uma implementação de referência em Python são publicadas sob a organização Dynamical Systems Group no GitHub; a implementação tem licença MIT.

O que a visão acrescenta. O KOI-net especifica a sincronização entre nós que já possuem conhecimento. Ele não especifica como uma fonte externa arbitrária se torna um objeto de conhecimento em primeiro lugar; essa camada de drivers é a contribuição própria da visão. O KOI-net é o candidato existente mais próximo para a camada de sincronização entre instâncias, e a primeira especificação em rascunho da seção 7 é concebida como um possível perfil dele.

4.3 AD4M e Coasys

O AD4M, desenvolvido pela Coasys, tem licença Cryptographic Autonomy License 1.0 e está em desenvolvimento ativo. Sua documentação descreve:

• Languages: protocolos plugáveis, cada um um pequeno trecho de código que define como os dados são armazenados, recuperados, endereçados e (para dados compartilhados) sincronizados. Uma Language roda em um ambiente isolado, é identificada por um hash de seu código e dá a cada dado um endereço no formato <language-hash>://<address>. Uma Language implementa apenas as capacidades de que precisa, como servir conteúdo ou responder a consultas. As Languages são o análogo existente mais próximo dos «drivers» desta visão;
• Perspectives: o grafo de conhecimento próprio de um agente, feito de links (origem, predicado, destino), armazenado localmente e consultável com SPARQL;
• Neighbourhoods: Perspectives compartilhadas entre agentes e sincronizadas por uma «linguagem de link» (link language). A linguagem de link padrão sincroniza sobre o Holochain, com uma rede separada para cada Neighbourhood, e a documentação apresenta linguagens de link que envolvem outros sistemas (um banco de dados de empresa, uma ferramenta de groupware legada ou um protocolo federado como ActivityPub ou Matrix) como cenários de integração. O README também descreve uma linguagem de link alternativa que sincroniza por meio de um servidor auto-hospedável sobre HTTP e WebSocket; e
• Hospedagem multiusuário: um único nó AD4M pode atender muitas pessoas, cada uma com a sua própria identidade e dados isolados, de modo muito parecido com um provedor de e-mail que hospeda caixas de correio. A documentação diz que os usuários podem exportar seus dados e mudar para outro host ou para o seu próprio nó.

A interface de Language (versão 1.0) é especificada em WebAssembly Interface Types junto com uma especificação em prosa, de modo que existe uma especificação escrita para essa camada.

O que a visão acrescenta. As Languages adaptam protocolos e sistemas de armazenamento que já são conhecidos. Os drivers da visão precisam interpretar fontes que não cooperam, como um blog, um PDF ou uma wiki desatualizada, o que é um trabalho mais difícil e mais dependente de extração. Adotar o AD4M também significaria seguir a implementação dele como fonte da verdade e não como um padrão independente, e instalar uma Language é uma decisão de confiança: a documentação observa que hoje uma Language pode alcançar qualquer host que o runtime alcance, com um escopo mais restrito previsto.

4.4 Geo, GRC-20 e Hypergraph

O GRC-20 é um padrão de grafo de conhecimento, hoje em rascunho (versão 0.1.0, criada em novembro de 2024) e liberado sob CC0. Sua unidade é um espaço, um agrupamento lógico que combina um grafo de conhecimento com um processo de governança ou controle de acesso. Os espaços pessoais podem permanecer privados ou locais; os espaços públicos devem estar na cadeia e ter governança pública. Os dados são expressos como triplas (entidade, atributo, valor) e relações, escritas por meio de edições versionadas ou importadas de outro espaço. O Geo Genesis é uma ferramenta relacionada do ecossistema Geo. O Hypergraph é um framework em TypeScript, local-first, para construir aplicações sobre o GRC-20; seu repositório o rotula como prévia para desenvolvedores e não destinado à produção. Sua documentação descreve dados mantidos em espaços pertencentes a pessoas ou grupos e não a uma aplicação, com os dados privados criptografados no cliente e os dados públicos legíveis por meio de um indexador para espaços GRC-20.

O que a visão acrescenta. O Geo é um design de publicação no sistema: os dados entram ao serem criados ou importados dentro de um espaço que alguém já governa, nunca por meio da interpretação de uma fonte que não coopera. Ainda assim, é um alvo de normalização plausível (sua forma de triplas se parece com o que os drivers emitiriam), uma fonte plausível a coletar por direito próprio e um possível destino posterior para publicar resultados curados.

4.5 ActivityPods

O ActivityPods combina o ActivityPub (o protocolo de federação do W3C) com pods de dados Solid. Cada usuário recebe um pod com perfil, caixa de entrada, caixa de saída e lista de seguidores. Sua página inicial o descreve como um «framework to create decentralized social apps» e lista três aplicações em produção; informa financiamento dos programas NGI0 da NLnet.

O que a visão acrescenta. O ActivityPods é um transporte de federação para aplicações sociais. Seus materiais não tratam de busca ou descoberta, em um sentido nem no outro, de modo que saber se uma federação no estilo ActivityPub poderia transportar dados de índice, cache ou proveniência é uma pergunta em aberto e não algo que o projeto tenha abordado.

4.6 A pilha da web semântica

RDF, JSON-LD, SHACL e SPARQL são padrões consolidados do W3C, e o Solid se constrói sobre eles. Oferecem um modelo compartilhado para a forma comum que os drivers emitiriam (RDF serializado como JSON-LD), uma maneira de verificar essa forma (SHACL) e uma maneira de consultar por muitos endpoints (federação SPARQL). O risco aqui não são os padrões, mas o custo operacional de executar consultas federadas em escala.

5. Como as peças poderiam se compor

As três arquiteturas candidatas abaixo usam a mesma divisão em camadas: coleta/driver, alvo de normalização, armazenamento, índice federado (o «mapa de mapas»), roteamento de consultas, sincronização entre instâncias e confiança e curadoria.

Candidata A: um pipeline de referência de instância única

Esta candidata é um pipeline de cinco camadas operado por um único operador.

Quase tudo nesta candidata pode ser construído com ferramentas maduras. O que ela não oferece é a camada de federação, que é exatamente a parte de que esta página trata. Construída como especificada, daria uma boa plataforma de conhecimento centralizada, não uma federada.

Candidata B: centrada em nós KOI-net

Cada instância executa um nó KOI-net. Os drivers (trabalho novo) transformam fontes externas em objetos de conhecimento endereçáveis, e os eventos NEW/UPDATE/FORGET levam as mudanças por arestas negociadas até os nós inscritos. Cada nó decide por si o que guardar em cache, o que indexar e em que confiar.

O principal risco é que o KOI-net ainda é um rascunho de um grupo pequeno, de modo que adotá-lo é apostar em um protocolo que ainda não é amplamente implementado. A vantagem é que os primeiros a adotá-lo poderiam ajudar a moldá-lo.

Candidata C: centrada no AD4M

Cada instância é um nó AD4M, ou um host multiusuário que atende muitas pessoas. Os drivers são Languages que envolvem fontes, o que elas encontram é mantido como links em Perspectives, e o índice compartilhado de uma comunidade é um Neighbourhood sincronizado por uma linguagem de link.

A candidata C usaria software que existe hoje, e a hospedagem multiusuário do AD4M é um modelo funcional para instâncias operadas em nome de outros. Os custos são que ela prende o design à implementação de um único projeto e, por padrão, ao Holochain; que instalar uma Language é uma decisão de confiança; que as Languages para fontes que não cooperam ainda teriam de ser escritas; e que ela não oferece nenhum modo de rotear uma consulta entre Neighbourhoods.

Nenhuma arquitetura foi selecionada. Nenhuma das três é recomendada em relação às outras. A candidata B se destaca porque já tem um rascunho de protocolo escrito para a peça mais difícil, e a candidata C porque existe hoje como software.

6. Muitas instâncias independentes, uma só rede

A infraestrutura que esta página descreve não seria um sistema de propriedade e operação de uma única organização. Um único operador executando toda a computação e o armazenamento recriaria o problema descrito na Visão geral. O objetivo são muitas instâncias operadas de forma independente que se sincronizam entre si, de modo que qualquer pessoa possa usar a instância que escolher e alcançar, em princípio, um corpo de conhecimento indexado em grande parte equivalente.

O que quem busca experimentaria

• Escolher qualquer instância. Uma pessoa, uma organização ou uma aplicação consultaria a instância em que confia, ou a que sua comunidade opera, e obteria resultados tirados do que essa instância mantém e do que recebeu de outras.
• Ver de onde vieram os resultados. Cada resultado traria sua proveniência: qual fonte, qual driver, qual instância o interpretou, quando e se uma pessoa o revisou (especificação A). Quando as instâncias interpretam uma fonte de maneira diferente, as duas interpretações podem ser mostradas em vez de fundidas em silêncio.
• Continuar funcionando quando uma instância falha. Se uma instância sai do ar, muda suas políticas ou é operada por alguém em quem a pessoa que busca não confia, outras instâncias manteriam boa parte do mesmo conhecimento, e passar para uma delas não deveria significar começar do zero. A hospedagem multiusuário do AD4M é um análogo documentado: os hosts atendem muitos usuários, cada usuário mantém a sua identidade e os seus dados, e os usuários podem exportar seus dados e mudar para outro host.
• Esperar cobertura parcial. Cada instância mantém um cache parcial: ela fica sabendo do que existe por meio de manifestos difundidos e busca os conteúdos completos sob demanda (especificação A). Os resultados seriam amplos, mas não há garantia de que sejam completos, e esta página não afirma o contrário.

Como poderia funcionar na prática

• Quem poderia operar instâncias. Comunidades que querem suas próprias fontes indexadas, instituições ou grupos de pesquisa que cubram um assunto, bibliotecas e arquivos, hosts comerciais que ofereçam isso como serviço e indivíduos. Operadores diferentes escolheriam drivers e regras de curadoria diferentes.
• O que cada operador assume. Executar drivers e mantê-los funcionando à medida que as fontes mudam; armazenamento para seu cache e seu índice; sincronização com as instâncias às quais decidir se conectar; moderação e curadoria do que publica; e responsabilidade pelo que guarda em cache conforme a lei de sua jurisdição (veja a pergunta em aberto sobre limites legais).
• Como as instâncias se conectam. Cada conexão seria negociada entre dois operadores (em termos de KOI-net, uma aresta estabelecida por proposta e aprovação), que decidem o que compartilhar e em quem confiar. Uma nova instância entraria conectando-se a uma ou mais existentes, e qualquer operador poderia descartar localmente uma instância que se comporte mal, sem uma decisão central.
• O que continua sem solução. Como as instâncias são descobertas em primeiro lugar (o próprio índice de hospedagem do AD4M é um registro central, o que mostra ao mesmo tempo a necessidade e o risco); como uma consulta chega às instâncias certas (veja o roteamento de consultas nas perguntas em aberto); como evitar que alguns poucos operadores grandes se tornem o novo centro; e quem paga pelo funcionamento das instâncias.

7. Especificações preliminares

Duas especificações em rascunho saíram deste trabalho. Cada uma é deliberadamente preliminar, está marcada como «Proposta em rascunho» e foi escrita de modo que possa ser levada para o seu próprio repositório. Ainda não estão publicadas; esta página as resume.

Especificação A: Sincronização entre instâncias e proveniência. Propõe que a sincronização entre instâncias seja definida como um perfil do KOI-net e não como um transporte novo, sujeito à confirmação de que os rascunhos do KOI-net permitem novos tipos de objeto (uma pergunta em aberto). Suas ideias centrais:

• uma chave do sujeito derivada apenas do localizador canônico de uma fonte, de modo que todas as instâncias nomeiem a mesma fonte de forma idêntica, mantida separada de uma derivação por instância (a interpretação que uma instância faz daquela fonte em um dado momento);
• os eventos existentes NEW/UPDATE/FORGET mapeados para o ciclo de vida da derivação, com manifestos difundidos amplamente e conteúdos completos buscados sob demanda, de modo que cada instância mantenha um cache parcial;
• proveniência obrigatória em cada objeto (de onde veio, quando, por qual driver e método, e se uma pessoa o revisou), alinhada ao W3C PROV-O;
• atestações assinadas (verificada, contestada, substituída) como objetos sincronizados comuns; e
• confiança local: a especificação define como os sinais de confiança são representados e verificados, não em quem confiar, e as interpretações conflitantes de uma mesma fonte coexistem em vez de serem fundidas.

Especificação B: Contrato do driver e objeto de conhecimento normalizado. Define o que um driver recebe e devolve e a forma do que ele emite. Suas ideias centrais:

• RDF serializado como JSON-LD, verificado com SHACL, como alvo comum, com GRC-20 e Murmurations como formatos de exportação e não como forma canônica (o GRC-20 ainda é um rascunho e o mapeamento não é sem perdas);
• cada afirmação traz um valor de confiança, sua base e um ponteiro para a fonte mostrando de onde veio;
• status de resultado explícitos, para que «não encontrou nada» nunca seja confundido com «não conseguiu ler» ou «a fonte mudou»; e
• limites firmes para a extração assistida por modelos de linguagem: nenhuma afirmação sem um trecho citado da fonte, validação antes de emitir e nenhum preenchimento silencioso de lacunas.

8. Como os drivers poderiam ser desenvolvidos

Um driver lê uma fonte em sua forma nativa e emite objetos de conhecimento na forma que a especificação B define. O trabalho é parecido de uma fonte para outra e segue as três primeiras etapas da Visão geral: ingestão, normalização e enriquecimento. Depois a instância armazena e serve o resultado. Um driver mínimo precisa apenas das duas primeiras etapas; o enriquecimento pode ser acrescentado depois.

Ingestão: ler a fonte

• Métodos de acesso. As fontes são alcançadas por meio de APIs nativas de protocolo (como o índice do Murmurations, a API GraphQL do Hylo ou a API MediaWiki da wiki da P2P Foundation), scrapes agendados de páginas estruturadas, exportações públicas (como Kumu JSON), importações manuais ou em lote (CSV ou exportações de cofres de notas) e APIs de dados geográficos. A análise de fontes de dados lista o método de acesso de cada fonte candidata.
• Guardar o resultado bruto. Os dados recuperados devem cair em uma área de staging simples antes de qualquer transformação, para que uma normalização que falhou possa ser reexecutada sem buscar a fonte de novo. Os status de resultado da especificação B mantêm «não conseguiu ler» distinto de «não encontrou nada».
• Orquestração. Agendar e encadear esses passos pode usar um motor de fluxos de trabalho auto-hospedado (por exemplo o n8n), um serviço de automação em nuvem (por exemplo o Make) ou scripts próprios em um agendador. O equilíbrio é entre esforço operacional, custo por operação e flexibilidade.

Normalização: uma forma comum

• Alvo. O driver mapeia o que lê para o objeto de conhecimento normalizado da especificação B. Um vocabulário de entidades como pessoa, organização, projeto, tecnologia, framework, lugar e mídia é um ponto de partida viável para o que os objetos descrevem.
• Resolução de entidades. A mesma entidade costuma aparecer com nomes diferentes («Life Itself» e «Life-Itself»). Funciona bem uma abordagem em duas passagens: correspondência difusa de strings (por exemplo com o RapidFuzz) para achar candidatas, e depois similaridade de embeddings (por exemplo com o sentence-transformers) para pegar duplicatas com nomes diferentes, com os casos duvidosos indo para uma fila de revisão humana. Uma fusão confirmada mantém os registros de origem vinculados ao registro canônico, de modo que a proveniência sobrevive. Como instâncias independentes podem resolver de forma diferente, as fusões são locais e as interpretações conflitantes coexistem.
• Resolução assistida por modelo. Para pares ambíguos, pode-se perguntar a um modelo de linguagem se dois registros descrevem a mesma entidade. É caro em escala e deve seguir os limites da especificação B: nenhuma afirmação sem um trecho citado da fonte e validação antes de emitir.

Enriquecimento: acrescentar significado

• Categorização. Um esquema de categorização pode ser aplicado como um trabalho de etiquetagem em lote: definir as categorias do esquema, classificar cada entidade relevante segundo elas e guardar cada etiqueta junto com o esquema que a produziu. A análise de fontes de dados lista esquemas candidatos.
• Inferência de relações. Além das relações que uma fonte declara, um driver pode inferir coafiliação (organizações em comum), proximidade temática (embeddings próximos), colocalização geográfica e afinidade baseada em esquemas (etiquetas compartilhadas entre esquemas). As relações inferidas devem ser marcadas como inferidas e nunca apresentadas como afirmadas pela fonte.
• Embeddings. Gerar embeddings de cada registro permite busca semântica e agrupamento, usando um serviço gerenciado (por exemplo o Nomic Atlas) ou modelos locais.
• Geografia. As entidades com localização podem ser etiquetadas com biorregião e limites administrativos, usando uma taxonomia de biorregiões como a da One Earth, geocodificação por meio do OpenStreetMap Nominatim e buscas de ponto em polígono.

O que cada instância faz com o resultado

• Armazenar. Cada instância escolhe o seu armazenamento. Um repositório de grafos se adapta a dados com muitas relações (exemplos: Neo4j, SurrealDB, Apache AGE), e um repositório de vetores cuida da busca por similaridade (exemplos: Qdrant, pgvector, Chroma). As Perspectives do AD4M são a alternativa centrada no agente descrita na candidata C.
• Servir. As funções que uma instância exporia são descoberta e busca de entidades; percurso de relações até uma profundidade escolhida; consulta por categoria e etiqueta; similaridade semântica; consultas geográficas; um feed de mudanças para entidades novas, atualizadas e inferidas; e exportação em formatos padrão (perfis Murmurations, CSV, JSON-LD), para que o que as instâncias aprendem possa voltar a fluir para o ecossistema mais amplo.

9. Perguntas em aberto

Estas são as perguntas que os rascunhos de especificação não conseguem resolver sozinhos.

• O que contêm os «resumos estruturados fáceis de percorrer», com precisão suficiente para validá-los entre instâncias independentes que nunca combinaram um formato?
• Quanta manutenção de drivers pode ser automatizada? Os drivers quebram quando as fontes mudam. Quanto reparo os modelos de linguagem podem fazer com segurança, e onde uma pessoa precisa revisar de novo?
• A nova camada de sincronização é um protocolo novo ou um perfil do KOI-net? Isso depende do que o rascunho do KOI-net permite.
• Como funciona o roteamento de consultas em uma rede de instâncias? Cada nó consulta todas as arestas inscritas, ou existe um mecanismo de descoberta mais inteligente?
• Como duplicatas e conflitos são tratados quando dois drivers independentes coletam a mesma fonte de maneira diferente?
• Como a confiança é representada e verificada entre nós que nunca se encontraram, sem virar um concurso de popularidade nem um alvo fácil para identidades falsas?
• Quais são os limites legais de guardar em cache e voltar a servir conteúdo coletado, e de lidar com dados pessoais nele? Eles variam conforme a jurisdição e não são resolvidos aqui.

10. Créditos

A pesquisa de mapeamento de ecossistemas da qual esta proposta surgiu foi originalmente patrocinada pelo Institute of Applied Metatheory. As comunidades da Collaborative Technology Alliance e do DWeb ofereceram percepções e pesquisas úteis que contribuíram para este relatório.

11. Referências

Padrões e especificações

• 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

Projetos e protocolos

• Murmurations. Documentation. docs.murmurations.network (arquitetura: about/architecture; roadmap: about/roadmap)
• KOI-net Protocol Specification, Draft v1.0. dynamicalsystemsgroup.github.io/koi-net-spec; implementação de referência: github.com/DynamicalSystemsGroup/koi-net
• AD4M. Coasys. Documentação: docs.ad4m.dev (Languages, Perspectives, Neighbourhoods e Multi-User Mode); código-fonte: 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

Ferramentas citadas na seção 8

• n8n (orquestração de fluxos de trabalho). n8n.io
• Make (automação de fluxos de trabalho em nuvem). make.com
• RapidFuzz (correspondência difusa de strings). github.com/maxbachmann/RapidFuzz
• sentence-transformers (embeddings locais). sbert.net
• Nomic Atlas (embeddings e agrupamento). atlas.nomic.ai
• One Earth. Navegador de biorregiões. oneearth.org/navigator
• OpenStreetMap Nominatim (geocodificação). 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. Um terceiro modo, a federação baseada em consentimento, é outro mecanismo de convergência distinto: os domínios independentes continuam soberanos e se conectam apenas por meio de pontes acordadas. Ele está incluído na comparação porque é um design distinto, não porque algum projeto seja proposto ou endossado aqui. Seu principal limite para esta visão é que nunca alcança as fontes que não participam. ↩

2. A página de roadmap foi lida em outubro de 2026. Se o desenvolvimento será retomado, e de que forma, é uma decisão dos mantenedores. A documentação do Murmurations usa «o índice» no singular, enquanto o site principal do projeto fala em «índices»; por isso esta página descreve o padrão (um índice mais agregadores que o consultam) sem afirmar quantos índices independentes existem. ↩