Posicionamento de Entidades da OpenHaven — Referência da Pilha Soberana

v3 / Entidades selecionadas posicionadas em relação ao Modelo de Pilha Soberana da OpenHaven

Um diagrama de referência que posiciona uma seleção curada de entidades rastreadas pela OpenHaven em suas camadas principais do modelo de pilha. O modelo de camadas usado aqui é o Modelo de Pilha Soberana da OpenHaven, desenvolvido em conjunto pelos grupos de trabalho da OpenHaven, da Collaborative Technology Alliance (CTA) e da DWeb. As entidades são extraídas da taxonomia da OpenHaven, com peso maior para aquelas com adoção real substancial e atenção dos desenvolvedores. A cor da borda do chip indica o tipo de entidade (definições no cartão de referência abaixo). Passe o cursor sobre qualquer chip para ver uma breve descrição, atributos-chave e a URL principal. As entidades transversais — aquelas cujo compromisso arquitetônico atravessa múltiplas camadas — são marcadas com uma de quatro visualizações transversais: ocupa, abstrai, subsume e suíte. O posicionamento indica a responsabilidade arquitetônica principal de cada entidade, não a única ou exclusiva — muitas entidades têm funcionalidade real em outras camadas mesmo quando nada no diagrama as marca como transversais; as faixas transversais explícitas são reservadas para um punhado de casos ilustrativos (Holochain, AD4M, NextGraph, as suítes), não uma lista exaustiva de cada entidade com alcance multicamada. Trate o posicionamento como um auxílio arquitetônico de orientação, não como uma classificação absoluta. Este diagrama é uma amostra, não um mapa abrangente. O panorama completo e os agrupamentos funcionais dinâmicos serão gerados programaticamente assim que os dados da OpenHaven forem migrados para um banco de dados relacional com uma camada de grafo complementar.

Posicionamento de entidades

As camadas vão de L4 (Aplicação / Interface) no topo até L1 (Físico / Rede) na parte inferior, seguindo o Modelo de Pilha Soberana da OpenHaven — de L3.1 a L3.6, no meio, formam a camada de Confiança Comunitária (ver trilho). Cada entidade fica em sua camada principal; as relações transversais são mostradas como marcadores de sobreposição (ver legenda). A seleção é ilustrativa, não exaustiva — inclui as entradas mais amplamente adotadas de cada tipo de entidade, além de todos os membros das suítes marcadas. Role horizontalmente se as linhas de entidades ultrapassarem a largura da tela.

L4
Aplicação / Interface
BlueSkyMastodonPeerTubeMobilizonLogseqAFFiNEAnytypeNextcloudHolonsNDN WorkspaceGroup IncomeA2A
L3 Confiança Comunitária
L3.6
Federação
ActivityPubATProtoMatrixSolidNostr (relay federation)KOI-net
L3.5
Coordenação entre Pares
HolochainAD4MNextGraphGordian ClubsVeilidDittoActivityPods
L3.4
Dados Comunitários & Governança
BonfireSemAppsTRQPOpenVTC
L3.3
Identidade & Soberania do Usuário
XIDFANFedID
L3.2
Dados & Semântica
Gordian EnvelopeIPFSFilecoinJSON-LDMurmurationsValueflowsCeramicWillowIrohMCPERC-8004SIWEERC-4337RIDsW3C VCs
L3.1
Rede de Sobreposição
Hubertlibp2pKitsuneTorI2PSnowflakeNostrCashuDIDCommTSP
L2
Transporte / Canal
NoiseReticulumMeshtasticTor (onion routing)I2P (garlic routing)W3C DIDs
L1
Física / Rede

Borda do chip — maturidade

O estilo da borda de um chip indica o nível de maturidade da entidade. A cor da borda continua codificando o tipo de entidade (ver o cartão de definições abaixo).

Solid
Maduro — versão de produção estável com ampla adoção e implantações ativas. Exemplos: Mastodon, IPFS, libp2p, W3C DIDs.
Dashed
Alfa / Beta — possui implementações funcionais, mas ainda não uma versão de produção estável. As especificações ainda estão evoluindo; as implantações são limitadas ou estão em adoção inicial. Exemplos: FAN, FedID, KOI-net, Gordian Envelope.
Dotted
Somente especificação — existe uma especificação ou rascunho, mas ainda não há implementações conhecidas implantadas em produção. Pode haver apenas código de referência. Exemplos: TSP (Implementers Draft), TRQP (Revisão Pública), ERC-8004 (ERC Draft).

