DIG: begrenzter Gopher-Client und lokale Workbench

Der Abstand zwischen Protokollskizze und brauchbarem Client.

Die frühere Oberfläche konnte ein Gopher-Menü veranschaulichen, belegte aber nicht die entscheidenden Teile: wie ein Selector als Bytes auf dem Socket landet, wo Text-Framing endet oder was geschieht, wenn ein Server hängt, einen falschen Typ meldet oder Binärdaten zurückgibt.

Version 3.2.0 behält den begrenzten Node.js-Pfad für CLI und Gateway und ergänzt nativen Android-Transport für direkte mobile Nutzung. Die Browserausgabe ist installierbar und offline-sicher; Pages bleibt auf Fixtures beschränkt, weil Browser-JavaScript keine rohen TCP-Sockets öffnen kann.

Regeln, die die Implementierung nicht verwischen darf.

Das Protokoll ist einfach; die Vertrauensgrenze ist es nicht:

Die RFC-4266-Auswertung muss Selector und Suche erhalten, während RFC-1436-Framing, Textabschluss, Dot-Stuffing und Binärtypen getrennte Übertragungs- und Ausgaberegeln behalten.
Jeder Netzwerkzugriff benötigt Gesamtfrist, Idle-Timeout, Anfragegrenze, Antwortgrenze und eine Obergrenze für Menüeinträge.
Gehostete Abrufe müssen bei privaten, Loopback- oder gemischten DNS-Antworten geschlossen scheitern und sich ohne erneute Auflösung mit der geprüften Adresse verbinden.
Nicht vertrauenswürdiger Text darf das Terminal nicht steuern, und Binärantworten dürfen weder dekodiert noch wie Text ausgegeben werden.

Ein lokales Gateway, kein offener Proxy.

Ein frei erreichbarer HTTP-Proxy hinter dem Explorer wäre bequem und gleichzeitig ein SSRF-Dienst. DIG hält das Gateway deshalb beim Benutzer, akzeptiert API-Aufrufe nur von seiner eigenen Browser-Origin und gewährt anderen Sites keinen CORS-Zugriff.

Der Hosted-Modus wird ausdrücklich gewählt. Er verlangt ein Token, blockiert private Ziele und bindet das geprüfte DNS-Ergebnis an die TCP-Verbindung. Lokaler Zugriff auf private Adressen existiert nur hinter einem ausdrücklichen Flag und einer sichtbaren Warnung.

Zwei begrenzte Transporte, vier ehrliche Oberflächen.

CLI und lokaler Explorer teilen Node.js-Zielrichtlinie, gepinntes TCP und Parser. Android setzt dieselben öffentlichen Ziel- und Antwortgrenzen nativ um und reicht typisierte Bytes an den paketierten Explorer. PWA und Pages bleiben ohne authentifiziertes Gateway beim Offline-Fixture.

Jede Oberfläche nennt, ob ihre Bytes aus direktem TCP, Same-Origin-Gateway oder Offline-Fixture stammen.

Warum diese Technologien.

Der Stack bringt Gopher in den Browser, ohne das Projekt in einen öffentlichen Proxy zu verwandeln.

Warum: Der Browser kann keine rohen Gopher-Sockets öffnen; das Gateway wendet Auflösung, Zielrichtlinie, Timeouts und Größenlimits vor der Verbindung an.
Was ich ausgeschlossen habe: Ein allgemeiner oder entfernter Proxy böte eine weit größere SSRF- und Relay-Oberfläche, als das Protokoll benötigt.
Der Preis dafür: Wir nehmen einen lokalen Node-Prozess und den bewussten Verzicht auf beliebige Protokolle in Kauf.

Warum: Der Explorer kann das Gateway unter derselben Herkunft nutzen, während Anfragen und Antworten engen Verträgen folgen.
Was ich ausgeschlossen habe: Ein öffentlicher Cross-Origin-Proxy könnte für Scans, Zugriffe auf private Netze oder nicht vorgesehenen Verkehr missbraucht werden.
Der Preis dafür: Wir nehmen in Kauf, dass die öffentliche Site nur Fixtures zeigt und Live-Zugriff eine lokale Installation erfordert.

Warum: Gopher überträgt Text, Menüs und Binärdaten; unveränderte Bytes verhindern beschädigte Downloads oder Protokollterminatoren.
Was ich ausgeschlossen habe: Alles vorab zu dekodieren würde einen Zeichensatz erzwingen, Binärdaten beschädigen und Inhalt mit Transport verwechseln können.
Der Preis dafür: Wir nehmen aufwendigere Puffer, Typmetadaten und ausdrückliche Grenzen in Kauf.

Warum: Der paketierte Explorer öffnet begrenzte TCP-Verbindungen und hält seine UI-Assets im APK; die Richtlinie bietet keinen Override für private Netze.
Was ich ausgeschlossen habe: Eine eingebettete Hosted-Site bliebe vom Gateway abhängig, und eine installierte PWA erhält keine rohen Socket-Rechte.
Der Preis dafür: Wir nehmen eine Kotlin-Grenze, Android-SDK, Signierung und Paritätstests mit der Node.js-Richtlinie in Kauf.

