fido-und-mailbox-netze

Was Mailbox-Netze überhaupt waren

Eine einzelne Mailbox war lokal. Ihre Bretter, privaten Nachrichten und Dateien lebten zunächst nur auf diesem einen Rechner. Ein Mailbox-Netz entstand dort, wo mehrere Systeme begannen, Nachrichten untereinander auszutauschen. Aus lokaler Kommunikation wurde verteilte Kommunikation. Die Nutzer bemerkten das oft nur daran, dass plötzlich Beiträge aus anderen Städten oder Ländern auftauchten. Technisch bedeutete es jedoch eine ganz andere Größenordnung.

Statt dass ein Benutzer ständig online sein musste, sammelte das System Nachrichten zunächst lokal. Zu festgelegten Zeiten wurden diese Datenpakete an andere Systeme übertragen – meist nachts, wenn Telefonkosten geringer waren oder die Leitungen der Box nicht für Benutzer blockiert werden sollten. Genau deshalb waren diese Netze asynchron. Eine Nachricht ging nicht sofort durch, sondern wanderte Schritt für Schritt von System zu System.

Das Netz bestand also nicht aus einer dauernden Online-Verbindung, sondern aus vielen kurzen, geplanten Transfers. Genau diese Logik machte Mailbox-Netze technisch interessant. Sie zwangen zu Struktur, zu Routing und zu Disziplin. Jede Verbindung kostete Zeit und Geld. Jede unnötige Übertragung war spürbar. Und jede Fehlerquelle – falsche Nummer, veralteter Knoten, schlechtes Timing – fiel unmittelbar auf.

„Eine Mailbox war ein Ort. Ein Mailbox-Netz war eine Transportlogik.“

FidoNet als prägender Standardfall

FidoNet wurde zum bekanntesten Mailbox-Netz, weil es aus der einzelnen BBS-Logik ein erstaunlich belastbares, verteiltes Nachrichtensystem machte. Der Grundgedanke war schlicht: Mail und Konferenzbeiträge werden zwischen Knoten weitergereicht. Aber aus dieser Schlichtheit entstand eine komplette Infrastruktur mit Adressierung, Knotenlisten, Standarddokumenten, Übertragungsprotokollen und Verwaltungsstruktur.

Technisch ist daran vor allem interessant, dass FidoNet nicht als luxuriöse Online-Welt gedacht war. Es war ein Netz für reale Wählleitungen. Damit stand von Anfang an nicht Komfort im Vordergrund, sondern Kostenbewusstsein, Routing und strukturierte Übertragung. Es war normal, dass Nachrichten spät nachts wanderten, dass einzelne Transfers gebündelt wurden und dass ein Ziel nicht direkt, sondern über Hubs oder Hosts erreicht wurde.

Gerade deshalb war FidoNet mehr als eine Sammlung von Mailboxen. Es war ein Netz mit eigenem Regelwerk, eigener Topologie und dem Anspruch, Interoperabilität zwischen sehr unterschiedlicher Software überhaupt erst herzustellen.

FTS, FSC und FSP: Interoperabilität wurde dokumentiert

FidoNet bestand nicht nur aus kompatibler Software, sondern aus veröffentlichten technischen Dokumenten. Die Bezeichnungen zeigen ihren jeweiligen Status.

FTS-0001 beschrieb den frühen technischen Mindestbestand, FTS-0004 Echomail, FTS-0005 die historische Distributions-Nodelist und FTS-0009 Nachrichtenkennung und Antwortverknüpfung. Spätere Dokumente ergänzten oder ersetzten Teile dieser frühen Basis.

Adressierung: Zone, Net, Node, Point

Einer der prägnantesten Teile von FidoNet war die Adressform. Ein Knoten wurde typischerweise als Zone:Net/Node geschrieben, bei Power-Usern oder privaten Endsystemen erweitert zu Zone:Net/Node.Point. Das wirkte zunächst kryptisch, war aber hoch funktional: Die Adresse transportierte bereits einen guten Teil der Netzstruktur.