Marcadores transversais

As entidades transversais são representadas como faixas que envolvem seus chips membros. O estilo do contorno da faixa codifica o tipo de transversalidade. Cada interseção (faixa, linha) pode ter um pequeno indicador — passe o cursor sobre ele para ver uma explicação do que está acontecendo naquela camada específica.

Ocupa Faixa de tinta sólida. Um único ambiente de execução integrado, implementado através de múltiplas camadas; componentes inseparáveis. Exemplos: Holochain (L3.2 + L3.5 + L4), NextGraph (L3.1 a L4).
Abstrai sobre Faixa violeta tracejada. Fornece uma camada de abstração unificada sobre substratos conectáveis em múltiplas camadas. Exemplo: AD4M.
Subsume (dentro da faixa) Um marcador de círculo cruzado colocado dentro da faixa em uma linha específica indica que a entidade subsume a função tradicional daquela camada em vez de implementá-la. Exemplo: AD4M Neighbourhoods substituindo a federação em L3.6.
Suíte Faixa tracejada na cor específica da suíte. Componentes separáveis co-projetados que se combinam em uma solução coerente; os membros permanecem substituíveis individualmente. Exemplos: Gordian Suite (dourado), KOI (verde-azulado), W3C SSI Suite (violeta), ToIP Suite (verde-sálvia).

Definições de Tipos de Entidade

Protocolo P2P
Uma especificação formal que define formatos de mensagens, roteamento e padrões de interação que permitem aos nós se comunicarem e se coordenarem sem prescrever a implementação. Preocupações no nível de transmissão; o protocolo é separável de qualquer implementação específica.
Plataforma P2P
Infraestrutura reutilizável para desenvolvedores, construída sobre um ou mais protocolos externos, que fornece SDKs, identidade, armazenamento e serviços componíveis que os aplicativos consomem. A plataforma é construída sobre seus protocolos subjacentes, não co-projetada com eles.
Ambiente de Execução P2P Integrado
Uma tecnologia em que o modelo de dados, o protocolo de sincronização, a arquitetura de segurança e o ambiente de desenvolvimento de aplicações são co-projetados como um único todo inseparável. O protocolo não existe de forma independente do seu ambiente de execução.
Infraestrutura P2P
Redes de nós ativas e operacionais que fornecem serviços de transporte, roteamento, privacidade ou acesso dos quais outros sistemas dependem. Definidas por serem um serviço em funcionamento, não uma especificação, e normalmente projetadas para condições adversas.
Protocolo de Dados Descentralizado
Uma especificação sobre como os dados estruturados são nomeados, endereçados, replicados e sincronizados em uma rede P2P. Trata do endereçamento por conteúdo, dos algoritmos de sincronização e da semântica de mutabilidade, em vez de como os nós se comunicam ou o que os dados significam.
Protocolo de Federação
Uma arquitetura de comunicação em que os usuários se conectam a servidores operados de forma independente (instâncias), e esses servidores mantêm relacionamentos entre pares para rotear mensagens, compartilhar conteúdo ou coordenar atividades em nome de seus usuários.
Protocolo Semântico e de Dados
Uma especificação formal para descrever, estruturar ou vincular dados de modo que sejam interpretáveis entre sistemas, aplicações e organizações sem uma implementação compartilhada. Vocabulários, esquemas e modelos de grafos para uma semântica portátil.
Protocolo de Identidade
Uma especificação formal que define a criação de identificadores, a emissão de credenciais, a autenticação ou o estabelecimento de confiança, sem prescrever a implementação. A especificação é separável de qualquer kit de ferramentas específico.
Kit de Ferramentas / Plataforma de Identidade
Infraestrutura para desenvolvedores que implementa um ou mais Protocolos de Identidade e expõe suas capacidades por meio de SDKs, APIs ou frameworks. Software funcional para criadores, em vez de um documento de especificação.
Sistema / Design de Identidade
Uma arquitetura inédita que propõe uma abordagem fundamentalmente nova para identidade, confiança ou personalidade, articulada como um white paper ou nota de pesquisa. A contribuição principal é a percepção arquitetônica, não o software funcional.
Aplicativo Descentralizado
Um produto de software para o usuário final que realiza tarefas específicas e delimitadas usando protocolos descentralizados, com um limite claro entre usar o aplicativo e construir sobre ele. Os usuários consomem a funcionalidade do aplicativo.
Aplicativo Descentralizado Extensível
Um aplicativo descentralizado no qual o limite entre usar e construir é dissolvido por design. A composabilidade e a extensão são intrínsecas; os usuários montam nova funcionalidade dentro da própria interface do aplicativo.
Padrão de Contrato Inteligente
Uma especificação formal cuja realização principal é um ou mais contratos implantáveis on-chain. O contrato implantado não é uma implementação do padrão, mas o próprio padrão, instanciado como estado compartilhado on-chain.
Rede de Armazenamento Descentralizada
Uma rede em que operadores de nós distribuídos fornecem capacidade de armazenamento de dados persistente aos usuários, sustentada por meio de incentivos criptoeconômicos, contribuição voluntária ou governança cooperativa. Definida pela custódia persistente como serviço central.
Spanning

