Decimen streamt QR-Codes mit nahezu 190 KB/s ohne Netzwerk

Tom Hardware hat ein Browser-Experiment hervorgehoben, das Dateien Berichten zufolge mit nahezu 190 KB/s über sich schnell ändernde QR-Codes zwischen Smartphones überträgt. Die Übertragung benötigt weder ein gemeinsames Netzwerk noch Bluetooth-Pairing, eine spezielle App oder ein Konto. Ein Gerät zeigt die Daten an, während das andere sie über seine Kamera erfasst.

Diese Kombination erzeugt die eigentliche Spannung. Herkömmliche Smartphone-Übertragungen bieten deutlich höhere Geschwindigkeiten, hängen jedoch von Funkverbindungen, Betriebssystemdiensten, Berechtigungen für Geräte in der Nähe oder Cloud-Infrastruktur ab. Decimen Optical Transfer ersetzt diese Abhängigkeiten durch einen optischen Kanal, den Nutzer sehen können.

Das Projekt bleibt ein Proof of Concept und ist kein direkter AirDrop-Ersatz. Die berichtete Leistung stammt zudem aus Entwicklertests unter günstigen Bedingungen. Dennoch zeigt das Experiment, dass Bildschirme und Kameras einen praktischen lokalen Datenpfad bilden können, wenn normale Konnektivität nicht verfügbar, eingeschränkt oder unerwünscht ist.

Tom Hardware ordnet die Behauptung zur optischen Übertragung ein

Das wichtige Ergebnis ist nicht, dass QR-Codes Dateien aufnehmen können. Es ist, dass ein Browser genug davon streamen kann, um eine nutzbare Einwegverbindung zu schaffen.

Entwickler bashalarmistalt veröffentlichte Decimen Optical Transfer als Open-Source-Demonstration. Laut dem Projekt zeigt ein Browser eine endlose Folge codierter Frames an. Ein zweiter Browser liest diese Frames über seine Kamera und rekonstruiert die Originaldatei.

Die ursprüngliche Berichterstattung wurde am 31. Juli 2026 veröffentlicht. Sie berichtete von ungefähr 128 KB/s bei freihändig gehaltenen Smartphone-zu-Smartphone-Übertragungen. Eine stabile Positionierung beider Geräte erhöhte die Rate Berichten zufolge auf rund 186 KB/s.

Diese Werte sind Entwicklermessungen und kein unabhängiger Labor-Benchmark. Die Position der Geräte ist wichtig, weil Bewegungen den Autofokus suchen lassen und einzelne Frames verwischen. Die Projektdokumentation bezeichnet Handzittern als größtes Durchsatzproblem.

Der Entwickler sagt, die Idee sei beim Bau eines zwischengespeicherten webbasierten Musikplayers entstanden. Er wollte Audiodateien zwischen Smartphones übertragen, die nicht mit demselben Netzwerk verbunden waren. Schnell blinkende QR-Codes lieferten einen Kanal, bei dem keines der Telefone das andere erkennen musste.

Über diesen Pfad wird mehr als ein Download-Link übertragen. Die binären Inhalte der ausgewählten Datei werden aufgeteilt, codiert, angezeigt, erfasst und auf dem empfangenden Gerät wieder zusammengesetzt. Die Nutzdaten selbst gelangen über sichtbares Licht zwischen Bildschirm und Kamera.

Der veröffentlichte Proof of Concept nutzt eine konservativere Konfiguration als das übergeordnete Experiment. Er kann ein 512-KB-Bild oder ein auswählbares 2-MB-Bild übertragen. Das Repository beschreibt eine Übertragung mit 129 KB/s während einer Demonstration.

Die höhere berichtete Obergrenze ergab sich aus dichteren QR-Frames, gestapelten Codes und einem fehlerkorrigierten Farbkanal. Der Entwickler verwendete für diese Tests ein 120-Hz-ProMotion-Display. Die berichtete Leistung erreichte etwa 128 KB/s freihändig und 186 KB/s, wenn die Geräte stillstanden.

Dieser Unterschied ist wichtig. Die Zahl in der Überschrift beschreibt das beste Ergebnis des umfassenderen Experiments, während der öffentliche Proof of Concept eine einfachere Erfassung bevorzugt. Leser sollten nicht davon ausgehen, dass jede Kombination aus Smartphone und Browser sofort 186 KB/s reproduzieren kann.

