Arquitetura do App AeroNyx e do protocolo

AeroNyx17 de junho de 20262 min de leitura

Esta página explica em português do Brasil o papel de “Arquitetura do App AeroNyx e do protocolo” no protocolo aberto de privacidade AeroNyx, o escopo atual, os invariantes de privacidade e os cuidados de desenvolvimento e operação.

Arquitetura do App AeroNyx e do protocolo

“Arquitetura do App AeroNyx e do protocolo” é uma página localizada oficial da documentação AeroNyx. AeroNyx separa a camada de protocolo da experiência de produto: o protocolo fornece capacidades abertas e resilientes, enquanto App, nodeboard, chat criptografado, armazenamento criptografado e operação de nós compõem a experiência do usuário.

Visão geral

Esta página explica em português do Brasil o papel de “Arquitetura do App AeroNyx e do protocolo” no protocolo aberto de privacidade AeroNyx, o escopo atual, os invariantes de privacidade e os cuidados de desenvolvimento e operação.

Papel na arquitetura AeroNyx

Este tema pertence a Introdução. O ponto central é entender AeroNyx não como um único serviço centralizado, mas como um conjunto de capacidades de protocolo compartilhadas por clientes, nós Rust, coordenadores backend e nodeboard.

Pontos atuais de implementação

  • Toda capacidade relacionada a conteúdo do usuário deve trafegar como criptografia ponta a ponta ou objeto criptografado.
  • Nós Rust podem reportar saúde, capacidade, conexões, provas de rota e estatísticas agregadas, mas não podem ler mensagens, credenciais ou segredos do usuário.
  • nodeboard oferece observabilidade operacional: saúde do nó, peer discovery, recuperação após reinício, capacidade, pacotes/tráfego e estado do protocolo.
  • Na fase atual o backend coordena, ordena, agrega e expõe APIs públicas de documentação; algumas responsabilidades podem migrar depois para a camada Rust.

Limite de privacidade

O invariante central da AeroNyx é o blind-node invariant: nós de relay e coordenadores Memory Chain lidam apenas com ciphertext, timestamps, provas, sinais agregados de saúde e metadados limitados de roteamento. Eles não devem ler texto claro, DNS, destinos ou reconstruir relações sociais.

O que operadores devem acompanhar

Operadores devem acompanhar largura de banda, limites de conexão, pool de IP, conntrack, descritores de arquivo, packet drops, pps, bps, peer store, frescor de heartbeat e restart recovery. A interface deve ajudar no diagnóstico sem expor conteúdo de usuário ou dados vinculáveis.

Integração para desenvolvedores e produtos

Clientes, App, AI agents e serviços externos devem reutilizar envelopes criptografados, assinaturas, blind relay, credenciais anônimas e healthchecks da AeroNyx. Toda nova API deve separar metadados públicos de campos que permanecem dentro do E2E payload.

Estado atual

Esta página descreve a fronteira pública atual do protocolo e produto AeroNyx. multi-hop routing, blind-signed vouchers, encrypted media blob, sincronização Memory Chain e melhorias de node discovery devem continuar sob o mesmo translation_key.