Un codice QR. O un file che passa attraverso la luce.

Attraverso una catena di camera simulata, a 10 frame al secondo, con i codici che riempiono la maggior parte dell’immagine a 3-5 pixel di camera per modulo, tutte e quattro le configurazioni sono risultate con hash verificato: bianco e nero su una banda 15,8 KB/s, bianco e nero su quattro bande 37,7 KB/s, colore su una banda 40,1 KB/s, colore su quattro bande 115,7 KB/s. Il colore su una sola banda batte il bianco e nero su quattro. Il tasso di errore è stato zero ovunque. Tenga presente da dove arrivano le cifre: frame geometrici perfetti, senza obiettivo e senza movimento. Un telefono vero non è ancora stato messo davanti a loro.

La camera è richiesta a 1920x1080 a 30 frame al secondo, con preferenza per quella posteriore; se Android rifiuta il vincolo, si passa a qualsiasi camera. Ogni frame acquisito viene ridotto a 1280 px sul lato lungo prima della decodifica. Ciò che conta davvero non è la risoluzione, ma quanti pixel del sensore cadono su un modulo: il bianco e nero ha bisogno di circa tre, il colore di circa il doppio, perché la catena video del telefono di solito fornisce 4:2:0 e dimezza entrambi i piani di colore in entrambe le direzioni. Il dettaglio fine di colore è la prima cosa che una camera reale distrugge.

Perché l’unica cosa che il dispositivo che invia può misurare è quanti simboli hanno prodotto i propri codificatori rispetto a quanti ne sono stati richiesti — un’affermazione su un processore, non su una camera a due palmi di distanza. Un laptop non perde mai un gradino, quindi un controller che legge «zero errori» come «continua» sale fino in cima e mette sullo schermo quattro codici che cambiano trenta volte al secondo, che nulla può scansionare. Questo è stato davvero consegnato una volta e una persona l’ha trovato in un minuto. Ora la modalità automatica è plafonata a una banda, bianco e nero, versione 26 e 15 frame al secondo. 15 non è un numero tondo: una camera di telefono registra a 30 e non è sincronizzata con lo schermo, quindi un frame deve rimanere visualizzato per due esposizioni consecutive — 67 ms — per essere catturato interamente.

Niente di speciale, ed è proprio il punto. Non esistono numeri d’ordine da recuperare. Il codificatore produce pacchetti di riparazione in proporzione di 2x rispetto ai simboli sorgente — misurato su questo codice: al 60% di perdita di frame, un set di circa 2x K recupera 2 MB senza che la lista venga mai riprodotta una seconda volta. Il limite assoluto è 60.000 pacchetti; oltre questo il mittente semplicemente ripete la lista più spesso, il che costa tempo, non memoria. Se comunque qualcosa va storto, l’hash SHA-256 lo intercetta e il trasferimento fallisce dichiaratamente invece di consegnare un file corrotto.

No, e non è una svista. Non esiste un canale di ritorno: uno schermo emette luce, e la luce non torna indietro con conferme. Il completamento si vede sul dispositivo che riceve. Qualsiasi interfaccia che pretendesse altro mentirebbe, e abbiamo già avuto una volta un test che offriva esattamente questa prova che il prodotto non ha mai: la simulazione calcolava il proprio tasso di mancato riconoscimento da ciò che la camera simulata riusciva a risolvere. Quello è un canale di ritorno. Quando un test e il codice consegnato non concordano su ciò che si può sapere, è il test a mentire.

32 MB, rifiutato alla selezione se è più grande. Il limite non deriva dal protocollo, ma dalla memoria di una scheda del browser: RaptorQ materializza tutti i pacchetti in una volta, e un file da 50 MB con rapporto 2x significherebbe 150 MB di array vivi, abbastanza da uccidere la scheda di un telefono. La codifica gira in modo sincrono sul thread principale, misurata a 2,5 secondi per 32 MB su computer. Ciò che viaggia effettivamente non è la dimensione del file: il contenuto è compresso con gzip prima di RaptorQ, quindi una tabella da 1 MB è pochi kilobyte di pacchetti, e una fotografia da 1 MB è un megabyte di pacchetti.

Né l’uno né l’altro. Non esiste un account e non esiste un abbonamento. Dopo la prima visita le pagine funzionano senza rete, perché tutto — inclusi i due binari WebAssembly — viene servito dal proprio dominio. Vale la pena dire anche che cosa abbiamo imparato lungo il percorso: un service worker registrato non significa supporto offline. Al primo caricamento la pagina e le sue risorse vengono recuperate prima che il worker prenda il controllo, quindi il suo handler non le vede mai. La pagina segnala le proprie risorse tramite Performance API invece di presumere.