Dennoch verändert selbst die niedrigere Rate, wie dieser Ansatz eingeordnet werden sollte. Ein einzelner statischer QR-Code ist normalerweise eine Abkürzung zum Öffnen einer Website oder zum Import kleiner Anmeldedaten. Decimen macht QR zu einem kontinuierlichen Transportmedium.

Ein 2-MB-Bild bei 129 KB/s benötigt ungefähr die Zeit, die man bei einer kurzen lokalen Übergabe erwarten würde, nicht bei einem Archiv-Upload. Große Videos blieben unpraktisch. Dokumente, Audioclips, Konfigurationspakete, Zugangsdaten und Notfalldateien passen natürlicher zu diesem Kanal.

Das Projekt ist außerdem bewusst nur in eine Richtung ausgelegt. Der Empfänger sendet keine Bestätigungen, handelt keine Verbindung aus und offenbart dem Sender seine Identität nicht. Das vereinfacht die Einrichtung, schafft aber das technische Problem, das das gesamte System bestimmt.

Wenn eine empfangende Kamera einen herkömmlichen nummerierten Datenblock verpasst, weiß der Sender nicht, dass er ihn wiederholen muss. Decimen löst dieses Problem mit Fountain Codes statt mit einem netzwerkähnlichen Neuübertragungsprotokoll.

Fountain Codes machen aus verpassten Frames Verzögerung statt Fehler

Decimen funktioniert, weil der Empfänger nicht jeden QR-Frame und nicht einmal die ursprüngliche Übertragungsreihenfolge benötigt.

Der Sender teilt eine Datei zunächst in Quellblöcke auf. Anschließend erzeugt er einen fortlaufenden Vorrat codierter Blöcke, von denen jeder eine pseudozufällige Teilmenge der Quelldaten kombiniert. Der Empfänger sammelt genug unterschiedliche Kombinationen, um die Datei wiederherzustellen.

Diese Technik ist als Fountain Code bekannt. Der Name beschreibt das Verhalten des Empfängers: Er kann codierte Daten wie Tropfen sammeln, bis genug davon vorhanden ist, um die Quelle zu rekonstruieren. Ein bestimmter Tropfen muss nicht zu einem bestimmten Zeitpunkt eintreffen.

Decimen verwendet Luby-Transform-Codierung, ein frühes praktisches Fountain-Code-Design. Die Teilmenge für jeden Frame wird anhand seiner Sequenznummer mithilfe einer robusten Soliton-Verteilung abgeleitet. Der Empfänger benötigt Berichten zufolge etwa das 1,15-Fache der ursprünglichen Blockanzahl, bevor die Wiederherstellung möglich ist.

Ein verlorener QR-Frame kostet daher Zeit, nicht Korrektheit. Der Empfänger kann verschwommene, doppelte oder unlesbare Bilder ignorieren und spätere Frames weiter sammeln. Diese Eigenschaft macht das System gut geeignet für einen optischen Kanal ohne Rückweg.

Das Projekt-Repository erklärt, dass jeder Frame einen 20-Byte-Header enthält. Dieser Header identifiziert Sitzung, Sequenznummer, Blockanzahl, Blockgröße, Dateilänge und Dateihash.

Selbstbeschreibende Frames ermöglichen es dem Empfänger, einem aktiven Stream beizutreten, nachdem die Übertragung bereits begonnen hat. Ein Neustart des Senders erstellt eine neue Sitzungskennung, die dem Empfänger signalisiert, sich automatisch zurückzusetzen. Ein Pairing-Austausch ist nicht erforderlich.

Der Hash bietet der empfangenden Seite eine Möglichkeit, die rekonstruierte Datei zu überprüfen. Er garantiert nicht, dass der Sender vertrauenswürdig ist, kann aber ein Ergebnis erkennen, das von den übertragenen Nutzdaten abweicht.

Dieser Mechanismus unterscheidet sich davon, nummerierte Datenblöcke einfach in einer Schleife anzuzeigen. Bei sequenzieller Wiedergabe kann ein fehlender Frame den Empfänger zwingen, auf die Wiederholung der gesamten Sequenz zu warten. Längere Dateien führen zu längeren Wiederherstellungsverzögerungen.

Fountain Coding erzeugt stattdessen weiterhin nützliche Kombinationen. Der Sender muss nicht wissen, welche Symbole angekommen sind, und der Empfänger muss keine fehlenden anfordern. Damit entfällt der Rückkanal, den man normalerweise bei zuverlässigen Übertragungsprotokollen erwartet.

