Un navigateur, un émetteur Rust et un iPhone
Un service Rust local reçoit du texte ou un fichier, découpe les octets en blocs et crée les trames du protocole. Le navigateur les affiche dans une séquence animée de codes QR standards. Sur l’iPhone, Vision d’iOS décode les images de la caméra; un récepteur Swift valide les trames binaires et reconstitue les données. Le navigateur sert à l’affichage, tandis que le service Rust génère le transfert.
Pourquoi utiliser des codes fontaine?
Une caméra ne capte pas chaque code affiché. L’émetteur transmet d’abord les blocs sources, puis des symboles de réparation LT déterministes qui combinent des blocs par XOR. Le récepteur résout ces équations pour récupérer les blocs manquants à partir d’un nombre suffisant de symboles utiles, sans attendre le retour d’une image précise. La correction QR intervient dans chaque image; les codes fontaine compensent les pertes dans la séquence. Il faut tout de même assez de données valides et indépendantes pour terminer.
Reconstituer, puis vérifier avant d’ouvrir
Le récepteur vérifie la structure des trames, la session et le CRC32, rejette les trames endommagées ou incompatibles et ignore les symboles en double. Après avoir récupéré les blocs sources, il réassemble les octets et compare leur empreinte SHA-256 à celle du manifeste. Seul le contenu vérifié s’affiche : le texte et les images prises en charge directement, les vidéos dans le lecteur système. Ces contrôles détectent la corruption, mais ne prouvent pas à eux seuls l’identité de l’expéditeur.
Ce qui a été testé
Le 20 octobre 2026, 41 tests Rust ont réussi pour le protocole, l’émetteur en ligne de commande, la bibliothèque d’images QR et le simulateur de canal. Ils couvrent les trames déterministes, la récupération par codes fontaine, les pertes, le désordre, les doublons, le rejet de données corrompues, l’authentification, la vérification de l’empreinte complète et le décodage indépendant d’images QR. Des vecteurs de référence communs définissent la concordance entre Rust et Swift. La vidéo fournie montre une reconstitution, une vérification et une lecture réussies sur iPhone. C’est une démonstration, pas une mesure reproductible du débit.
Les limites actuelles du prototype
La mise au point, l’éclairage, le rafraîchissement de l’écran, la densité QR et la taille du fichier influencent la durée et la réussite du transfert. Le transfert vidéo peut être lent. Nous ne présentons ici aucun débit physique général ni taille maximale démontrée. La limite de 64 Mio du protocole est une limite logicielle, pas un résultat de transfert vérifié par caméra. L’authentification HMAC facultative à clé partagée ne chiffre pas les données et n’empêche pas de rejouer une session valide complète. Il s’agit d’un prototype d’ingénierie fonctionnel, pas d’un service de transfert en production.