Quatro tipos de entidades que abrangem múltiplas camadas

A OpenHaven reconhece quatro formas arquitetonicamente distintas pelas quais uma entidade pode abranger múltiplas camadas da Pilha Soberana. Cada entidade transversal é representada como uma faixa que envolve seus chips membros e passa pelas linhas que abrange; o estilo do contorno da faixa identifica de que tipo de transversalidade se trata.

  • Ocupa — a entidade é um único ambiente de execução integrado cujos componentes em cada camada são inseparáveis entre si (Holochain em L3.2 + L3.5 + L4; NextGraph abrangendo de L3.1 a L4).
  • Abstrai sobre — a entidade fornece uma camada de abstração unificada sobre substratos conectáveis, permitindo que as implementações específicas de cada camada subjacente sejam trocadas sem alterar a abstração (AD4M).
  • Subsume — aparece como um marcador dentro de outra faixa em uma linha específica, indicando que a entidade substitui a função tradicional daquela camada por um mecanismo diferente. Os Neighbourhoods do AD4M, por exemplo, substituem a federação em vez de implementá-la.
  • Suíte — uma família de componentes separáveis co-projetados, cada um em sua própria camada, projetados em conjunto para compor uma solução coerente enquanto permanecem substituíveis individualmente (Gordian Suite, KOI, W3C SSI Suite, ToIP Suite, Protocol Labs Suite).

Cada interseção (faixa, linha) pode ter um indicador , exibindo informações contextuais específicas da interseção ao passar o cursor — útil para casos como a relação do AD4M com a federação, em que o compromisso arquitetônico naquela camada específica precisa de explicação. A gramática unificada de faixas permite que os quatro tipos de transversalidade compartilhem uma única lógica visual.

Pathways

Caminhos de adoção e agrupamentos funcionais

As entidades na OpenHaven costumam ser adotadas por meio de agrupamentos funcionais, e não como componentes isolados. Os agrupamentos que surgiram na prática atual do ecossistema incluem:

  • SSI / confiança digital — DIDs, VCs, DIDComm nas camadas inferiores, com TSP e TRQP como protocolos transversais.
  • Social do Fediverso — aplicativos baseados em ActivityPub (Mastodon, PeerTube, Mobilizon, Bonfire) e protocolos adjacentes.
  • Coordenação cívica e financiamento coletivo — Murmurations, Valueflows, Bonfire, Holons, e a infraestrutura emergente de organização do conhecimento como o KOI.
  • Economia de agentes — MCP, A2A, x402, ERC-8004; um agrupamento jovem se formando em torno do momento da IA agêntica.
  • Autocustódia e dados pessoais — as ferramentas da Gordian Suite para autossoberania criptográfica.
  • Armazenamento descentralizado e entrega de conteúdo — a Protocol Labs Suite (libp2p, IPFS, Filecoin) para dados endereçados por conteúdo e armazenamento descentralizado persistente.

