Un código QR. O un archivo que pasa por la luz.

A través de una cadena de cámara simulada, a 10 fotogramas por segundo, con los códigos llenando la mayor parte de la imagen a 3-5 píxeles de cámara por módulo, las cuatro configuraciones salieron con hash verificado: blanco y negro en una banda 15,8 KB/s, blanco y negro en cuatro bandas 37,7 KB/s, color en una banda 40,1 KB/s, color en cuatro bandas 115,7 KB/s. El color en una sola banda supera al blanco y negro en cuatro. La tasa de fallos fue cero en todas partes. Ten en cuenta de dónde salen las cifras: fotogramas geométricos perfectos, sin objetivo y sin movimiento. Un teléfono real aún no se ha puesto delante de ellos.

Se exige a la cámara 1920x1080 a 30 fotogramas por segundo, con preferencia por la trasera; si Android rechaza la restricción, se cae a cualquier cámara. Cada fotograma capturado se reduce a 1280 px en el lado largo antes de la decodificación. Lo que realmente importa no es la resolución, sino cuántos píxeles de sensor caen sobre un módulo: el blanco y negro necesita aproximadamente tres, el color aproximadamente el doble, porque la cadena de vídeo del teléfono normalmente entrega 4:2:0 y reduce a la mitad ambos planos de color en ambas direcciones. El detalle fino de color es lo primero que una cámara real destruye.

Porque lo único que el dispositivo que envía puede medir es cuántos símbolos han producido sus propios codificadores frente a cuántos se le pidieron —una afirmación sobre un procesador, no sobre una cámara a dos palmos. Un portátil nunca pierde un escalón, así que un controlador que lee «cero fallos» como «sigue» sube hasta arriba y pone en pantalla cuatro códigos que cambian treinta veces por segundo, que nada puede escanear. Eso sí se entregó una vez y una persona lo encontró en un minuto. Ahora el modo automático está limitado a una banda, blanco y negro, versión 26 y 15 fotogramas por segundo. 15 no es una cifra redonda: una cámara de teléfono registra a 30 y no está sincronizada con la pantalla, así que un fotograma debe permanecer mostrado dos exposiciones consecutivas —67 ms— para ser captado entero.

Nada especial, y ese es precisamente el punto. No hay números de orden que recuperar. El codificador produce paquetes de reparación en una proporción de 2x respecto a los símbolos fuente — medido en este código: con 60% de pérdida de frames, un conjunto de aproximadamente 2x K recupera 2 MB sin que la lista se reproduzca nunca por segunda vez. El límite absoluto es de 60.000 paquetes; por encima de él, el remitente simplemente reinicia la lista más a menudo, lo que cuesta tiempo, no memoria. Si aun así algo sale mal, el hash SHA-256 lo detecta y la transferencia falla de forma declarada en lugar de entregar un archivo corrupto.

No, y no es una omisión. No existe canal de retorno: una pantalla emite luz, y la luz no vuelve con confirmaciones. La finalización se ve en el dispositivo que recibe. Cualquier interfaz que dijera lo contrario mentiría, y ya tuvimos una vez una prueba que ofrecía exactamente esa evidencia que el producto nunca tiene: la simulación calculaba su tasa de fallos a partir de lo que la cámara simulada conseguía resolver. Ese es un canal de retorno. Cuando una prueba y el código entregado no coinciden sobre lo que se puede saber, la prueba es la que miente.

32 MB, rechazado en la selección si es mayor. El límite no viene del protocolo, sino de la memoria de una pestaña del navegador: RaptorQ materializa todos los paquetes de una vez, y un archivo de 50 MB con relación 2x implicaría 150 MB de tablas vivas, suficiente como para matar la pestaña de un teléfono. La codificación se ejecuta de forma síncrona en el hilo principal, medida en 2,5 segundos para 32 MB en el ordenador. Lo que viaja realmente no es el tamaño del archivo: el sobre se comprime con gzip antes de RaptorQ, así que una tabla de 1 MB son unos pocos kilobytes de paquetes, y una fotografía de 1 MB es un megabyte de paquetes.

Ni una cosa ni la otra. No hay cuenta y no hay suscripción. Después de la primera visita las páginas funcionan sin red, porque todo —incluidos los dos binarios WebAssembly— se sirve desde su propio dominio. También vale la pena decir lo que hemos aprendido en el camino: un service worker registrado no significa soporte offline. En la primera carga la página y sus recursos se traen antes de que el worker tome el control, así que su handler nunca los ve. La página reporta sus propios recursos mediante la Performance API en lugar de suponer.