Das Konzept geht diesem Projekt voraus. Das TXQR-Experiment von 2018 kombinierte ebenfalls animierte QR-Codes mit Fountain Coding. Die qram-Bibliothek von Digital Bazaar untersuchte später LT-codierte QR-Streams zur Übertragung beliebiger Daten über ein verlustbehaftetes Medium.

Decimens Beitrag liegt darin, die Idee auf aktuelle Smartphone-Displays, Kameras, Browser-APIs und WebAssembly zuzuschneiden. WebAssembly, häufig als WASM abgekürzt, ermöglicht Browsern die Ausführung kompilierten Codes mit nahezu nativer Geschwindigkeit.

Der Empfänger verwendet einen WASM-Build von ZXing-C++, einer etablierten Bibliothek zum Decodieren von Barcodes. Kameraframes werden auf Worker verteilt, sodass mehrere Decodierungsaufgaben ausgeführt werden können, ohne die zentrale Browseroberfläche zu blockieren.

Ausgelastete Worker können überschüssige Kameraframes einfach verwerfen. Auf einem normalen sequenziellen Kanal würde dieses Verhalten die Übertragung gefährden. Hier fängt die Fountain-Schicht diese Verluste ab und lässt die nächsten lesbaren Symbole die Rekonstruktion voranbringen.

Die Implementierung behandelt außerdem ein weniger sichtbares Kompatibilitätsproblem. JavaScript-Engines garantieren nicht für jede mathematische Funktion bitidentische Näherungen. Eine kleine Abweichung in der Fountain-Verteilung könnte dazu führen, dass zwei Browser für dieselbe Sequenznummer unterschiedliche Quellblöcke auswählen.

Das Projekt enthält daher einen deterministischen Logarithmus, der auf explizit definierten IEEE-754-Operationen basiert. Dadurch bleiben V8-basierte Browser und Safaris JavaScriptCore abgestimmt, wenn sie dieselbe Verteilung erzeugen.

Dieses Detail zeigt, warum das Etikett „nur im Browser“ nicht mit einem einfachen Webseiten-Trick verwechselt werden sollte. Die Seite koordiniert Kameraerfassung, parallele Decodierung, deterministische Codierung, Sitzungsverwaltung und Hash-Verifizierung. Sie ist praktisch ein Transport-Stack, der auf sichtbaren Bildern aufbaut.

Das Ergebnis erklärt auch, warum eine schnellere QR-Erzeugung allein keine schnellere Dateiübertragung garantiert. Der Sender muss jeden Frame lange genug anzeigen, damit die Kamera ein sauberes Bild erfassen kann. Der Empfänger benötigt dann genug Verarbeitungskapazität, um ihn zu decodieren, bevor sich seine Worker-Warteschlange füllt.

Bildschirmaktualisierung, Kamera-Belichtung, Autofokus, Browser-Scheduling und Decodierungsgeschwindigkeit bestimmen alle die endgültige Rate. Fountain Coding kann diese Einschränkungen nicht beseitigen. Es verhindert, dass ihre unvermeidlichen Verluste die Übertragung unterbrechen.

Der eigentliche Gegner ist der Verbindungsaufbau, nicht die AirDrop-Geschwindigkeit

Bei der Rohbandbreite verliert die optische Übertragung deutlich, doch sie umgeht die Erkennungs- und Vertrauensschritte funkbasierter Alternativen.

AirDrop, Quick Share, Bluetooth, Wi-Fi Direct, WebRTC, Messaging-Apps und Cloud-Laufwerke können Dateien alle schneller übertragen. Sie sind jedoch der falsche Leistungsmaßstab, wenn das zentrale Problem darin besteht, dass zwei Geräte keinen herkömmlichen Übertragungsweg herstellen können.

Apple und Google arbeiten seit Jahren daran, die sichtbare Reibung beim Teilen in der Nähe zu reduzieren. Ihre Systeme setzen weiterhin Betriebssystemunterstützung, kompatible Geräte, Funkverbindungen, Erkennungsdienste und vom Nutzer genehmigten Zugriff voraus.

Ein Webdienst kann WebRTC für direkte Browserkommunikation nutzen, doch die Peers benötigen in der Regel Signalisierung, bevor sie sich verbinden können. Netzwerkrichtlinien, inkompatible Routen oder restriktive Firewalls können diesen Prozess erschweren.

Decimen umgeht die Erkennung vollständig. Der Sender zeigt Informationen öffentlich sichtbar an, und jeder kompatible Empfänger innerhalb optischer Reichweite kann sie sammeln. Keines der Geräte benötigt die Adresse oder Identität des anderen.