Esses agrupamentos não são mutuamente exclusivos — uma única implantação costuma se compor por diversos caminhos (SSI mais Fediverso, ou coordenação cívica mais autocustódia). Os agrupamentos funcionais ficarão mais legíveis em diagramas dinâmicos assim que os dados da OpenHaven forem migrados para uma camada consultável como grafo; esta referência estática não tenta representá-los.

Gaps

Lacunas de cobertura que o diagrama revela

Ao examinar o diagrama, surgem alguns pontos onde a cobertura de entidades ou a taxonomia da OpenHaven poderia crescer.

  • As bibliotecas de suporte são invisíveis — os motores CRDT, as primitivas criptográficas e as bibliotecas de serialização (Loro, Yjs, Automerge, implementações de BLAKE3, libsodium) executam dentro do processo das entidades que a OpenHaven classifica atualmente, mas não têm um tipo de entidade próprio. Se convém adicionar um tipo de Componente de Subcamada ou Motor de Sincronização é uma questão em aberto, adiada até depois da migração do banco de dados.
  • O agrupamento da economia de agentes se encaixa de forma incômoda em P2P Pro — MCP, A2A e x402 são especificações cliente-servidor, e não ponto a ponto no sentido arquitetônico. Sua inclusão segue o precedente estabelecido por especificações abertas adjacentes com múltiplos implementadores, mas o encaixe é estrutural, não ideal.
  • L2 Transporte / Canal está pouco povoado em relação à crescente importância da camada. QUIC, WebRTC, WebSockets e os protocolos de canal criptografado além do Noise são relevantes para a soberania, mas ainda não são rastreados individualmente.

Essas observações são conservadoras — identificam lacunas das quais os colaboradores da OpenHaven já têm conhecimento, em vez de fazer afirmações sobre a escala de implantação ou o tamanho da comunidade que exigiriam verificação independente.

DID Ecosystem

Por que "W3C DIDs" não é uma única camada

Os identificadores descentralizados costumam ser apresentados como uma única tecnologia, mas o ecossistema DID na verdade abrange várias camadas da Pilha Soberana, cada uma com uma responsabilidade arquitetônica distinta.

  • DID Core — L2. O chip W3C DIDs (linha L2) fica ali porque o DID Core fornece principalmente identificadores descentralizados, sintaxe DID, Documentos DID e resolução de identificadores — infraestrutura fundacional de nomenclatura e resolução. O DID Core em si não define soberania do usuário, relações de confiança, carteiras, troca de credenciais, governança ou mecanismos de recuperação; esses são compromissos arquitetônicos separados sobrepostos.
  • DIDComm — L3.1. O DIDComm pertence principalmente a L3.1 porque estabelece relações seguras entre pares e canais de comunicação entre partes identificadas por DID, não os identificadores ou a identidade em si.
  • Credenciais Verificáveis — L3.2. As VCs do W3C e os modelos de dados semânticos relacionados pertencem principalmente a L3.2 porque definem representações interoperáveis de alegações e provas — uma questão de dados e semântica, distinta de identidade ou transporte.
  • Carteiras e agentes de identidade — L3.3. A gestão de chaves, a recuperação, a delegação, os frameworks de confiança e a identidade controlada pelo usuário pertencem principalmente a L3.3. Nenhum chip dedicado representa essa classe de ferramentas na seleção atual de entidades do diagrama.
  • Os métodos DID variam em seu alcance de camada. Métodos leves como did:key ou did:web funcionam principalmente como mecanismos de identificação e permanecem próximos de L2. Ecossistemas DID mais sofisticados — métodos apoiados em ledger com gestão de ciclo de vida, delegação ou recuperação embutidas — assumem cada vez mais responsabilidades de identidade de camada superior que se aproximam de L3.3.

A lição geral: classifique uma tecnologia relacionada a DID pela responsabilidade arquitetônica específica que ela fornece — resolução de identificadores, mensagens seguras, semântica de credenciais ou soberania de identidade — em vez de tratar "W3C DIDs", ou "DIDs" em geral, como uma única tecnologia monolítica que vive em uma só camada.