Ein Point war besonders interessant, weil er zeigte, dass das Netz nicht nur aus öffentlich erreichbaren Mailboxen bestand. Wer technisch versiert war, konnte sich als Point an einen Hostknoten hängen, Mail austauschen und Echomail lokal offline lesen oder schreiben. Das sparte Leitungszeit und reduzierte Kosten. Gleichzeitig war ein Point eben kein vollwertiger öffentlicher Knoten im Nodelist-Sinn.

„Die Adresse war nicht nur Kennung. Sie war bereits ein Stück Routingdenken.“

Region, Host, Hub, Point und Domain sauber trennen

Die häufig zitierte 4D-Adresse endet bei Zone:Net/Node.Point. Organisatorische Rollen und eine optionale FTN-Domain ergänzen den Kontext, verändern aber nicht unbemerkt das klassische Hauptschema.

Nodes, Hubs, Hosts und Routing

FidoNet lebte nicht davon, dass jede Mailbox jede andere direkt anrief. Das wäre unter realen Telefonkosten und bei wachsender Knotenzahl schnell unerfreulich geworden. Deshalb bildete sich eine Hierarchie aus Nodes, lokalen Hubs, Hosts und größeren Routingpunkten. Genau dadurch wurde aus vielen Einzelverbindungen eine ökonomisch tragfähigere Struktur.

Innerhalb eines lokalen Netzes konnten Knoten häufig direkt miteinander tauschen, besonders wenn lokale Gespräche günstig oder kostenlos waren. Für überregionale Ziele war das anders. Dort wurden Nachrichten oft zunächst zu einem Hub oder Host gesammelt, der sie gebündelt weiterreichte. Das sparte Verbindungsaufbau, Leitungszeit und Gebühren.

Diese Topologie war keine Schönheitsfrage, sondern ein direktes Ergebnis der Kostenstruktur von Telefonnetzen. Das Netz war dort stark, wo es nicht jede Verbindung naiv einzeln behandelte, sondern Verkehr zusammenzog und erst dann weiterleitete.

Routing war Kosten-, Zeit- und Zuständigkeitsplanung

Netmail konnte direkt an den Zielknoten gewählt oder über definierte Hosts und Gateways weitergereicht werden. Echomail folgte dagegen einer Verteilstruktur, die Schleifen vermeiden und alle angeschlossenen Systeme erreichen musste.

Region und Koordinatorenstruktur waren nicht nur Politik. Sie lieferten auch Wege, Nodelist-Daten und überregionalen Verkehr zu bündeln.

Nodelist, Nodediff und Aktualität

Ohne aktuelle Knotendaten konnte ein Fido-Netz nicht vernünftig arbeiten. Genau deshalb war die Nodelist so zentral. Sie enthielt die bekannten aktiven öffentlichen Knoten, ihre Adressen, Rufnummern und weitere Betriebsinformationen. In FidoNet war diese Liste keine dekorative Übersicht, sondern operative Grundlage.

Besonders wichtig war dabei, dass die Nodelist regelmäßig aktualisiert und verteilt wurde. Statt jede Woche eine komplette Welt neu zu übertragen, arbeiteten viele Systeme mit Differenzdateien – also Nodediffs –, die die Änderungen zur Vorwoche beschrieben. Das war technisch nüchtern und bandbreitenschonend.

Wer mit veralteten Knotendaten arbeitete, bekam die Folgen unmittelbar zu spüren: Fehlanrufe, besetzte oder tote Nummern, nicht erreichbare Ziele, unnötige Gebühren und störendes Nachfassen. Genau deshalb war Aktualität hier nicht Komfort, sondern Voraussetzung für ein funktionierendes Netz.

Nodelist-Felder, Status und Parser