Dieses Modell passt zu beschädigten oder isolierten Geräten. Ein Smartphone kann einen funktionierenden Bildschirm und Browser haben, selbst wenn seine Mobilfunk-, Wi-Fi-, Bluetooth- oder Kabelverbindung nicht verfügbar ist. Falls seine Kamera weiterhin funktioniert, kann es auch einen optischen Stream empfangen.

Air-Gap-Systeme bieten ein weiteres potenzielles Einsatzgebiet. Eine Air Gap trennt ein Gerät von gewöhnlichen Kommunikationsnetzwerken, um die Angriffsfläche zu verringern. Administratoren benötigen dennoch kontrollierte Methoden, um Updates, Logs, Schlüssel oder andere Dateien über diese Grenze zu bewegen.

QR-Streams werden bereits in einigen Offline-Signatur- und Sicherheitsworkflows verwendet, weil der Kanal beobachtbar ist. Ein Nutzer kann sehen, wann Daten die Grenze überschreiten, auch wenn die visuelle Wahrnehmung nicht verrät, ob die Nutzdaten selbst sicher sind.

Der Browseransatz senkt die Bereitstellungsreibung, weil keine spezielle Installation erforderlich ist. Der Nutzer erteilt der empfangenden Seite Kamerazugriff, während der Sender nur ein Display benötigt.

Diese Aussage erfordert eine Einschränkung. Die Browserseite muss zunächst auf dem Gerät verfügbar sein. Decimen kann für die spätere Nutzung zwischengespeichert werden, doch der erste Zugriff benötigt normalerweise einen Server, einen lokalen Entwicklungs-Host oder einen anderen Installationsweg.

Auch der Kamerazugriff erfordert einen sicheren Browserkontext. Das Projekt verwendet während der Entwicklung HTTPS, weil Browser getUserMedia, die Schnittstelle für den Kamerazugriff, auf unsicheren Remote-Ursprüngen in der Regel blockieren.

Safari stellt eine zusätzliche Implementierungshürde dar, weil es die von einigen browserbasierten QR-Tools verwendete BarcodeDetector-Schnittstelle noch nicht ausgeliefert hat. Das entsprechende WebKit-Issue bleibt Teil der Kompatibilitätserklärung des Projekts.

Decimen schließt diese Lücke, indem es seinen eigenen ZXing-Decoder über WASM mitbringt. Dieses Design verbessert die browserübergreifende Kontrolle, fügt jedoch auch Code und Verarbeitungsaufwand hinzu, die ein nativer Plattformdienst möglicherweise vermeiden könnte.

Das System bietet in einem eng gefassten technischen Sinne Datenschutzvorteile. Laut dem Entwickler bleiben Dateiinhalte innerhalb der beiden Browser und passieren keinen Upload-Server. Der Sender erhält keine Informationen darüber, wer den Stream empfangen hat.

Optische Übertragung ist jedoch nicht automatisch privat. Jeder mit einer geeigneten Kamera und freier Sicht auf den Bildschirm kann versuchen, dieselben Daten zu empfangen. Der aktuelle Kanal verhält sich eher wie eine sichtbare Übertragung als wie eine vertrauliche, gekoppelte Verbindung.

Sensible Übertragungen müssten vor der Kodierung verschlüsselt werden. Die öffentliche Dokumentation konzentriert sich auf zuverlässigen Transport und Dateiprüfung, nicht auf ein vollständiges System für Identität, Autorisierung oder Schlüsselverwaltung.

Der Sender kann zudem nicht bestätigen, dass der vorgesehene Empfänger die Übertragung abgeschlossen hat. Es gibt keinen Bestätigungskanal. Nutzer müssen sich auf visuelle Abstimmung oder eine separate Methode verlassen, um den Abschluss zu bestätigen.

Diese Einschränkungen sind für das zentrale Versprechen des Projekts akzeptabel. Es versucht nicht, jeden Netzwerk-Stack zu ersetzen. Es schafft einen Ausweichweg, wenn der Aufbau einer Verbindung das größere Hindernis ist.

Diese Unterscheidung ordnet das Ergebnis von Tom Hardware ein. Fast 190 KB/s sind im Vergleich zu Wi-Fi unspektakulär, für eine berechtigungsarme optische Verbindung aus Browser-Bausteinen jedoch überraschend. Das Experiment tauscht Bandbreitenfülle gegen Unabhängigkeit von Netzwerkinfrastruktur.

Was das Ergebnis von 186 KB/s nicht beweist

