Découverte des noeuds et livraison chiffrée vérifiable
Comment les noeuds AeroNyx découvrent des peers signés, choisissent un chemin réseau diversifié à deux sauts, relaient un ChatRelay opaque et vérifient la livraison terminale par reçu signé.
Le 17 juillet 2026, un smoke test de production a envoyé un ChatRelay opaque d'un client authentifié depuis US1, via Korean1, jusqu'à Noway1. Le terminal l'a écrit dans le pending store et a renvoyé un reçu signé vérifié par la source. C'est une preuve limitée pour un chemin ChatRelay éligible, pas l'affirmation que tous les paquets AeroNyx utilisent onion routing.
Invariant du protocole: L'infrastructure relay ne doit recevoir ni texte clair ni clé de déchiffrement. Le middle ne traite que des route metadata bornées, proof, TTL, next hop et ciphertext opaque; le terminal reçoit uniquement le minimum requis pour store-and-forward avec le ciphertext.
Ce qui fonctionne actuellement
Peer descriptors signés, peer store persistant, gossip, reachability probes, préférence des routes avec receipt, client sessions authentifiées, terminal pending store et delivery receipts signés fonctionnent en production.
Flux de livraison authentifiée
- Le client établit une session avec Ed25519 et X25519 éphémère puis envoie
ChatRelaydans unDataPacketchiffré. La source lie sender à session identity et choisit middle/terminal diversifiés. Elle ne compte la livraison qu'après vérification d'un receipt lié à route, au payload commitment exact, au terminal attendu et à freshness.
authenticated client -> source -> middle -> terminal pending store
<- terminal-signed receipt <-
Le receipt terminal est lié au route ID, au payload commitment exact, à l'identité terminale attendue et à la fenêtre de freshness. Un receipt différent ou périmé est rejeté.
Niveaux de preuve
Trois niveaux restent séparés afin qu'un health check ne soit pas présenté comme une livraison réelle:
| Code de preuve | Signification |
|---|---|
synthetic_onion_message_delivery_probe | Probe contrôlé du chemin, pas du trafic utilisateur réel. |
opaque_relay_acceptance | Acceptation d'un relay chiffré origin-neutral; elle ne prouve pas la livraison terminale. |
verified_client_onion_delivery_receipt | Le payload authentifié a atteint le terminal attendu et la source a vérifié son reçu. |
Diversité des routes
Source, middle et terminal doivent être distincts. Même IPv4 /24, IPv6 /48 ou DNS host normalisé est refusé; un endpoint incorrect échoue fermé. La diversité ASN et propriétaire n'est pas encore implémentée.
Compatibilité inter-versions
Les routes receipt-capable sont prioritaires. Les anciens peers peuvent servir de fallback limité, mais sans receipt valide ils n'augmentent jamais verified_client_onion_deliveries et ne sont pas affichés comme livraison vérifiée.
Contrat de l'API publique
La card directe d'un noeud est disponible via GET http://<node>:8422/api/discovery/public-card, et l'agrégat privacy-safe via GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/. L'ancien segment vpn reste uniquement pour compatibilité; le produit est AeroNyx Privacy Protocol.
{
"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 confidentialité
L'API publique expose seulement readiness, compteurs et âge de preuve agrégés, jamais route ID, endpoints, clés, payloads, adresses, destinations, DNS ou social graph. Le contenu reste aveugle, mais la résistance à l'analyse globale ou l'anonymat de niveau Tor ne sont pas encore prouvés.
Limites actuelles
- La vérification couvre seulement
ChatRelayauthentifié éligible sur deux sauts, pas tous les paquets, voice ou media.verified_client_onion_deliveriesest un signal process-local réinitialisé au restart, pas un total historique ni un consensus global.
Libellés produit
Seul verified_client_onion_delivery_receipt s'affiche comme Verified client delivery; opaque_relay_acceptance comme Encrypted relay active et synthetic_onion_message_delivery_probe comme Path probe passed. Ces états ne doivent pas être fusionnés.