Architecture de l’App et du protocole AeroNyx

AeroNyx17 juin 20265 min de lecture61 vues

Comment le protocole durable AeroNyx relie l’App multiplateforme, les identités et messages chiffrés, MemChain, les nœuds de confidentialité, Nodeboard et les agents.

AeroNyx sépare un protocole ouvert et durable des produits qui l’utilisent.

Le protocole définit routage privé, identité et communication chiffrées, stockage node-blind, discovery signé, relay opaque et preuves opérationnelles. Les produits transforment ces règles en AeroNyx App, nœuds décentralisés, Nodeboard, MemChain et services pour agents.

Séparation entre protocole et produit

CoucheExemplesResponsabilité
AeroNyx Protocolidentité, envelopes chiffrés, limites metadata, peer descriptors, receipts, commitments MemChainDéfinit l’interopérabilité et ce que l’infrastructure peut observer
Produit utilisateurAeroNyx App sur iOS, Android, macOS et WindowsRéseau de confidentialité, communication, récupération, fichiers, consentement wallet et IA
Infrastructurenœuds de confidentialité exploités indépendammentAccepte et relaie le travail chiffré, publie des capacités signées et une santé limitée
Produit opérateurNodeboardCapacité, peers, incidents, reprise et audit sans contenu utilisateur
Mémoire privéeMemChainMémoire local-first, objets de synchronisation chiffrés et preuves append-only

L’interface, le prix ou la distribution d’un produit peuvent évoluer. La frontière du protocole reste stable pour permettre l’interopérabilité des implémentations indépendantes.

Couches de capacité

Le réseau de confidentialité fournit un accès chiffré choisi par l’utilisateur. La messagerie directe et de groupe utilise des identités P2P et E2E. Les media sont chiffrés côté client et référencés dans des envelopes E2E. .ayx permet la restauration d’identité. MemChain conserve une mémoire node-blind. Discovery et relay apportent descriptors signés, routeability, blind forwarding et receipts. Les services agent ajoutent connectivité privée et état vérifiable.

Identité financière et identité sociale

AeroNyx sépare wallet identity et P2P identity. La première porte actifs, abonnement, propriété de nœud et consentement de compte ; la seconde porte contacts, chat, QR ou deep link, namespace de messages et récupération sociale.

Cette séparation limite la corrélation et donne à chaque identité son cycle de récupération. La rotation d’une identité sociale ne doit pas détruire silencieusement le wallet root ou d’autres identités.

Messagerie chiffrée et transport

Le message est chiffré sur l’endpoint émetteur et déchiffré seulement par un destinataire autorisé. Le relay traite envelope opaque, identifiant de route, timestamps limités, replay protection, rate limits et état de livraison, jamais les clés.

RelayWS, opéré centralement, reste le chemin par défaut pour une livraison prévisible et le store-and-forward hors ligne. Les utilisateurs peuvent choisir des chemins par nœuds décentralisés lorsqu’ils sont disponibles. AeroNyx ne prétend pas que chaque message de production utilise déjà un chemin décentralisé ou multi-hop.

Les contacts se vérifient par fingerprint, QR ou deep link ; la base locale est isolée par identité P2P active.

Media chiffrés et fichiers reprenables

Voix, images, vidéo et fichiers utilisent un canal blob de ciphertext. Clés, nonces, noms, transcriptions et plaintext n’entrent pas dans l’API.

FluxAPILimite actuelle
Upload simplePOST /api/relay/blob/10 MB
Créer une session reprenablePOST /api/relay/blob/session/100 MB total
Envoyer ou réessayer un chunkPUT /api/relay/blob/session/{upload_id}/chunk/{index}/1 MB par défaut, 4 MB maximum
Lister les chunks manquantsGET /api/relay/blob/session/{upload_id}/Session valable 24 h
TerminerPOST /api/relay/blob/session/{upload_id}/complete/Opération idempotente
Télécharger le ciphertextGET /api/relay/blob/{blob_id}/Accès capability ou authenticated

La rétention est de 7 jours par défaut et 30 au maximum. En mode capability, blob_id est un bearer capability imprévisible ; le mode authenticated limite le téléchargement aux P2P public keys autorisées. Référence et metadata de déchiffrement restent dans le payload E2E.

Sauvegarde d’identité, groupes et appels

.ayx protège le seed par salt aléatoire, clé dérivée du mot de passe et authenticated encryption. Le seed n’existe pas en clair dans le fichier, et import/export sont des actions explicites.

Les groupes ajoutent opérations de membres signées et état de group key chiffré. Voix et vidéo respectent les mêmes identités et frontières, avec des états produit stables plutôt que des erreurs transport brutes.

Invariant blind-node

Relay nodes, storage nodes et coordinateurs MemChain doivent rester aveugles au contenu. Ils peuvent traiter ciphertext, signatures, route state limité, timestamps, replay guards, limites, capacité et compteurs agrégés, mais jamais les clés de messages, payloads, DNS, historique, destinations, fichiers privés, plaintext MemChain, secrets d’identité ou relations sociales stables.

Si l’utilisateur transmet du plaintext à une IA externe, les conditions de ce fournisseur s’appliquent. L’invariant décrit l’infrastructure AeroNyx sans masquer la frontière des tiers.

Exploitation sans surveillance

Nodeboard et les statistiques peuvent afficher capacité, politiques de connexion, fraîcheur des peers, routeability, restart recovery, pression fd/conntrack, packet drops, pps, bps, proofs et livraisons terminales.

Ils ne deviennent pas des visualiseurs de trafic exposant messages, payloads, DNS, destinations, URL, IP publique du client, mémoire privée, contacts ou trafic par wallet.

Direction du protocole pour agents

Les agents autonomes ont besoin de reachability privée, messages chiffrés, mémoire contrôlée, credentials limités, consentement auditable et transitions vérifiables. AeroNyx fournit ces primitives sans imposer un backend unique : envelopes agent-to-agent, MemChain node-blind, routage privé optionnel, nœuds indépendants et settlement hors du ledger de confidentialité.

Frontière réelle du déploiement

L’App utilise aujourd’hui le relay central par défaut. Relay décentralisé, multi-hop, full-node mirroring étendu et diversité réseau restent en déploiement contrôlé. Les docs distinguent production, options, probes et capacités prévues : une progression vérifiable vaut mieux qu’un futur présenté comme universel.

À lire ensuite