Die Spitzenrate ist ein vielversprechender technischer Messwert, aber kein Beleg für verlässliche Leistung über gewöhnliche Telefone und Umgebungen hinweg.

Der Entwickler nennt physische Stabilität als wichtige Variable. Ein stationärer Empfänger erreichte Berichten zufolge annähernd 186 KB/s, während der Betrieb aus der Hand bei etwa 128 KB/s blieb. Allein diese Differenz zeigt, wie stark Bewegung den Kanal beeinflusst.

Der Autofokus kann sich verschieben, während sich die Hände eines Nutzers bewegen. Rolling-Shutter-Sensoren erfassen möglicherweise einen Teil eines Displayframes und einen Teil des nächsten. Reflexionen, geringe Helligkeit, Blickwinkel, Bildschirmskalierung und Umgebungslicht können den Kontrast verringern.

Bildraten von Kamera und Display bringen eine weitere Komplikation mit sich. Der Empfänger kann 60 FPS anfordern, aber nur 30 FPS erhalten. Das Projekt weist darauf hin, dass iOS bei einer idealen Anfrage stillschweigend eine niedrigere Rate liefern kann.

Als Abhilfe wird, wo unterstützt, eine exakte Rate angefordert und anschließend die Einstellungen des Kamera-Tracks geprüft. Doch auch dieser Ansatz kann nicht dafür sorgen, dass nicht unterstützte Hardware zusätzliche Frames liefert.

Der Proof of Concept nutzt standardmäßig 24 übertragene Frames pro Sekunde. Dadurch erhält jedes QR-Bild auf einem typischen Display mindestens zwei Aktualisierungszyklen, was die Wahrscheinlichkeit erhöht, dass eine Kamera es sauber erfasst.

Jeder Standardframe trägt 1.465 Payload-Bytes mit einem QR-Code der Version 27. Dichtere Frames der Version 40 können laut Repository bei Smartphone-Tests aus kurzer Entfernung 2.953 Bytes tragen.

Ein dichterer Code ist in der Praxis nicht immer schneller. Kleinere visuelle Module sind für Kameras schwieriger aufzulösen, insbesondere bei Bewegung oder unvollständigem Fokus. Ein Frame, der doppelt so viele Daten trägt, ist wenig wert, wenn der Decoder ihn verwirft.

Der Sender kann Bildrate, Bytes pro Frame, Fehlerkorrekturstufe und Anzeigegröße anpassen. Der Empfänger kann Aufnahmebreite, Kamerarate und Anzahl der Decoding-Worker einstellen. Diese Regler zeigen, dass das Projekt seine Leistungsentscheidungen noch nicht auf ein universelles automatisches Profil reduziert hat.

Die QR-Fehlerkorrektur ist in der dokumentierten Konfiguration auf Stufe L eingestellt, der niedrigsten Standardstufe. Diese Wahl lässt innerhalb jedes Bildes mehr Platz für Daten.

Fountain-Code und QR-Fehlerkorrektur adressieren unterschiedliche Fehlerarten. Die QR-Korrektur versucht, Beschädigungen innerhalb eines erfassten Symbols zu reparieren. Die Fountain-Schicht behandelt Symbole, die nie dekodiert wurden.

Decimen bevorzugt das Verwerfen fehlerhafter Frames und das Erzeugen weiterer Fountain-Symbole. Diese Entscheidung ist sinnvoll, wenn saubere Frames häufig eintreffen, aber bei schlechter Beleuchtung könnte ein anderes Gleichgewicht vorteilhafter sein.

Die gemeldete Rate schließt zudem breitere Workflow-Kosten aus. Ein Nutzer benötigt weiterhin beide vorbereiteten Seiten, passende Berechtigungen, gute Ausrichtung und ausreichend freien Speicher, um die rekonstruierte Datei zu halten. Bei einer kleinen Übertragung können diese Schritte das Erlebnis dominieren.

Große Dateien stellen ein anderes Problem dar. Bei 186 KB/s bleibt die Übertragung von Hunderten Megabyte langwierig. Dauerhafte Kameranutzung, maximale Bildschirmhelligkeit und kontinuierliches Dekodieren verbrauchen Akku und erzeugen Wärme.

Browser können Hintergrundarbeit aussetzen oder unter Druck Speicher zurückfordern. Mobile Betriebssysteme können das Kameraverhalten außerdem je nach Gerät und Version verändern. Ein Produktivtool würde umfangreiche Kompatibilitätstests benötigen.