Historische Distributions-Nodelists bestanden aus strukturierten, komma-separierten Datensätzen. Typische Felder beschrieben Knotenrolle beziehungsweise Schlüsselwort, Nummer, Systemname, Ort, Sysop, Rufnummer, maximale Geschwindigkeit und Flags.

Statuskennzeichen wie Pvt, Hold oder Down waren keine bloße Beschreibung. Sie beeinflussten, ob und wie automatische Mailer einen Eintrag verwenden durften. Ein Parser musste außerdem den hierarchischen Kontext vorheriger Zone-, Region-, Host- oder Hubzeilen berücksichtigen.

FTS-5000 ersetzte später FTS-0005 als Nodelist-Spezifikation. Eine erhaltene historische Liste muss daher zusammen mit ihrem damaligen Format- und Softwarestand gelesen werden.

Paket, Nachrichtenkopf und Nachrichtentext sind getrennte Ebenen

Ein ausgetauschtes FTN-Paket enthält einen Paketkopf und danach eine oder mehrere Nachrichten. Der Paketkopf beschreibt die Session- beziehungsweise Paketpartner und Formatinformationen. Jede Nachricht besitzt zusätzlich eigene Absender-, Empfänger-, Attribut-, Kosten-, Datums- und Textfelder.

Die frühe Type-2-Welt wurde durch zone- und pointfähige Erweiterungen ergänzt. Deshalb muss Archivsoftware nicht nur den Dateinamen, sondern den konkreten Pakettyp und die verwendeten Zusatzfelder kennen.

Kludge Lines tragen Technik im Nachrichtentext

Viele FTN-Erweiterungen wurden als Steuerzeilen im Textteil transportiert. Solche Zeilen beginnen häufig mit dem Steuerzeichen SOH beziehungsweise ^A und sind für normale Leser nicht als Fließtext gedacht.

AREA: und SEEN-BY: gehören ebenfalls zur Echomail-Steuerung, beginnen im klassischen Format jedoch nicht wie gewöhnliche Kludge Lines mit ^A. Ein Reader sollte technische Zeilen erkennen, nicht ungeprüft als Benutzertext darstellen oder beim Gateway verlieren.

Netmail, Echomail und Fileecho

In der Praxis war nicht jede Nachricht gleich. FidoNet unterschied verschiedene Verkehrsarten, und genau diese Trennung war wichtig, um das Netz verständlich zu halten.

Netmail war im Grunde die private Nachrichtenschicht des Netzes. Sie musste an ein konkretes Ziel gelangen. Routing, Priorität und Zustellbarkeit waren hier besonders wichtig. Echomail dagegen war die öffentliche Konferenzebene. Ein Beitrag in einem Echo wurde über definierte Verteilwege an alle teilnehmenden Knoten weitergegeben. So entstanden verteilte Diskussionsräume, die nicht an einer einzelnen Mailbox hingen.

Genau hier zeigte sich die Doppelrolle solcher Netze: einerseits persönliche Kommunikation, andererseits öffentliche Foren. Im einen Fall zählte zielgenaue Zustellung. Im anderen die verlässliche Replikation an viele Stellen.

„Netmail ging an jemanden. Echomail ging in einen Raum.“

Netmail: adressierte Nachricht mit Transportattributen

Netmail richtet sich an eine konkrete FTN-Adresse und einen Empfängernamen. Attribute konnten unter anderem festlegen, ob eine Nachricht privat markiert, in Transit, bereits gesendet oder als Datei-Anhang beziehungsweise Dateianforderung behandelt wurde.

Eine private Markierung ist keine Ende-zu-Ende-Verschlüsselung. Die Nachricht wird als Datei oder Paket über beteiligte Systeme transportiert und muss von deren Software verarbeitet werden. Vertrauliche Inhalte benötigten daher zusätzliche Schutzverfahren und eine passende Vertrauensannahme.

