Descoberta de nós e entrega criptografada verificável

Em 17 de julho de 2026, um smoke test de produção enviou um ChatRelay opaco de cliente autenticado do US1, via Korean1, ao Noway1. O terminal gravou no pending store e devolveu receipt assinada validada pela origem. É evidência limitada de rota ChatRelay elegível, não uma alegação de que todo pacote AeroNyx usa onion routing.

Invariante do protocolo: A infraestrutura relay não deve receber plaintext nem chaves. O middle trata apenas route metadata limitada, proof, TTL, next hop e ciphertext opaco; o terminal recebe só os metadados mínimos de store-and-forward e ciphertext.

O que está ativo agora

Estão ativos peer descriptor assinado, peer store persistente, gossip, reachability probe, preferência por rotas com receipt, client session autenticada, terminal pending store e delivery receipt assinada.

Fluxo de entrega autenticada

O cliente cria session com Ed25519 e X25519 efêmero e envia ChatRelay em DataPacket criptografado. A origem vincula sender à session identity e escolhe middle/terminal diversos. Só conta entrega após verificar receipt vinculada à route, payload commitment exato, terminal esperado e freshness.

text

authenticated client -> source -> middle -> terminal pending store
                                  <- terminal-signed receipt <-

A receipt terminal fica vinculada ao route ID, ao payload commitment exato, à identidade terminal esperada e à janela de freshness. Uma receipt divergente ou antiga é rejeitada.

Níveis de evidência

Três níveis são separados para não apresentar health check como entrega real:

Código de evidência	Significado
`synthetic_onion_message_delivery_probe`	Probe controlado de rota; não é tráfego real de usuário.
`opaque_relay_acceptance`	Aceite de relay criptografado origin-neutral; não prova entrega terminal.
`verified_client_onion_delivery_receipt`	O payload autenticado chegou ao terminal esperado e a origem verificou a receipt.

Diversidade de rota

Source, middle e terminal devem ser distintos. Mesmo IPv4 /24, IPv6 /48 ou DNS host normalizado é recusado; endpoint inválido falha fechado. Diversidade por ASN ou operador ainda não existe.

Compatibilidade entre versões

Rotas com receipt têm prioridade. Peers antigos podem ser fallback limitado, mas sem receipt válida não aumentam verified_client_onion_deliveries nem são mostrados como entrega verificada.

Contrato da API pública

A card direta do nó está em GET http://<node>:8422/api/discovery/public-card e o agregado privacy-safe em GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/. O segmento legado vpn permanece apenas por compatibilidade; o produto é o AeroNyx Privacy Protocol.

json

{
  "real_relay_ready": true,
  "verified_client_onion_deliveries": 1,
  "verified_client_onion_delivery_age_seconds": 42,
  "message_delivery_proof_ready": true,
  "message_delivery_ready": true,
  "message_delivery_evidence_mode": "verified_client_onion_delivery_receipt"
}

Limite de privacidade

A API pública expõe apenas readiness, contagem e idade de evidência agregadas, nunca route ID, endpoints, chaves, payloads, endereços, destinos, DNS ou social graph. O conteúdo é blind, mas resistência a análise global e anonimato tipo Tor ainda não são comprovados.

Limites atuais

A verificação cobre só ChatRelay autenticado elegível em dois saltos, não todo pacote, voz ou media. verified_client_onion_deliveries é sinal process-local que zera no restart, não total histórico nem consenso global.

Texto no produto

Somente verified_client_onion_delivery_receipt aparece como Verified client delivery; opaque_relay_acceptance como Encrypted relay active e synthetic_onion_message_delivery_probe como Path probe passed. Os estados não devem ser combinados.