Ein QR-Code. Oder eine Datei, die durch Licht geht.

Durch eine simulierte Kamerakette, bei 10 Bildern pro Sekunde, mit Codes, die den größten Teil des Bildes bei 3-5 Kamera-Pixeln pro Modul füllen, kamen alle vier Konfigurationen mit verifiziertem Hash heraus: Schwarzweiß auf einem Streifen 15,8 KB/s, Schwarzweiß auf vier Streifen 37,7 KB/s, Farbe auf einem Streifen 40,1 KB/s, Farbe auf vier Streifen 115,7 KB/s. Farbe auf einem einzigen Streifen schlägt Schwarzweiß auf vier. Die Fehlerrate war überall null. Merken Sie sich, woher die Zahlen kommen: geometrisch perfekte Frames, ohne Objektiv und ohne Bewegung. Ein echtes Telefon wurde ihnen noch nicht vorgehalten.

Die Kamera wird mit 1920x1080 bei 30 Bildern pro Sekunde verlangt, mit Bevorzugung der Rückkamera; wenn Android die Einschränkung ablehnt, fallen wir auf irgendeine Kamera zurück. Jeder erfasste Frame wird vor der Decodierung auf 1280 px an der langen Seite reduziert. Entscheidend ist nicht die Auflösung, sondern wie viele Sensorpixel auf ein Modul fallen: Schwarzweiß braucht ungefähr drei, Farbe ungefähr doppelt so viele, weil die Videokette des Telefons gewöhnlich 4:2:0 liefert und beide Farbebenen in beide Richtungen halbiert. Feine Farbdetails sind das Erste, was eine echte Kamera zerstört.

Weil das einzige, was das sendende Gerät messen kann, ist, wie viele Symbole seine eigenen Kodierer im Vergleich zu den angeforderten erzeugt haben — eine Aussage über einen Prozessor, nicht über eine Kamera zwei Handbreit entfernt. Ein Laptop verpasst nie eine Stufe, also fährt ein Controller, der „null Fehlraten“ als „weitermachen“ liest, bis ganz nach oben und zeigt vier Codes auf dem Bildschirm an, die sich dreißig Mal pro Sekunde ändern und von nichts gescannt werden können. Das wurde tatsächlich einmal ausgeliefert, und ein Mensch hat es innerhalb einer Minute gefunden. Jetzt ist der Automatikmodus auf einen Streifen, Schwarzweiß, Version 26 und 15 Bilder pro Sekunde begrenzt. 15 ist keine runde Zahl: Eine Telefonkamera zeichnet bei 30 auf und ist nicht mit dem Bildschirm synchronisiert, also muss ein Frame zwei aufeinanderfolgende Belichtungen lang angezeigt werden — 67 ms — damit er vollständig erfasst wird.

Nichts Besonderes, und genau das ist der Sinn. Es gibt keine Sequenznummern, die wiederhergestellt werden müssten. Der Kodierer erzeugt Reparaturpakete im Verhältnis 2x zu den Quell-Symbolen — gemessen an diesem Code: Bei 60% Frameverlust stellt ein Satz von ungefähr 2x K 2 MB wieder her, ohne dass die Liste jemals ein zweites Mal abgespielt wird. Das absolute Limit sind 60.000 Pakete; darüber hinaus spielt der Sender die Liste einfach öfter erneut ab, was Zeit kostet, nicht Speicher. Wenn trotzdem etwas schiefgeht, fängt der SHA-256-Hash das ab, und der Transfer schlägt ausdrücklich fehl, statt eine beschädigte Datei zu liefern.

Nein, und das ist kein Versäumnis. Es gibt keinen Rückkanal — ein Bildschirm sendet Licht, und Licht kehrt nicht mit Bestätigungen zurück. Der Abschluss wird auf dem empfangenden Gerät sichtbar. Jede Oberfläche, die etwas anderes behaupten würde, würde lügen, und wir hatten bereits einmal einen Test, der genau diesen Beweis lieferte, den das Produkt nie hat: Die Simulation berechnete ihre Fehlerrate aus dem, was die simulierte Kamera tatsächlich auflösen konnte. Das ist ein Rückkanal. Wenn ein Test und der ausgelieferte Code sich darüber nicht einig sind, was gewusst werden kann, ist der Test derjenige, der lügt.

32 MB, bei der Auswahl abgelehnt, wenn sie größer ist. Das Limit kommt nicht vom Protokoll, sondern aus dem Speicher eines Browser-Tabs: RaptorQ materialisiert alle Pakete auf einmal, und eine 50-MB-Datei bei 2x-Rate würde 150 MB lebende Arrays bedeuten, genug, um den Tab eines Telefons zu töten. Die Kodierung läuft synchron auf dem Hauptthread und wurde auf 2,5 Sekunden für 32 MB auf dem Computer gemessen. Was tatsächlich übertragen wird, ist nicht die Dateigröße: Der Umschlag wird vor RaptorQ mit gzip komprimiert, also ist eine 1-MB-Tabelle nur wenige Kilobyte Pakete, und ein 1-MB-Foto ist ein Megabyte Pakete.

Weder noch. Es gibt kein Konto und kein Abonnement. Nach dem ersten Besuch funktionieren die Seiten ohne Netzwerk, weil alles — einschließlich der beiden WebAssembly-Binaries — von der eigenen Domain ausgeliefert wird. Es lohnt sich auch zu sagen, was wir unterwegs gelernt haben: Ein registrierter Service Worker bedeutet nicht Offline-Support. Beim ersten Laden werden die Seite und ihre Ressourcen geladen, bevor der Worker die Kontrolle übernimmt, also sieht sein Handler sie nie. Die Seite meldet ihre eigenen Ressourcen über die Performance API, statt etwas anzunehmen.