Um código QR. Ou um ficheiro que passa pela luz.

Numa cadeia de câmara simulada, a 10 frames por segundo, com os códigos a preencher a maior parte da imagem a 3-5 pixels de câmara por módulo, as quatro configurações saíram com hash verificado: preto e branco numa banda 15,8 KB/s, preto e branco em quatro bandas 37,7 KB/s, cor numa banda 40,1 KB/s, cor em quatro bandas 115,7 KB/s. A cor numa só banda bate o preto e branco em quatro. A taxa de falha foi zero em todo o lado. Repare de onde vêm os números: frames geométricos perfeitos, sem objetiva e sem movimento. Um telemóvel verdadeiro ainda não foi colocado à frente deles.

A câmara é pedida a 1920x1080 a 30 frames por segundo, com preferência pela traseira; se o Android recusar a restrição, caímos em qualquer câmara. Cada frame capturado é reduzido a 1280 px no lado longo antes da decodificação. O que conta verdadeiramente não é a resolução, mas quantos pixels do sensor caem num módulo: o preto e branco precisa de aproximadamente três, a cor de aproximadamente o dobro, porque a cadeia de vídeo do telemóvel normalmente entrega 4:2:0 e reduz pela metade ambos os planos de cor em ambas as direções. O detalhe fino de cor é a primeira coisa que uma câmara real destrói.

Porque a única coisa que o dispositivo que envia consegue medir é quantos símbolos produziram os seus próprios codificadores face a quantos lhe foram pedidos — uma afirmação sobre um processador, não sobre uma câmara a dois palmos. Um portátil nunca falha um degrau, por isso um controlador que lê “zero falhas” como “continua” sobe até ao topo e põe no ecrã quatro códigos que mudam trinta vezes por segundo, que nada consegue escanear. Isso foi mesmo entregue uma vez e uma pessoa encontrou-o num minuto. Agora o modo automático está limitado a uma banda, preto e branco, versão 26 e 15 frames por segundo. 15 não é um número redondo: uma câmara de telemóvel grava a 30 e não está sincronizada com o ecrã, por isso um frame tem de ficar exibido duas exposições consecutivas — 67 ms — para ser apanhado por inteiro.

Nada de especial, e é esse o ponto. Não existem números de ordem para recuperar. O codificador produz pacotes de reparação na proporção de 2x face aos símbolos de origem — medido neste código: a 60% de perda de frames, um conjunto de cerca de 2x K recupera 2 MB sem que a lista seja reproduzida uma segunda vez. O teto absoluto é 60.000 pacotes; acima disso, o remetente simplesmente retoma a lista com mais frequência, o que custa tempo, não memória. Se, ainda assim, algo correr mal, o hash SHA-256 deteta isso e a transferência falha de forma declarada em vez de entregar um ficheiro corrompido.

Não, e não é uma falha. Não existe canal de retorno — um ecrã emite luz, e a luz não volta com confirmações. A conclusão vê-se no dispositivo que recebe. Qualquer interface que afirmasse o contrário estaria a mentir, e já tivemos uma vez um teste que oferecia exatamente essa prova que o produto nunca tem: a simulação calculava a sua taxa de falha a partir do que a câmara simulada conseguia resolver. Esse é um canal de retorno. Quando um teste e o código entregue não concordam sobre o que pode ser sabido, o teste é que mente.

32 MB, rejeitado na seleção se for maior. O limite não vem do protocolo, mas da memória de um separador do navegador: o RaptorQ materializa todos os pacotes de uma vez, e um ficheiro de 50 MB com rácio 2x implicaria 150 MB de matrizes vivas, suficiente para matar o separador de um telefone. A codificação corre de forma síncrona no thread principal, medida em 2,5 segundos para 32 MB no computador. O que viaja efetivamente não é o tamanho do ficheiro: o envelope é comprimido com gzip antes do RaptorQ, por isso uma tabela de 1 MB é apenas alguns kilobytes de pacotes, e uma fotografia de 1 MB é um megabyte de pacotes.

Nem uma coisa nem a outra. Não existe conta e não existe assinatura. Depois da primeira visita, as páginas funcionam sem rede, porque tudo — incluindo os dois binários WebAssembly — é servido do próprio domínio. Vale também dizer o que aprendemos pelo caminho: um service worker registado não significa suporte offline. No primeiro carregamento, a página e os respetivos recursos são trazidos antes de o worker assumir o controlo, por isso o seu handler nunca os vê. A página reporta os seus próprios recursos através da Performance API em vez de assumir.