Echomail: replizierte Konferenz statt zentrale Datenbank

Ein Echo besitzt einen Area-Namen und wird über vereinbarte Links an mehrere Systeme verteilt. Jeder teilnehmende Knoten hält eine lokale Kopie der Nachrichtenbasis oder importiert die Beiträge in seine eigene Messagebase.

1. lokaler Beitrag: BBS oder Point schreibt eine Nachricht in die Area.
2. Scanner: markiert neue Nachrichten für abonnierte Nachbarsysteme.
3. Tosser/Packer: erzeugt ausgehende Pakete und Bundles.
4. Mailer: überträgt sie an die Links.
5. Remote-Tosser: importiert, prüft Duplikate und verteilt weiter.

Die Replikation erklärt zugleich die Stärke und die Grenze: Ein Echo funktioniert ohne zentralen Server, aber eine einmal verteilte Nachricht lässt sich nicht zuverlässig aus allen bereits erreichten Kopien zurückholen.

AREA, SEEN-BY und PATH verhindern falsche Weiterverteilung

SEEN-BY und PATH lösen unterschiedliche Aufgaben. SEEN-BY steuert die weitere Verteilung; PATH dokumentiert den zurückgelegten technischen Weg. Beides ist kein Ersatz für eine eindeutige MSGID-basierte Duplikaterkennung.

MSGID, REPLY und Dupe-Check

FTS-0009 standardisierte Steuerzeilen für eine möglichst eindeutige Nachrichtenkennung und die Verknüpfung einer Antwort mit ihrer Vorgängernachricht.

• MSGID: kombiniert Absenderkontext und eine vom erzeugenden System gewählte Kennung.
• REPLY: übernimmt die Kennung der Nachricht, auf die geantwortet wird.
• Threading: Reader kann Antworten gruppieren, sofern Kennungen erhalten bleiben.
• Dupe-Check: Tosser speichert bereits verarbeitete Kennungen oder zusätzliche Signaturen.
• Gateway: muss IDs so abbilden, dass keine Schleife bei Rückführung entsteht.

Keine Kennung ist allein magisch global eindeutig. Erzeugungsregel, Softwarefehler, Gateways und begrenzte Dupe-Datenbanken bestimmen, wie belastbar die Erkennung tatsächlich ist.

Tearline und Origin: sichtbare Herkunft am Nachrichtenende

Echomail trägt traditionell eine Tearline und eine Origin-Zeile. Die Tearline begann mit drei Bindestrichen und nannte häufig die erzeugende Software. Die Origin-Zeile enthielt einen frei gewählten Herkunftstext und die FTN-Adresse des Systems.

Die Origin ist sichtbare Herkunftsangabe, aber kein kryptografischer Absendernachweis. Gateways, Points und falsch konfigurierte Systeme können zusätzliche Adresskontexte erzeugen.

BBS, Mailer, Tosser, Packer

Technisch bestand eine Fido-kompatible Umgebung selten aus nur einem einzigen großen Programm. Typisch war vielmehr eine Aufgabenteilung: Die Mailbox-Software bediente die Nutzer. Ein Frontend-Mailer führte die eigentlichen Verbindungen durch. Ein Tosser oder Mailprozessor entpackte eingehende Pakete, verteilte Inhalte in die richtigen Bereiche und bereitete ausgehende Daten für den nächsten Transfer vor. Häufig kamen noch Packer, Scanner, Editoren und Reader hinzu.

Diese Aufgabenteilung ist wichtig, weil sie zeigt, dass Mailbox-Netze nicht einfach „BBS plus Modem“ waren. Sie bestanden aus einer kleinen Werkzeugkette. Und genau diese Werkzeugkette machte das System beherrschbar: jedes Teil hatte eine klarere Aufgabe, statt alles in einem unübersichtlichen Monolithen zu verstecken.

Inbound, Outbound und Messagebase

