Card 1 / Framing
O que o Modelo de Pilha Soberana é e não é
O Modelo de Pilha Soberana não é um modelo de redes genérico. É um modelo com uma postura definida sobre as camadas nas quais são tomadas as decisões arquitetônicas relativas à soberania digital. Esse enfoque o distingue do TCP/IP (que modela a internet em funcionamento) e do OSI (que modela as camadas de rede com fins pedagógicos e de desenvolvimento de padrões).
O modelo condensa as camadas inferiores — meios físicos, enlace de dados, roteamento em nível IP — em uma única L1, porque essas camadas estão, em grande parte, mercantilizadas para fins de soberania. Ele elabora as camadas superiores porque é ali que residem de fato os compromissos de soberania de quem o adota: identidade, dados comunitários, governança, federação, paradigma de aplicação.
Correspondência explícita com o OSI e o TCP/IP. A L1 do SSM absorve as camadas L1–L3 do OSI e L1–L2 do TCP/IP — o substrato físico, de enlace e de roteamento — porque essas camadas são mercantilizadas para fins de soberania. A L2 do SSM (Transporte / Canal) é um análogo direto da L4 do OSI / L3 do TCP/IP. A L3.1 do SSM (Rede de Sobreposição) não tem análogo no OSI nem no TCP/IP; ela fica acima da internet roteada, em vez de no mesmo nível, e é opcional — os sistemas que não usam redes de sobreposição simplesmente a atravessam. O restante da pilha superior do SSM — de L3.2 a L3.6 (as cinco subcamadas restantes de Confiança Comunitária) mais L4 (Aplicação / Interface) — aprofunda o que o OSI chama de camada de aplicação (L7) e o que o TCP/IP chama de sua própria camada de Aplicação, numerada separadamente (também rotulada L4 nesse modelo, distinta da L4 do SSM): elas existem porque é ali que residem as decisões de soberania.
A contrapartida é intencional. O modelo tem alta resolução onde quem o adota precisa dela (seis camadas acima do transporte, onde se tomam a maioria das decisões relevantes para a descentralização) ao custo de uma resolução menor nas camadas sobre as quais a maioria dos adotantes não toma decisões (infraestrutura física e de nível IP).
Card 2 / Comparison
Como os três modelos se relacionam
TCP/IP, OSI e a Pilha Soberana são três formas de dividir o mesmo terreno arquitetônico para propósitos distintos.
O TCP/IP se otimiza para a internet em funcionamento — camadas mínimas, focado no que quem implementa de fato constrói. O OSI se otimiza para a clareza pedagógica e de desenvolvimento de padrões — mais camadas, separação de preocupações mais granular. A Pilha Soberana se otimiza para a tomada de decisões sobre soberania digital — camadas completamente distintas acima do substrato de transporte, focadas em onde residem de fato os compromissos de soberania de quem a adota.
Nenhum dos três é "mais correto" que os outros. Eles respondem a perguntas diferentes. Um engenheiro de redes depurando um problema recorre ao TCP/IP. Um órgão de padronização projetando um novo protocolo recorre ao OSI. Quem adota e tenta decidir em qual pilha descentralizada apostar recorre a algo como a Pilha Soberana.
Card 3 / Analogues
Onde os análogos são claros e onde não são
Os análogos horizontais diretos são claros para a camada de transporte — o Transporte do TCP/IP, a L4 Transporte do OSI e a L2 Transporte / Canal do SSM concordam sobre o que é transporte. Abaixo do transporte, os três modelos dividem o território de forma diferente, mas o compartilham.
Os análogos distorcidos (diagonais) aparecem em dois lugares. A L3 Rede do OSI e a Internet do TCP/IP são absorvidas na L1 do SSM — a Pilha Soberana condensa o substrato de roteamento IP em uma única camada fundacional, em vez de separar o roteamento físico, de enlace e de rede. A L3.1 Rede de Sobreposição do SSM é um conceito completamente diferente (redes de sobreposição construídas sobre a internet roteada, não a internet roteada em si). De modo semelhante, a L6 Apresentação do OSI é, em sua maior parte, absorvida na L3.2 Dados & Semântica do SSM, já que a Pilha Soberana trata o formato dos dados e sua semântica como algo integrado, em vez de dividi-los em camadas separadas.
Para a terceira grande assimetria — a L5 Sessão do OSI não ter análogo na Pilha Soberana — veja o cartão dedicado abaixo.
Card 4 / OSI L5 Session
Por que a Sessão do OSI não tem análogo na Pilha Soberana
A camada de Sessão do OSI cuida de estabelecer, manter e recuperar interações de longa duração entre pontos finais — pontos de sincronização, controle de diálogo e retomada de sessão após uma interrupção. A Pilha Soberana não extrai essas preocupações em uma única camada, porque, no panorama dos sistemas descentralizados, a sessão é tratada em camadas diferentes, dependendo da entidade:
O QUIC gerencia a sessão de conexão na L2 Transporte / Canal do SSM — migração de conexão, retomada 0-RTT, controle de fluxo por stream. As sessões de sincronização do Willow residem na L3.2 Dados & Semântica do SSM — negociação de área de interesse, rodadas de reconciliação, suporte à retomada. A continuidade de mensagens em thread do DIDComm reside na L3.3 Identidade & Soberania do Usuário do SSM — IDs de thread, IDs de thread pai, rotação de mensagens. O emparelhamento entre instâncias do ActivityPub gerencia seus próprios equivalentes de sessão na L3.6 Federação do SSM — semântica de entrega servidor-a-servidor.
A escolha de qual camada trata a sessão é, em si, uma decisão de arquitetura de soberania. Extrair a sessão para uma única camada do SSM obscureceria essa escolha — condensando compromissos arquitetônicos significativamente diferentes em uma uniformidade enganosa. A omissão da Pilha Soberana é deliberada: a sessão é real e importante, mas é corretamente entendida como uma preocupação que atravessa camadas, e não como uma camada própria.
Card 5 / Methodology
Como o SSM difere do mapeamento genérico de capacidades
Existem duas formas de organizar uma descrição do que um sistema complexo faz. Uma é o mapeamento de capacidades — identificar as capacidades discretas que um sistema oferece e dispô-las como um grafo ou hierarquia, com relações entre elas. A outra é a modelagem em camadas — comprometer-se com um pequeno número de camadas ordenadas, cada uma com um papel definido, e posicionar as capacidades dentro delas. O SSM é a segunda opção.
O mapeamento de capacidades tem forças reais. Ele capta a complexidade com fidelidade, acomoda novas capacidades com facilidade e não impõe compromissos onde ainda não são justificados. O custo é que cada mapa é sob medida — a comparação entre mapas é difícil, e a falta de uma estrutura geral dificulta o uso dos mapas de capacidades para a tomada de decisões.
O SSM se compromete com uma estrutura em camadas com um esquema definido: nove posições de camada numeradas — L1, L2, a camada de Confiança Comunitária de seis partes (L3.1–L3.6) e L4 — cada uma com um papel específico, e as entidades posicionadas em sua camada principal (às vezes abrangendo várias). O custo dessa abordagem é que parte da informação se perde — em particular, as preocupações transversais e as capacidades que não se encaixam claramente em uma única camada. O benefício é que a comparação se torna possível: duas arquiteturas podem ser examinadas quanto ao que colocam em L3.3, ao que colocam em L3.6, ao que deixam vazio.
Essa comparação é o propósito. O SSM é projetado para quem adota e tenta escolher entre pilhas descentralizadas, para colaboradores que tentam entender onde seu trabalho se encaixa, e para pesquisadores que tentam identificar lacunas no panorama. Os três se beneficiam de um vocabulário compartilhado em camadas de formas que um mapa de capacidades sob medida não pode oferecer.
A escolha metodológica é intencional e estrutural. O SSM troca fidelidade por legibilidade — escolhendo uma estrutura que permite a comparação em vez de uma que capte cada nuance.
Card 6 / Cross-cutting concerns
Propriedades que não pertencem a uma única camada
Algumas propriedades arquitetônicas atravessam as camadas em vez de residir em uma só. O histórico imutável, o endereçamento por conteúdo, os registros de auditoria vinculados por Merkle, o versionamento e o estado reproduzível são decisões em nível de protocolo que podem ser implementadas em L3.2 (Dados & Semântica), L3.3 (Identidade & Soberania do Usuário), L3.4 (Dados Comunitários & Governança), L3.5 (Coordenação entre Pares) ou L3.6 (Federação), dependendo do protocolo. Nenhuma dessas propriedades tem uma única camada em que sempre reside.
A camada na qual um protocolo implementa essa propriedade é, em si, um compromisso arquitetônico relevante para a soberania. O endereçamento por conteúdo implementado em L3.2 produz estruturas de dados verificáveis nas quais qualquer camada acima pode confiar. Implementado em L3.5, produz um substrato de coordenação entre pares com detecção de adulteração embutida. Implementado em L3.6, produz federação com responsabilização criptográfica entre instâncias. Esses são mundos arquitetônicos significativamente diferentes, ainda que a técnica subjacente — aplicar hash ao conteúdo para endereçá-lo — seja a mesma.
O SSM não extrai essas preocupações para uma camada própria, porque fazer isso obscureceria exatamente as escolhas que mais importam. Quem ler e encontrar o endereçamento por conteúdo em um posicionamento do SSM deveria perguntar: em qual camada esse protocolo o implementa, e a que essa posição compromete a arquitetura? A mesma pergunta se aplica ao histórico imutável, aos registros de auditoria e ao versionamento. A natureza transversal dessas propriedades é uma característica do modelo, não uma lacuna.
Uma nota sobre a linguagem: quando a descrição de uma entidade menciona uma dessas propriedades, entende-se que a propriedade é implementada na camada principal da entidade, salvo indicação em contrário. Entidades que implementam propriedades transversais em múltiplas camadas — algo comum em ambientes de execução integrados — refletem isso em seu próprio perfil de entidade, e não no modelo de camadas em si.
Card 7 / Origins
De onde vem este modelo
O Modelo de Pilha Soberana surgiu de um trabalho colaborativo entre três comunidades de grupos de trabalho que se sobrepõem, cada uma contribuindo com um enfoque complementar.
A Collaborative Technology Alliance (CTA) é uma coalizão de organizações e indivíduos que trabalham com tecnologia pró-social, descentralizada e orientada aos comuns. A OpenHaven é o grupo de trabalho de tecnologias ponto a ponto da CTA — o mesmo projeto sob um nome de trabalho — e é o principal local onde este modelo é mantido e refinado à medida que novas entidades surgem e a taxonomia evolui. A DWeb (o projeto Decentralized Web do Internet Archive, incluindo o DWeb Camp e os DWeb Working Groups) oferece um espaço de convergência mais amplo para praticantes de tecnologia descentralizada e contribui com o enfoque social e político de "soberania digital" que motiva as camadas superiores do modelo.
O modelo é atribuído a este esforço colaborativo, e não a nenhuma organização isolada. À medida que o catálogo de entidades cresce e novos padrões arquitetônicos surgem no ecossistema, espera-se que o modelo evolua através do mesmo processo de grupos de trabalho — com revisões apresentadas para revisão da comunidade, em vez de impostas unilateralmente.
Card 8 / Version history
Versões e colaboradores
O Modelo de Pilha Soberana é um artefato de trabalho desenvolvido por meio de rascunhos iterativos e revisão da comunidade.
V1 (2025) foi produzida pelo grupo de trabalho World Wise Web, com a colaboração de Brad deGraf, Josh Field, Day Waterbury e Brandon Nørgaard.
V2 (2026) foi apresentada no Internet Identity Workshop XLII (IIW 42), onde recebeu feedback que orientou as revisões subsequentes.
V3 (2026) incorpora as revisões do ciclo de revisão da V2 e as contribuições contínuas das comunidades mais amplas da Collaborative Technology Alliance, OpenHaven e DWeb.
V4 (atual, 2026) reagrupa as seis camadas intermediárias sob uma camada de Confiança Comunitária subdividida (3.1–3.6) e renumera Aplicação / Interface para L4, alinhando o nível superior do modelo em quatro camadas: Rede, Transporte, Confiança Comunitária e Aplicações.
Feedback é bem-vindo. Para sugerir revisões, levantar uma questão ou contribuir para futuras versões, entre em contato com Brandon Nørgaard em brandon@civicenlightenment.org.