Sicherheit verdient dieselbe Vorsicht. Ein korrekter Hash bestätigt, dass die empfangenen Bytes den übertragenen Bytes entsprechen. Er belegt nicht, wer sie erstellt hat oder ob sie schädliche Inhalte enthalten.

Eine Seite mit automatischen Downloads muss Dateinamen, MIME-Metadaten, Dateigrößen und rekonstruierte Puffer als nicht vertrauenswürdige Eingaben behandeln. Der Open-Source-Status des Projekts erleichtert die Prüfung, ersetzt jedoch keine formale Sicherheitsbewertung.

Das Repository präsentiert den Code derzeit als minimalen Proof of Concept. Seine kurze Historie und begrenzte Testpopulation machen weitreichende Zuverlässigkeitsaussagen verfrüht. Das Schlagzeilenergebnis wurde nicht unabhängig über eine veröffentlichte Gerätematrix hinweg reproduziert.

Das Projekt bietet zudem keinen inhärenten Schutz gegen Shoulder Surfing. Ein Beobachter in der Nähe kann das Display aufzeichnen und den Stream später dekodieren, sofern die Payload nicht zuvor verschlüsselt wurde.

Dieses Risiko wirkt in beide Richtungen bei Air-Gap-Anwendungen. Ein sichtbarer optischer Kanal kann leichter zu überwachen sein als eine unsichtbare Funkverbindung. Er kann jedoch auch zu jeder Kamera mit Sichtlinie durchsickern.

Das fehlende Pairing reduziert Reibung, weil der Sender Empfänger nicht authentifiziert. Dieselbe Eigenschaft beseitigt die Zugriffskontrolle auf der Transportschicht.

Keiner dieser Punkte entwertet das Experiment. Sie definieren seine tatsächliche Leistung. Decimen zeigt, dass browserbasierter optischer Transport unter ausgewählten Bedingungen nützliche Geschwindigkeiten erreichen kann, während Produktzuverlässigkeit, automatische Abstimmung und sicheres Sitzungsdesign ungelöst bleiben.

Frühere QR-Projekte zeigen sowohl die Chance als auch die Grenze

Decimen gehört zu einer längeren Reihe optischer Übertragungsexperimente, doch bessere Smartphone-Hardware macht die alte Idee praktischer.

Animierte QR-Übertragung tauchte in Forschungsprojekten, Open-Source-Bibliotheken, Kryptowallets und Air-Gap-Signaturtools auf. Diese Systeme teilen eine grundlegende Beobachtung: Eine Folge maschinenlesbarer Bilder kann weit mehr Daten übertragen als ein einzelnes statisches Symbol.

Frühere Projekte nutzten häufig sequenzielle Chunks. Das ist leicht zu implementieren, aber ein verpasstes Symbol kann den Abschluss verzögern, bis sich die Sequenz wiederholt. Fountain-Codes machten den Kanal toleranter gegenüber Verlusten und Empfang in falscher Reihenfolge.

TXQR kombinierte 2018 animierte QR-Codes und Fountain-Coding in Go. Die qram-Bibliothek von Digital Bazaar verwendete LT-Codes, um beliebige Daten in wiederholte QR-Pakete zu verpacken. Beide legten einen Großteil der konzeptionellen Grundlage für Decimen.

Andere Implementierungen verzichten vollständig auf Standard-QR. Libcimbar nutzt benutzerdefinierte farbige visuelle Codes, die für eine höhere optische Dichte ausgelegt sind. Spezialisierte Formate können mehr Informationen in einer Bildschirmfläche unterbringen, verlieren jedoch die ausgereifte Erkennungssoftware rund um Standard-QR.

Dieser Kompromiss ist auf Smartphones wichtig. QR-Dekodierung profitiert von jahrzehntelanger Arbeit an Erkennung, Perspektivkorrektur, beschädigten Symbolen und wechselnden Lichtverhältnissen. Ein benutzerdefiniertes Farbsystem muss diese Probleme lösen und gleichzeitig Weißabgleich und Farbverarbeitung der Kamera bewältigen.

RaptorQR stellt einen weiteren aktuellen Ansatz dar. Sein Entwickler berichtet von einer Übertragung von 6,5 MB in 36 Sekunden beziehungsweise 183,6 KB/s mit einem iPhone 16 und Safari. Es kombiniert RaptorQ-Coding, WASM-Rendering und ZXing-Scanning.

RaptorQ ist ein standardisierter Fountain-Code, beschrieben in RFC 6330. Sein Design zielt auf effiziente Wiederherstellung bei Paketverlusten mit geringem Overhead. Decimen dokumentiert stattdessen eine LT-Code-Implementierung mit einer robusten Soliton-Verteilung.