Eine saubere FTN-Installation trennt empfangene Transportdateien, geprüfte beziehungsweise entpackte Bestände, lokale Nachrichtenbasen und ausgehende Warteschlangen.

Konkrete Dateinamen unterschieden sich zwischen Mailern und Betriebssystemen. Deshalb gehören Pfadkonfiguration, Namensschema und verwendete Softwareversion untrennbar zur Archivierung.

Mailer-Sitzung: Erkennen, Aushandeln, übertragen, bestätigen

Die Sessionebene muss von Nachrichtenformat und Dateitransfer getrennt werden. Historische Mailer verwendeten verschiedene Erkennungs- und Handshakeverfahren.

Ein Sessionpasswort authentisiert nach der jeweiligen Mailerlogik einen Verbindungspartner, verschlüsselt aber nicht automatisch den Modemdatenstrom oder die gespeicherten Nachrichten.

Paket ist nicht Bundle und Bundle ist nicht Messagebase

Beide Seiten mussten einen passenden Archivierer und ein kompatibles Namens- beziehungsweise Bundleverfahren verwenden. Ein erhaltenes Archiv ohne damaliges Packprogramm, Passwort oder Formatbeschreibung kann trotz intakter Bytes unlesbar bleiben.

File Requests und Fileecho

FTN-Mailer konnten neben Nachrichten auch Dateien austauschen. Ein File Request forderte benannte oder per Magie-Name definierte Dateien vom entfernten System an, sofern dessen Regeln dies erlaubten. FTS-0008 dokumentierte die Bark-Erweiterung für solche Anforderungen.

Fileecho verteilte Dateien dagegen abonnementsähnlich über definierte Links. Häufig begleiteten Kontroll- und Beschreibungsdateien den eigentlichen Nutzinhalt, damit Name, Area, Ursprung und Weiterverteilung geprüft werden konnten.

NetCalls, Mail Hours und Telefonkosten

Die eigentliche physische Realität solcher Netze war das Telefon. Jede überregionale Verbindung musste gewählt werden. Jeder Verbindungsaufbau kostete. Jede Minute konnte relevant sein. Genau deshalb wurden Transfers oft in die Nacht gelegt. Dort waren Tarife günstiger, die Mailbox musste keine Benutzer bedienen, und der Verkehr ließ sich planbarer abarbeiten.

In FidoNet spielte dabei die Mail Hour beziehungsweise Zone Mail Hour eine wichtige Rolle. Bestimmte Zeitfenster mussten für Netzübergaben reserviert oder zumindest berücksichtigt werden. Auch außerhalb solcher Stunden liefen Transfers, aber der Grundgedanke blieb: Netzverkehr war zeitlich geplant, nicht dauernd beliebig.

Points und Offline-Arbeit

Ein besonders wichtiger Fortschritt für technisch versierte Nutzer war die Point-Logik. Statt sich lange interaktiv in eine öffentliche Mailbox einzuwählen, konnte ein Point-Nutzer Mail und Konferenzbeiträge gebündelt mit einem Host austauschen, lokal lesen, beantworten und erst später wieder gesammelt zurücksenden. Das sparte Leitungszeit und machte größere Diskussionsmengen überhaupt erst praktikabel.

Gerade bei wachsender Echomail war das entscheidend. Wer sich durch viele Konferenzen arbeitete, wollte nicht Minute um Minute am Online-Tarif vergeuden. Offline-Reader, Reply-Pakete und gebündelte Zustellung passten deshalb perfekt zur technischen und ökonomischen Realität der Zeit.

Ein Point war damit keine vollwertige öffentliche Box, sondern eher ein privater Endpunkt mit Netzanschluss über einen Hostknoten. Genau diese Zwischenstellung machte ihn so nützlich.

Echo-Regeln, Moderator und verteilte Verantwortung

