Comunidades humanas sempre propagaram informação através do boca a boca.
Uma pessoa compartilha novidades com seu círculo íntimo, que compartilha com os deles, criando uma propagação epidêmica através de um grafo social ponderado por confiança. Esse mecanismo possui três propriedades que protocolos formais de gossip buscam replicar.
Filtragem por confiança
Uma informação vinda de um amigo próximo tem mais peso do que de um estranho. Uma afirmação sobre a pessoa X significa coisas diferentes vindo de alguém a 1 hop versus 4 hops de distância.
Preservação de contexto
O boca a boca dentro de uma comunidade preserva contexto: quem disse o quê, para quem, em que circunstâncias. Fofoca sem contexto é calúnia; com contexto, é sinal.
Redundância natural
Informações importantes chegam a você por múltiplos caminhos independentes. Se um amigo está indisponível, outro traz a mesma atualização. A redundância é proporcional à relevância social da informação.
Esses não são ideais abstratos. É assim que toda vila, todo grupo de amigos, toda comunidade sempre funcionou. Aí a vida social migrou para o online.
Plataformas centralizadas não apenas falharam em preservar essas propriedades — elas engenheiraram o oposto.
No Twitter, Facebook e Instagram, um algoritmo decide o que você vê — otimizado para engajamento, não para confiança. O post viral de um estranho chega a você antes da atualização do seu amigo.
Um post feito para amigos íntimos aparece ao lado de estranhos. O Instagram achata momentos íntimos em performance pública. Sem contexto, comunicação vira performance.
Seus dados, relacionamentos e todo o seu histórico vivem nos servidores de uma empresa. Se eles te banirem, mudarem os termos ou fecharem — tudo desaparece. Não existe fallback.
Bilhões de pessoas se comunicam através de infraestrutura projetada para extrair atenção, não para preservar relacionamentos.
Protocolos descentralizados surgiram para devolver esse controle aos usuários. Mas mesmo assim, tudo passa por servidores que decidem o que é armazenado, servido e censurado.
Controle de armazenamento
Servidores decidem quais dados armazenar e por quanto tempo.
Controle de distribuição
Servidores decidem quais dados servir e para quem.
Capacidade de censura
Operadores podem silenciosamente descartar conteúdo ou suspender contas.
Alavancagem econômica
Usuários precisam pagar operadores ou aceitar seus termos.
Isso recria a dependência de plataforma que protocolos descentralizados foram projetados para eliminar. O grafo social do usuário vive em infraestrutura que ele não controla.
E se o próprio grafo social fosse a infraestrutura?
Propomos uma arquitetura local-first onde a estrutura social da rede é sua infraestrutura. Seus relacionamentos se tornam sua rede de armazenamento, seu grafo de confiança se torna seu sistema de entrega, e relays são rebaixados a aceleradores opcionais.
O armazenamento primário reside no dispositivo do usuário e nos pares próximos do WoT (1–2 hops).
A recuperação primária consulta a rede de confiança primeiro, não a infraestrutura de relays.
O papel do relay é rebaixado a descoberta e curadoria opcionais — útil para alcance além do grafo, não necessário para existir.
Os dados são auto-autenticados e portáveis. Cada evento é assinado pelas chaves do autor, conversível de e para ActivityPub, AT Protocol e outros formatos descentralizados.
Como o protocolo funciona
Pactos de Armazenamento
Um pacto de armazenamento é um acordo bilateral entre dois nós para armazenar os eventos um do outro. A formação segue uma negociação em três fases: Request, Offer, Accept. Parceiros de pacto são verificados através de trocas periódicas de challenge-response — desafios de hash comprovam que os dados estão disponíveis sem transferir eventos completos. Cada nó mantém cerca de 20 pactos ativos (mínimo de 12), renovados por padrão; um parceiro que falha é simplesmente descartado e substituído.
Recuperação em Camadas
Quando um nó precisa recuperar eventos de um autor seguido, o protocolo tenta a entrega através de uma cascata de caminhos progressivamente mais custosos: o armazenamento local do pacto, depois uma consulta criptografada direta aos parceiros de pacto do autor, e finalmente o fallback via relay como último recurso. Cada camada só é tentada quando a anterior falha, criando um gradiente natural de custo que mantém a maior parte do tráfego dentro do grafo social.
Roteamento Gossip
Como uma extensão opcional de resistência à censura, o encaminhamento filtrado por WoT do protocolo espelha como humanos compartilham seletivamente: parceiros de pacto ativos têm prioridade máxima, depois pares WoT a 1 hop, depois pares a 2 hops se a capacidade permitir. Fontes desconhecidas nunca são encaminhadas — a fofoca de estranhos para na sua porta. O caminho de leitura primário é mais simples: as requisições de dados são criptografadas com NIP-44 diretamente para um par de armazenamento escolhido, então a privacidade do leitor vem de manter os metadados da requisição entre os seus pares da rede de confiança em vez de em relays públicos — não de esconder quem está perguntando.
O que o protocolo possibilita
Sincronização multi-dispositivo sem compartilhar chaves
Cada dispositivo recebe sua própria subchave, delegada a partir da sua identidade raiz. Seu celular, notebook e extensão de navegador assinam eventos independentemente — sem cópia de chave privada, sem ponto único de comprometimento. Quando os dispositivos ficam online, eles reconciliam via checkpoints: uma prova Merkle leve que confirma que cada dispositivo viu os eventos mais recentes dos outros. A resolução de conflitos é automática. Se dois dispositivos editam seu perfil simultaneamente, os campos se fundem pelo timestamp mais recente. Listas de follows se fundem por operações de conjunto. Eventos se encadeiam por números de sequência por dispositivo, tornando retenção e reordenação detectáveis em tempo real.
Criptografia com hierarquia de chaves sob medida
Sua chave raiz fica fria — numa hardware wallet ou máquina air-gapped. A partir dela, o protocolo deriva chaves com propósitos específicos: chaves de dispositivo para eventos do dia a dia e uma chave de governança para alterações de perfil e follows. Mensagens criptografadas usam uma chave de DM dedicada, derivada de sua própria semente independente, então comprometer sua chave raiz nunca expõe DMs passadas. Essa chave de DM rotaciona a cada 90 dias, limitando a exposição de qualquer período isolado — isso é rotação periódica de chaves, não sigilo avançado. Nem todo dispositivo precisa de acesso a DM — seu desktop e celular podem descriptografar mensagens, enquanto sua extensão de navegador só publica. Se um dispositivo for comprometido, revogue sua subchave. Sua identidade, suas DMs, seu grafo social: intactos.
Dados portáveis entre protocolos
Todo evento é auto-autenticado — assinado pelas chaves do autor, verificável por qualquer pessoa. Isso torna a ponte entre protocolos algo direto: eventos Nostr se convertem em atividades ActivityPub para Mastodon, em registros AT Protocol para Bluesky, e em feeds RSS/Atom para sindicação. Sua identidade se conecta por meio de atestações assinadas vinculando sua pubkey secp256k1 a URIs de ator ActivityPub ou DIDs do AT Protocol. Você pode exportar seu histórico completo como um arquivo assinado — à prova de adulteração, importável em qualquer cliente compatível.
Modelo de feed em três camadas
Nem todos os relacionamentos são iguais, e o protocolo sabe disso. Seu Círculo Íntimo — follows mútuos com pactos ativos — recebe entrega contínua em tempo real. Sua Órbita — autores de alta interação e descobertas socialmente endossadas — recebe polling periódico. Seu Horizonte — grafo de 2 hops e descobertas via relay — recebe busca sob demanda. As camadas emergem do seu comportamento social real: responda, reposte e reaja a alguém o suficiente, e essa pessoa se aproxima. Pare de interagir, e ela se afasta. Nenhum algoritmo decide isso. Sua atenção decide.
Recuperação social
Perdeu sua chave raiz? Designe contatos de recuperação da sua Web of Trust. Se o pior acontecer, a verificação de limiar N-de-M entra em ação: seus contatos verificam sua identidade fora de banda, publicam atestações de recuperação, e após um timelock de 7 dias — dando ao dono legítimo tempo para cancelar — sua nova chave assume. Sem seed phrases para esquecer. Sem serviço centralizado de recuperação. Apenas as pessoas que te conhecem.
Onde o Gozzip se encaixa
O Gozzip não é um substituto para protocolos existentes. É uma camada que faltava — construída especificamente para complementar o que Nostr e BitChat já fazem bem, e para resolver problemas que designs peer-to-peer anteriores como o Scuttlebutt deixaram em aberto.
Complementando o Nostr
O Nostr deu ao mundo descentralizado algo essencial: um protocolo simples baseado em relays onde a identidade é um par de chaves e os eventos são auto-autenticados. Mas o modelo de relays do Nostr significa que seus dados vivem em servidores que você não controla, sem garantia de persistência. O Gozzip adiciona a camada de armazenamento: pactos bilaterais entre pares que se conhecem, aplicados por desafios criptográficos, recíprocos, mas sem equiparação de volume. Sua identidade Nostr funciona diretamente — mesmas chaves secp256k1, mesmo formato de evento. O Gozzip não cria um fork do Nostr. Ele dá aos usuários do Nostr uma forma de serem donos dos seus dados sem depender de operadores de relay.
Complementando o BitChat
O BitChat resolve um problema diferente: mensagens criptografadas peer-to-peer sobre Bluetooth Low Energy, com handshakes Noise Protocol, enquadramento binário compacto e relay multi-hop de até 7 dispositivos. Ele se destaca como camada mesh em tempo real — efêmera, local, projetada para cenários onde não há internet. O Gozzip adiciona persistência por cima: pactos de armazenamento que mantêm seus dados vivos quando você fica offline, uma Web of Trust que filtra o que se propaga, e um grafo social que serve como infraestrutura de longo prazo. O BitChat cuida de "enviar uma mensagem para alguém próximo agora." O Gozzip cuida de "ser dono da sua vida social permanentemente." Juntos formam uma pilha completa do rádio Bluetooth à mídia social soberana.
O que o Scuttlebutt acertou — e onde parou
O Secure Scuttlebutt foi pioneiro na ideia de que redes sociais poderiam funcionar com gossip peer-to-peer sem servidores centralizados. O Gozzip tem uma dívida conceitual com esse trabalho. Mas as arquiteturas divergem em três pontos críticos. Primeiro, identidade: o SSB vincula feeds ed25519 a dispositivos únicos — perca o dispositivo, perca a identidade. O Gozzip usa secp256k1 com uma hierarquia de delegação, então sua chave raiz fica fria enquanto subchaves de dispositivo cuidam das operações do dia a dia. Segundo, replicação: os pub servers do SSB replicam dados unilateralmente — armazenam o que querem, para quem querem, sem obrigação nenhuma. O Gozzip impõe pactos bilaterais de armazenamento com desafios de proof-of-possession, tornando o free-riding estruturalmente impossível. Terceiro, fronteiras de gossip: o SSB não tem limite explícito de confiança — o gossip se propaga indefinidamente pela rede. O Gozzip restringe o encaminhamento a uma Web of Trust de 2 hops, prevenindo o crescimento ilimitado de dados que fez os pubs do SSB colapsarem sob seu próprio peso.
Resiliência de emergência
A integração com o BitChat também habilita o panic wipe: um gatilho configurável — toque triplo, gesto ou PIN falso — que destrói todas as chaves locais, eventos em cache e estado. Seus dados publicados sobrevivem nos parceiros de pacto e relays. Sua identidade sobrevive em armazenamento frio. A recuperação é: acessar a chave raiz, publicar uma nova delegação de dispositivo, buscar nos pares de armazenamento, e você está de volta. O modo decoy opcional limpa para um perfil inofensivo. O adversário vê um app normal com conteúdo inofensivo.
Cada protocolo resolve bem um problema difícil. O Gozzip os conecta numa pilha onde o grafo social é a infraestrutura — da identidade ao armazenamento ao transporte.
Como se compara
| Nostr | Mastodon | Gozzip | |
|---|---|---|---|
| Identity | secp256k1 keypair | user@instance (domain-bound) | secp256k1 + key hierarchy |
| Data lives on | Relay servers | Home instance (PostgreSQL) | Your device + friends' devices (~20 pact partners) |
| Who controls | Relay operators | Instance admin | You + bilateral pact partners |
| Redundancy | Manual multi-relay publishing | None - single home instance | ≈20 active pacts (floor 12), renewed by default |
| Censorship resistance | Individual relays can drop events | Admin can suspend/delete | No single point - data on 20+ WoT peers |
| Offline support | Not supported | Not supported | Store-and-forward via pact partners while you are offline |
| Read privacy | Relay sees all subscriptions | Instance admin sees all activity | Encrypted requests stay within your web-of-trust peers |
Essa arquitetura ainda precisa de alguns participantes confiavelmente online. Não são servidores públicos ou relays. São amigos rodando Gozzip num desktop, uma máquina doméstica ou um VPS pequeno. Pode ser você, com um setup multi-dispositivo onde um aparelho fica sempre ligado. A diferença dos protocolos atuais é estrutural: parceiros de pacto operam sob obrigações bilaterais com pessoas que conhecem, verificadas por challenge-response, não sob controle unilateral de um operador de plataforma. Os problemas difíceis permanecem. O bootstrap do grafo para novos usuários requer dependência inicial de relays. A rotação de chaves de DM limita a exposição, mas é rotação periódica de chaves, não sigilo avançado. Esses são desafios de engenharia, não de arquitetura.
A infraestrutura existe, mas pertence ao grafo social.
O design deste protocolo não é meramente inspirado pela dinâmica social humana — é estruturalmente isomorfo a ela.
A pesquisa de Robin Dunbar identifica camadas sociais fractais: ~5 contatos íntimos, ~15 amigos próximos, ~50 bons amigos, ~150 amigos casuais — cada camada aproximadamente triplicando em tamanho e reduzindo pela metade a intimidade. Cada primitiva do protocolo mapeia um padrão observável em como humanos formam comunidades, mantêm relacionamentos e propagam informação.
O protocolo formaliza isso como pactos de armazenamento: acordos bilaterais onde ambas as partes armazenam os eventos uma da outra, cada uma até um limite por parceiro. Não há equiparação de volume — um publicador prolífico e alguém que só lê em silêncio podem firmar um pacto livremente, porque o que mantém o relacionamento saudável é o armazenamento confiável, não a produção simétrica. A confiabilidade é a moeda; um parceiro que deixa de entregar é simplesmente substituído.
Cada nó mantém pontuações de confiabilidade por par a partir de uma janela rolante de 14 dias de resultados challenge-response — e a pontuação leva a presença em conta: um parceiro só é avaliado enquanto está de fato online, então um Witness móvel que fica quase sempre offline nunca é punido por estar dormindo. As pontuações são privadas — cada nó calcula sua própria avaliação. Não existe pontuação global de reputação. A topologia da rede é a estrutura de incentivos.
O protocolo formaliza isso como pactos de guardian: um usuário estabelecido armazena voluntariamente dados de um recém-chegado fora da sua Web of Trust. A lógica de “retribua adiante” é deliberada: a semente de hoje se torna o guardian de amanhã.
Essa variação natural se mapeia diretamente em como o protocolo distribui o armazenamento. Pares que estão online com mais frequência naturalmente armazenam mais dados e atendem mais requisições, enquanto pares com disponibilidade intermitente contribuem com o que podem. O protocolo não força ninguém a um papel — ele se adapta a como as pessoas realmente usam seus dispositivos. Assim como círculos sociais se auto-organizam em torno da disponibilidade natural de cada um, a topologia de armazenamento da rede emerge organicamente.