Diese Projekte sollten nicht als kontrollierte Direktvergleiche behandelt werden. Sie verwenden unterschiedliche Payloads, Codelayouts, Geräte, Bildraten und Testbedingungen. Ihre ähnlichen Raten deuten dennoch darauf hin, dass smartphonebasierte optische Übertragung einen praktischen Leistungsbereich erreicht hat.

Community-Experimente zeigen ebenfalls den verbleibenden Abstand zu gewöhnlichem Networking. Entwickler, die an browserbasierter QR-Übertragung arbeiten, beschrieben Wi-Fi- und WebRTC-Pfade mit Geschwindigkeiten von mehreren Megabyte pro Sekunde. Optische Übertragung bleibt im Allgemeinen bei einigen Hundert Kilobyte pro Sekunde.

Der Vergleich unterstreicht den richtigen Gegner. Es geht nicht um einen Bandbreitenwettbewerb gegen lokales drahtloses Teilen. Es ist ein Wettbewerb gegen Verbindungsfehler, nicht verfügbare Funkverbindungen, inkompatible Plattformen und Richtlinien, die gewöhnliches Networking untersagen.

Standardbasierte QR-Codes verschaffen Decimen zudem einen Bereitstellungsvorteil. Das Projekt kann sich auf vertraute visuelle Marker und etablierte Dekodierungsbibliotheken stützen. Nutzer benötigen keine spezielle Kamerahardware.

Moderne Smartphones verbessern nahezu jeden Teil der Pipeline. Displays mit hoher Bildwiederholrate können mehr Symbole darstellen. Bessere Kameras lösen dichtere Codes auf. Schnellere Mobilprozessoren dekodieren mehr Frames parallel. Browser-WASM-Unterstützung bringt optimierte native Bibliotheken in eine Webseite.

Diese Verbesserungen erklären, warum ein altes Konzept ein neues Ergebnis liefern kann. Die zugrunde liegende Informationstheorie hat sich nicht verändert. Consumer-Hardware hat einen Punkt erreicht, an dem die vollständige optische Pipeline interaktiv laufen kann.

KI-gestützte Entwicklung beeinflusste auch den Implementierungsprozess. Der Entwickler sagt, Claude Code habe beim Aufbau des funktionierenden Proof of Concept geholfen. Das ist interessant, aber gegenüber den im Repository sichtbaren, verifizierten Designentscheidungen zweitrangig.

KI hat weder Fountain-Codes, QR-Erkennung, WASM noch Browser-Kameraaufnahme erfunden. Sie half einem Entwickler, diese Komponenten schnell um ein konkretes persönliches Problem herum zu kombinieren.

Dieses Muster wird in experimenteller Software zunehmend üblich. Entwickler können Standards, Bibliotheken und Geräte-APIs zu schlanken Prototypen zusammensetzen, bevor ein konventionelles Produktteam die Arbeit rechtfertigen würde.

Der entstandene Code benötigt weiterhin menschliche Prüfung, Hardwaretests, Bedrohungsanalyse und Wartung. Der Wert von Decimen liegt in dem System, das es offenlegt, nicht darin, KI-generierten Code automatisch für zuverlässig zu halten.

Tom-Hardware-Leser sollten das Projekt daher als Beleg für einen reifenden Weg betrachten, nicht als einzelnen isolierten Stunt. Mehrere Teams konvergieren auf Fountain-kodierte optische Übertragung, weil aktuelle Geräte sie endlich mit nützlichen Raten ausführen können.

Drei Signale werden entscheiden, ob optische Übertragung das Labor verlässt

Der nächste Test besteht darin, ob Decimen eine günstige Demonstration in wiederholbares Verhalten über Smartphones, Browser und reale Umgebungen hinweg verwandeln kann.

Das erste Signal ist ein unabhängiger Kompatibilitätsbenchmark. Das Projekt benötigt Ergebnisse über aktuelle iPhones, Android-Smartphones, Tablets und Laptops hinweg, wobei sowohl Sende- als auch Empfangsrollen getestet werden.

Ein nützlicher Benchmark würde Betrieb aus der Hand und stationären Betrieb getrennt ausweisen. Er sollte tatsächliche Kameraeinstellungen, Display-Bildwiederholraten, Abstand, Beleuchtung, Payload-Größe, fehlgeschlagene Versuche und dauerhaften Durchsatz berichten.