Ein technischer Area-Name erklärt noch nicht, welche Beiträge erlaubt sind. Echo-Regeln bestimmten Thema, Sprache, Realname oder Pseudonym, Zitierstil, Crossposts und Moderationsweg.

• Area-Fixierung: Links abonnieren nur vereinbarte Echos.
• Moderator: pflegt Regeln und kann Verwarnungen oder Sperrempfehlungen aussprechen.
• Linkverantwortung: jeder Sysop entscheidet über lokale Teilnahme und Weiterleitung.
• Recall-Grenze: bereits replizierte Beiträge können auf entfernten Systemen weiterbestehen.
• Feed-Trennung: technische Abkopplung eines Störers ist möglich, aber keine zentrale globale Löschung.

Zeichensätze, Zeilenlänge und Zitieren

FTN-Nachrichten wanderten zwischen DOS-, OS/2-, Amiga-, Atari-, Unix- und anderen Systemen. Umlaute und Sonderzeichen waren daher keine Selbstverständlichkeit.

Gateways müssen Bedeutung übersetzen, nicht nur Text kopieren

Ein Gateway zwischen FTN, Internet-Mail und Usenet muss Adressen, Message-IDs, Betreff, Threading, Zeichensatz, Steuerzeilen und Rückweg abbilden.

• Adressabbildung: FTN-4D-Adresse und RFC-Mailadresse sind unterschiedliche Namensräume.
• Message-ID: muss bei Hin- und Rückweg stabil genug bleiben, um Schleifen und Duplikate zu vermeiden.
• Echo/Newsgroup: Area-Name und News-Hierarchie benötigen eine feste Zuordnung.
• Header: technische FTN-Zeilen nicht unkontrolliert als sichtbaren Mailtext ausgeben.
• Loop Prevention: gegatete Nachricht darf nicht als vermeintlich neuer Beitrag zurückkehren.

Ein „transparentes“ Gateway ist daher technisch anspruchsvoll. Beide Seiten besitzen Metadaten, die im jeweils anderen Format nicht automatisch ein direktes Gegenstück haben.

binkp: FTN-Transport über zuverlässige Verbindungen

binkp wurde für Mailer-Sitzungen über einen bereits zuverlässigen Transport wie TCP entwickelt. Dadurch musste die Session nicht dieselben feingranularen Fehler- und Synchronisationsverfahren wiederholen, die für störanfällige Wählleitungen sinnvoll waren.

binkp ist kein Gateway zu E-Mail oder Usenet. Es transportiert FidoNet-Technology-Dateien über einen anderen Verbindungsweg. Nachrichtenformat, Tosser, Echomail und Routing bleiben weiterhin FTN-Aufgaben.

Vertrauen, Passwörter und fehlende Ende-zu-Ende-Sicherheit

Historische Dokumentation rechtfertigt keine Veröffentlichung alter Telefonnummern, privater Nachrichten, Sessionpasswörter oder personenbezogener Nodelist-Auszüge ohne Prüfung.

Diagnose entlang der vollständigen Transportkette

Erhaltung historischer FTN-Bestände

Eine Messagebase allein rekonstruiert kein Mailbox-Netz. Für eine belastbare technische Archivakte werden mehrere Ebenen benötigt.

• Software und Version: BBS, Mailer, Tosser, Packer, Reader und Betriebssystem.
• Konfiguration: Adressen, Areas, Links, Routing, Archivierer, Pfade und Zeitzone.
• Nodelist/Nodediff: mit Datum, Prüfsumme und zugehörigem Parserstand.
• Transportdateien: originale Pakete, Bundles, TIC/Request- und Sessiondateien möglichst unverändert.
• Messagebase: einschließlich Index-, Lastread- und Threaddaten.
• Zeichensatz: Codepage, CHRS-Praxis und Konvertierungsregeln dokumentieren.
• Datenschutz: private Mail, Telefonnummern, Passwörter und reale Namen vor Veröffentlichung prüfen.