Entscheidungen, die die Grenze sichtbar machen.

Jede Oberfläche sagt klar, was sie erreichen und was sie speichern kann.

D01

Einmal auflösen und genau das geprüfte Ziel verwenden

Die Hosted-Richtlinie verwirft den gesamten Hostnamen, sobald eine DNS-Antwort nicht öffentlich ist. Eine erfolgreiche Auflösung gibt exakt die Adresse zurück, die der TCP-Client verwendet, und schließt damit die Lücke zwischen Prüfung und Verbindung.

Der ZielkonfliktDie strikte Ablehnung gemischter Antworten kann ungewöhnliche, legitime DNS-Konfigurationen blockieren; sie ist sicherer, als die Absicht eines Angreifers zu erraten.

D02

Demo- und Live-Modus sichtbar unterscheiden

Der öffentliche Modus kennzeichnet, dass er ausschließlich mit enthaltenen Fixtures navigiert. Live-Gopher erscheint als eigener Modus und benötigt das lokale oder bewusst betriebene Hosted-Gateway.

Der ZielkonfliktPages öffnet keine echten Ressourcen, aber Benutzer verwechseln eine statische Demo nicht mit einem verbundenen Client.

D03

Downloads atomar abschließen

Die CLI schreibt im Zielverzeichnis in eine temporäre Datei und macht den endgültigen Pfad erst nach erfolgreichem Abschluss sichtbar; Fehler oder Abbruch hinterlassen keinen scheinbar gültigen Download.

Der ZielkonfliktDafür sind temporärer Speicher und ein finaler Commit-Schritt nötig, doch Verbraucher sehen Teildateien nicht als vollständige Ergebnisse.

Wie Version 3.2.0 geprüft wird.

Die 102 Node.js-Tests decken RFC-Parsing, TCP-Fixtures, Netzrichtlinie, HTTP-Vertrag, atomare Ausgabe, PWA-Zustand, Android-Bundle und Release-Verträge ab. 15 Playwright-Abläufe prüfen Chromium und mobiles WebKit einschließlich Live-Navigation und Offline-Erholung.

Android CI kompiliert und lintet das native Projekt, führt Unit-Tests aus und prüft die paketierten Assets. Das Gate kontrolliert außerdem deterministische Archive, Abhängigkeiten, Container-Smoke-Test und den Vertrag des signierten APK.

Was heute funktioniert.

Im Terminal oder in der Android-App lassen sich reale Menüs, Texte, Suche und gängige Binärtypen abrufen. Der lokale Browser ergänzt Verlauf, Lesezeichen, Suche, Rohdatenprüfung, JSON-Export und Download über das Gateway; die installierte PWA hält das Fixture offline bereit.

DIG macht aus Gopher kein HTTP. Der Verkehr zum Gopher-Server bleibt unverschlüsselt, Pages ruft keine Live-Ressourcen ab, und Gopher+, TLS, Telnet-Sitzungen sowie rekursives Crawling bleiben außerhalb des unterstützten Vertrags.

Evidenzprotokoll.

Die Aussagen zu Version 3.2.0 sind an ausführbare Prüfungen und sichtbare Grenzen gebunden:

Verifikation: Der geprüfte Quellstand besteht 102 Node.js-Tests und 15 Browserabläufe in Chromium und mobilem WebKit; ein Skip ist bewusst plattformspezifisch.
Android: Die Capacitor-8-App unterstützt Android 7/API 24 und neuer, zielt auf API 36 und verwendet direkten nativen TCP-Transport statt die gehostete Site zu laden.
Netzrichtlinie: Der Hosted-Modus verlangt ein Zugriffstoken, verwirft einen Hostnamen, sobald eine DNS-Antwort nicht öffentlich ist, und verbindet sich nur mit der bereits geprüften Adresse.
Ausgabeintegrität: Die CLI schreibt über eine temporäre Datei im selben Verzeichnis und macht den Zielpfad atomar sichtbar; binäre Bytes gelangen nie in ein interaktives Terminal.
Offline-Grenze: Die PWA speichert statische Shell und geprüftes Fixture, nie API-Antworten. Nach der Rückkehr ins Netz wird nur eine zuvor aktive Gateway-Sitzung fortgesetzt.

Geprüftes Release v3.2.0 Geprüft am 29. Juli 2026

Was dieser Fall belegt

Diese Fallstudie beschreibt Version 3.2.0: RFC-1436-Framing, RFC-4266-URLs und Suche, Binärtypen, begrenzte TCP-Transporte in Node.js und Android, Same-Origin-Gateway und Offline-PWA mit Fixture. Gopher bleibt nicht authentifiziert und unverschlüsselt.

Funktionierendes Projekt ansehen

Gopher als klar begrenzte, prüfbare lokale Arbeitsumgebung.