Eine Reproduktion von annähernd 186 KB/s über mehrere Geräte hinweg würde die zentrale Leistungsbehauptung stärken. Große Schwankungen oder häufige Übertragungsfehler würden zeigen, dass optische Bedingungen weiterhin das Softwaredesign dominieren.

Das zweite Signal ist die automatische Abstimmung. Ein produktionsreifer Empfänger sollte seine Kamerarate und Decodierkapazität messen und dem Sender mitteilen, welche Dichte und Wiedergabegeschwindigkeit zuverlässig funktionieren.

Decimen verzichtet derzeit auf einen Rückkanal, sodass diese Koordination eine Designentscheidung erfordern würde. Der Empfänger könnte dem Sender einen kleinen Steuerungs-QR-Code anzeigen, oder Nutzer könnten ein erkanntes Profil manuell auswählen.

Ein bidirektionaler visueller Modus würde Bestätigungen, Flusskontrolle und die Aushandlung von Fähigkeiten hinzufügen. Gleichzeitig würde er das zentrale Versprechen einer einfachen Einwegübertragung verkomplizieren.

Das Projekt benötigt keine Duplexübertragung, um nützlich zu bleiben. Automatische Profile würden jedoch fehlgeschlagene Versuche reduzieren und die Leistung weniger von Experteneinstellungen abhängig machen.

Das dritte Signal ist ein Sicherheitsmodell für echte Dateien. Verschlüsselung, Senderauthentifizierung, Nutzlastgrenzen, sichere Download-Verarbeitung und klare Sitzungsindikatoren würden das Konzept über eine technische Demonstration hinausführen.

Die Verschlüsselung sollte vor der Fountain-Codierung erfolgen, damit aufgezeichnete Frames ohne Schlüssel keine verwertbaren Dateidaten preisgeben. Die Authentifizierung würde Empfängern helfen zu bestätigen, dass eine rekonstruierte Nutzlast vom erwarteten Sender stammt.

Diese Ergänzungen müssen den Hauptvorteil des Kanals bewahren. Wenn die sichere Einrichtung Konten, Cloud-Dienste oder umfangreiches Pairing erfordert, beginnt die optische Übertragung, genau die Abhängigkeiten nachzubilden, die sie vermeiden sollte.

Das überzeugendste Ergebnis wären optionale Sicherheitsmodi. Unkomplizierte Übertragungen könnten unmittelbar bleiben, während sensible Arbeitsabläufe vorab geteilte Schlüssel oder kurze visuelle Verifizierungscodes nutzen könnten.

Entwickler sollten auch das Kameraverhalten von Browsern im Blick behalten. Ein besserer Zugriff auf Bildratensteuerungen und native Barcode-Erkennung würde die Implementierung vereinfachen. Rückschritte bei der mobilen Planung oder Kamerabeschränkungen könnten den gegenteiligen Effekt haben.

Für gewöhnliche Nutzer ist die unmittelbare Frage einfacher: Wann wäre dies besser als ein bestehendes Freigabetool? Die Antwort lautet: wenn das übliche Tool keinen Übertragungsweg herstellen kann, inakzeptable Zugriffsrechte verlangt oder von fehlender Infrastruktur abhängt.

Dazu gehören isolierte Geräte, defekte WLAN-Hardware, plattformübergreifende Wiederherstellung, überwachte Air-Gap-Übertragungen, Klassenzimmer mit eingeschränkten Netzwerken und Eins-zu-viele-Übertragungen von einem großen Display.

Die Methode eignet sich weiterhin schlecht für große Backups oder das routinemäßige Teilen von Videos. Sie erfordert außerdem Vorsicht bei vertraulichen Daten, da jeder innerhalb der Kamerareichweite einen unverschlüsselten Stream beobachten kann.

Tom’s Hardware hat einen glaubwürdigen Beleg dafür geliefert, dass Smartphone-Bildschirme und -Kameras mehr als Links und Zahlungstoken unterstützen können. Das Ergebnis von nahezu 190 KB/s muss nun breiter reproduziert, einfacher abgestimmt und um eine definierte Sicherheitsschicht ergänzt werden.

Bewerten Sie die Idee anhand ihres vorgesehenen Ausfallfalls. Wenn WLAN, Bluetooth, Kabel und Cloud-Dienste verschwänden: Würde ein sichtbarer Browserkanal Ihnen helfen, eine wichtige Datei wiederherzustellen? Die Antwort darauf wird entscheiden, ob streamende QR-Codes ein interessantes Experiment bleiben oder zu einem standardmäßigen Notfallweg zwischen Geräten werden.