Descubrimiento de nodos y entrega cifrada verificable
Cómo los nodos AeroNyx descubren peers firmados, eligen rutas de dos saltos con diversidad de red, retransmiten ChatRelay opaco y verifican la entrega terminal mediante recibos firmados.
El 17 de julio de 2026, una prueba de producción envió un ChatRelay opaco de un cliente autenticado desde US1, pasando por Korean1, hasta Noway1. El terminal lo guardó en pending store y devolvió un recibo firmado que verificó el origen. Es evidencia limitada de una ruta ChatRelay elegible, no una afirmación de que todo paquete AeroNyx use onion routing.
Invariante del protocolo: La infraestructura relay no debe recibir texto claro ni claves. El nodo intermedio solo maneja route metadata limitada, proof, TTL, next hop y ciphertext opaco; el terminal recibe únicamente los metadatos mínimos de store-and-forward y el ciphertext.
Qué funciona actualmente
Están activos descriptor de peer firmado, peer store persistente, gossip, probes de alcance, preferencia por rutas con receipt, sesiones de cliente autenticadas, pending store terminal y recibos firmados.
Flujo de entrega autenticada
- El cliente establece sesión con Ed25519 y X25519 efímero y envía
ChatRelaydentro deDataPacketcifrado. El origen vincula sender con session identity y elige middle/terminal diversos. Solo cuenta la entrega cuando verifica un recibo ligado a route, payload commitment exacto, terminal esperado y freshness.
authenticated client -> source -> middle -> terminal pending store
<- terminal-signed receipt <-
El recibo terminal está vinculado al route ID, al payload commitment exacto, a la identidad terminal esperada y a la ventana de freshness. Un recibo distinto o caduco se rechaza.
Niveles de evidencia
Se separan tres niveles para no presentar un health check como entrega real:
| Código de evidencia | Significado |
|---|---|
synthetic_onion_message_delivery_probe | Probe controlado de ruta; no es tráfico real de usuario. |
opaque_relay_acceptance | Aceptación de relay cifrado origin-neutral; no prueba entrega terminal. |
verified_client_onion_delivery_receipt | El payload autenticado llegó al terminal esperado y el origen verificó su recibo. |
Diversidad de ruta
Origen, middle y terminal deben ser distintos. Se rechazan el mismo IPv4 /24, IPv6 /48 o DNS host normalizado; endpoints inválidos fallan de forma cerrada. Aún no existe diversidad por ASN o propietario.
Compatibilidad entre versiones
Se prefieren rutas compatibles con receipt. Peers antiguos pueden ser fallback limitado, pero sin receipt válido nunca aumentan verified_client_onion_deliveries ni se muestran como entrega verificada.
Contrato de API pública
La card directa del nodo se obtiene con GET http://<node>:8422/api/discovery/public-card y el agregado privacy-safe con GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/. El segmento vpn se conserva solo por compatibilidad; el producto es 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"
}
Límite de privacidad
La API pública solo expone readiness, conteos y antigüedad de evidencia agregados; no route ID, endpoints, claves, payloads, direcciones, destinos, DNS ni grafo social. El contenido es ciego, pero aún no se prueba resistencia al análisis global ni anonimato tipo Tor.
Límites actuales
- La verificación solo cubre
ChatRelayautenticado y elegible en dos saltos; no todo paquete, voz o media.verified_client_onion_deliverieses una señal process-local que se reinicia con el nodo, no un total histórico ni consenso global.
Texto de producto
Solo verified_client_onion_delivery_receipt se muestra como Verified client delivery; opaque_relay_acceptance como Encrypted relay active y synthetic_onion_message_delivery_probe como Path probe passed. No deben fusionarse.