Originaldateien sollten schreibgeschützt mit Hashwerten erhalten werden. Eine modern konvertierte Lesefassung darf daneben entstehen, muss aber als Bearbeitung vom Originalbestand getrennt bleiben.

Z-Netz, MausNet und CL-Netz waren keine Fido-Unterarten

Im deutschsprachigen Raum existierten mehrere eigenständige Store-and-Forward-Netze. Gemeinsam war ihnen der Austausch zwischen Mailboxen; Nachrichtenformat, Adressierung, Software, Regeln und Netzkultur konnten sich jedoch deutlich unterscheiden.

Der Begriff Mailbox-Netz ist daher die Oberkategorie. FTN bezeichnet eine technische Familie; FidoNet ist ein konkretes, historisch besonders großes Netz innerhalb dieser Familie. ZConnect, MausNet und andere Verfahren bilden eigene Familien.

Verhältnis zu Usenet, Shell-Accounts und Web

Mailbox-Netze standen nicht isoliert da. Sie lagen historisch zwischen mehreren Welten. Gegenüber der einzelnen BBS waren sie bereits verteilte Netze. Gegenüber Usenet blieben sie oft stärker mailbox- und sysop-geprägt. Gegenüber Shell-Accounts waren sie lokaler, telefonischer und direkter von Wählleitungen abhängig. Gegenüber dem Web wirkten sie später wie eine frühere, textnähere Stufe verteilter Kommunikation.

Viele technische Übergänge liefen über Gateways. Echomail-Konferenzen konnten mit Newsgroups gekoppelt werden. Netmail konnte in Internet-Mail übersetzt werden. Shell-Accounts öffneten später Räume, in denen Reader, News, Mail und schließlich Webserver näher zusammenrückten. Genau dort zeigt sich die Kontinuität: Die Werkzeuge wechselten, aber die Grundbegriffe – Adressierung, Transport, Routing, Zustellbarkeit, Textdisziplin – blieben.

Die Modem- und Telefonebene darunter beschreibt modems-und-dataphon.htm. Die lokale Mailbox-Praxis steht auf mailboxen-bbs.htm. Die News-Schicht darüber beschreibt usenet-und-newsgruppen.htm. Die spätere Host- und Shell-Ebene folgt auf shell-accounts-und-hosts.htm.

Technische Referenzen

Der FTSC-Dokumentenbestand enthält Standards, Vorschläge, Kommentare, obsolet gewordene Fassungen und spätere Erweiterungen. Eine konkrete Implementation muss gegen die tatsächlich verwendeten Dokumentversionen geprüft werden.

Was technisch daran stark war

Die eigentliche Stärke von Fido- und Mailbox-Netzen lag nicht in Geschwindigkeit oder Komfort. Beides war aus heutiger Sicht begrenzt. Stark war vielmehr, dass diese Netze mit sehr einfachen Mitteln eine belastbare Kommunikationsstruktur aufbauten: Adressierung, Routing, Knotenlisten, Paketlogik, Offline-Arbeit und klare Trennung zwischen Transport und Nutzung.

Gerade weil Telefonzeit knapp und Leitungsqualität unzuverlässig waren, mussten diese Netze diszipliniert sein. Nichts davon war überflüssiger Luxus. Die Struktur war direkt aus der Realität der Technik geboren. Und genau das macht sie bis heute interessant: Sie zeigen, wie weit man mit klarem Denken, gut getrennten Funktionen und nüchterner Netzlogik kommen kann.

„Die Mailbox war lokal. Das Denken dahinter war es längst nicht mehr.“

Querverweise im SSLXY-Archiv

• Zur SSLXY-Hauptseite
• Mailboxen und BBS-Systeme
• Bulletin-Board-Alltag
• Modems, Mailboxen und Protokolle
• Modems und Dataphon
• Usenet und Newsgruppen
• Shell-Accounts und Hosts
• Datensicherung und Erhaltung