Arquitetura do AeroNyx App e Protocol

A AeroNyx separa um protocolo aberto e durável dos produtos que o utilizam.

O protocolo define roteamento privado, identidade e comunicação criptografadas, storage node-blind, discovery assinado, relay opaco e evidência operacional. Os produtos transformam essas regras em AeroNyx App, nós descentralizados, Nodeboard, MemChain e serviços para agentes.

Separação entre protocolo e produto

Camada	Exemplos	Responsabilidade
AeroNyx Protocol	identidade, envelopes criptografados, limites de metadata, peer descriptors, receipts e commitments MemChain	Define interoperabilidade e o que a infraestrutura pode observar
Produto do usuário	AeroNyx App para iOS, Android, macOS e Windows	Rede de privacidade, comunicação, recuperação, arquivos, consentimento wallet e IA
Infraestrutura	nós de privacidade operados independentemente	Aceita e retransmite trabalho criptografado, publica capacidades assinadas e saúde limitada
Produto do operador	Nodeboard	Capacidade, peers, incidentes, recovery e auditoria sem conteúdo do usuário
Memória privada	MemChain	Memória local-first, objetos de sync criptografados e prova append-only

Interface, preço e distribuição podem mudar. O limite do protocolo permanece estável para a interoperabilidade de implementações independentes.

Camadas de capacidade

A rede de privacidade oferece acesso criptografado escolhido pelo usuário. Mensagens diretas e de grupo usam identidades P2P e E2E. Mídia é criptografada no client e referenciada em envelopes E2E. .ayx recupera identidade. MemChain conserva memória node-blind. Discovery e relay fornecem descriptors assinados, routeability, blind forwarding e receipts. Serviços agent adicionam conectividade privada e estado verificável.

AeroNyx separa wallet identity de P2P identity. A primeira cobre ativos, membership, subscription, node ownership e consentimento; a segunda cobre contatos, chat, QR ou deep link, namespace de mensagens e recuperação social.

A separação reduz correlação e dá a cada identidade seu próprio ciclo. Girar ou apagar uma identidade social não deve destruir silenciosamente o wallet root ou outras identidades.

Mensagens criptografadas e transporte

A mensagem é criptografada no endpoint remetente e descriptografada apenas pelo receptor autorizado. O relay processa envelope opaco, identificador de rota, timestamps limitados, replay protection, rate limits e delivery state; nunca recebe as chaves.

O RelayWS central continua sendo o caminho padrão para entrega previsível e store-and-forward offline. Usuários podem escolher caminhos por nós descentralizados quando disponíveis. A AeroNyx não afirma que toda mensagem de produção já usa caminho descentralizado ou multi-hop.

Contatos são verificados por fingerprint, QR ou deep link; o banco local é isolado por identidade P2P ativa.

Mídia criptografada e arquivos retomáveis

Voz, imagens, vídeo e arquivos usam um canal blob de ciphertext. Chaves, nonces, nomes, transcrições e plaintext não entram na API.

Fluxo	API	Limite atual
Upload único	`POST /api/relay/blob/`	10 MB
Criar sessão retomável	`POST /api/relay/blob/session/`	100 MB total
Enviar ou repetir chunk	`PUT /api/relay/blob/session/{upload_id}/chunk/{index}/`	1 MB padrão, 4 MB máximo
Consultar chunks ausentes	`GET /api/relay/blob/session/{upload_id}/`	Sessão por 24 horas
Completar	`POST /api/relay/blob/session/{upload_id}/complete/`	Operação idempotente
Baixar ciphertext	`GET /api/relay/blob/{blob_id}/`	Acesso capability ou authenticated

A retenção padrão é 7 dias e o máximo é 30. Em capability mode, blob_id é uma bearer capability imprevisível; authenticated mode limita o download às P2P public keys permitidas. A referência e metadata de decriptação ficam no payload E2E.

Backup de identidade, grupos e chamadas

.ayx protege o seed com salt aleatório, chave derivada de senha e authenticated encryption. Não armazena seed em claro, e import/export são ações explícitas.

Grupos adicionam membership operations assinadas e group-key state criptografado. Voz e vídeo respeitam as mesmas identidades e limites, convertendo falhas de transporte em estados estáveis.

Invariante blind-node

Relay nodes, storage nodes e coordenadores MemChain devem ser cegos ao conteúdo. Podem tratar ciphertext, assinaturas, route state limitado, timestamps, replay guards, limites, capacidade e contadores agregados, mas não chaves de mensagens, payloads, DNS, histórico, destinos, arquivos privados, plaintext MemChain, segredos de identidade ou relações sociais estáveis.

Se o usuário enviar plaintext a uma IA externa, valem os termos daquele provedor. O invariante descreve a infraestrutura AeroNyx sem ocultar limites de terceiros.

Operação sem vigilância

Nodeboard e estatísticas mostram capacidade, política de conexão, peer freshness, routeability, restart recovery, pressão fd/conntrack, packet drops, pps, bps, proofs e entregas terminais, nunca mensagens, payloads, DNS, destinos, URL, IP pública do client, memória privada, contatos ou tráfego por wallet.

Direção do protocolo para agentes

Agentes autônomos precisam de reachability privada, mensagens criptografadas, memória controlada, credentials limitadas, consentimento auditável e transições verificáveis. AeroNyx fornece esses primitives sem impor um backend único: envelopes agent-to-agent, MemChain node-blind, routing privado opcional, nós independentes e settlement fora do privacy ledger.

Limite real da implantação

Hoje o App usa relay central por padrão. Relay descentralizado, multi-hop, full-node mirroring ampliado e diversidade de rede seguem em rollout controlado. A documentação distingue produção, opções, probes e planejamento; progresso verificável vale mais que apresentar o futuro como universal.