Ich steige in Mesh-Netzwerke ein (Meshtastic, MeshCore, Reticulum)
(jonaharagon.com)- Mesh-Networking verringert die Abhängigkeit von zentralen Service-Providern und eignet sich gut für Einsatzzwecke, bei denen Zugänglichkeit und Zensurresistenz wichtig sind, etwa Messaging, Social Networking und Informationsaustausch
- Ein über LoRa aufgebautes Funk-Mesh bietet geringe Leistungsaufnahme und große Reichweite im lizenzfreien Sub-GHz-Band und kann so lokale Peer-to-Peer-Netze bilden
- Meshtastic ist für mobiles Messaging und Geräte-Tracking leicht nutzbar, stößt in großen öffentlichen Meshes wegen seines Flooding-Designs und der Hop-Beschränkung aber an deutliche Grenzen
- MeshCore nutzt ein echtes Routing-System, reduziert Übertragungen und Überlastung und unterstützt bis zu 64 Hops, allerdings sind die Struktur aus Companion- und Repeater-Knoten sowie proprietäre Clients nachteilig
- Reticulum bietet verschlüsseltes Routing über LoRa, LAN, Wi‑Fi, Internet, Tor, I2P und weitere Netze hinweg, doch ein Ökosystem eigenständiger LoRa-Infrastrukturknoten ist noch nicht unkompliziert
Warum Mesh-Netzwerke nötig sind
- Das moderne Internet hat logisch gesehen eine Mesh-Struktur, in der Praxis hängen zentrale Ressourcen aber von wenigen Anbietern und zentralen Service-Providern ab und sind dadurch anfällig für Zensurdruck und Service-Kontrolle
- Laptops, Bürocomputer und mobile Geräte von Einzelpersonen und Gemeinschaften sind leistungsfähig genug, doch die heutige Service-Struktur ist stark daran gebunden, den Zugang großer Anbieter zu konsumieren
- Mesh-Networking reduziert die Abhängigkeit von zentralen Service-Providern, indem mehrere direkt verbundene Peers Datenpakete weiterleiten statt eines zentralen Rechenzentrums
- Verbindungen mit hoher Bandbreite sind teuer, und für Dienste mit latenzkritischen Anforderungen wie Gaming sind transkontinentale und Untersee-Glasfasernetze mit möglichst wenigen Zwischenstationen praktisch unverzichtbar
- Bandbreitenintensive Dienste wie Netflix oder latenzsensible Dienste wie Spiele lassen sich kurzfristig kaum auf Mesh-Netzwerke verlagern, aber Messaging, Social Networking und Informationsaustausch passen gut zu Anwendungsfällen, in denen Zugänglichkeit, Zensurresistenz und Resilienz entscheidend sind
Das Potenzial von LoRa-basierten Funk-Meshes
- Ein großer Teil der modernen Innovation im Mesh-Networking findet derzeit im Bereich LoRa-Funk statt
- LoRa-Funkgeräte nutzen in den meisten Ländern lizenzfreie Sub-GHz-Bänder, die öffentlich verwendet werden können
- Im Vergleich zu den aus Wi‑Fi bekannten lizenzfreien 2,4- und 5-GHz-Bändern arbeitet LoRa mit geringerer Leistung und bietet dabei eine größere Reichweite
- Funkbasiertes Mesh-Networking kann Peer-to-Peer-Netze schaffen, die mit dem Internet koexistieren
- Es kann Zugang in Regionen mit heute unzureichender Konnektivität bereitstellen
- Es kann ein Internet-Backup für wichtige Bedürfnisse erhalten und damit die digitale Souveränität Einzelner stärken
- Dass sich Nachrichten allein mit Geräten senden lassen, die einem selbst und anderen Netzwerkteilnehmern gehören, unterscheidet sich grundlegend von einem Modell, bei dem Kommunikationsfähigkeit von Diensten wie einem ISP oder Starlink gemietet wird
Meshtastic
- Meshtastic gilt als führender Akteur im Bereich konsumorientierter LoRa-Meshes
- Die Hauptanwendungsfälle von Meshtastic sind mobiles Messaging und Geräte-Tracking; es ist eher ein sofort nutzbares Produkt als ein Technikprojekt nach dem Motto „erst Netzwerk bauen, dann einen Zweck dafür finden“
- Für Nutzer, die ein sofort einsatzbereites Werkzeug ähnlich einem kleinen Walkie-Talkie wollen, ist es attraktiv
- In kleinen privaten Gruppen wie bei Wanderern oder Veranstaltungsteilnehmern funktioniert es vernünftig gut, in sehr großen und öffentlichen Meshes ist es vom Design her jedoch schwer aufrechtzuerhalten
- Einige öffentliche Mesh-Gruppen haben die nutzbare Bandbreite von Meshtastic erhöht, indem sie Reichweite opferten, doch das ist eher ein Provisorium, das das Grundproblem nicht löst
- Wer öffentliches Mesh-Networking ernsthaft betreiben will, sollte andere Ansätze in Betracht ziehen
MeshCore
- MeshCore ist eine der Alternativen, zu denen einige öffentliche Mesh-Gruppen inzwischen wechseln
- Das ursprüngliche Design von Meshtastic setzt darauf, jede Nachricht praktisch in das gesamte Netzwerk zu flooden und darauf zu hoffen, dass sie ihr Ziel erreicht
- MeshCore besitzt ein echtes Routing-System, mit dem Nachrichten nur über einen bestimmten Gerätepfad zwischen Sender und Empfänger übertragen werden
- Dieser Ansatz reduziert die Zahl der Funkübertragungen deutlich, senkt die Netzüberlastung, erhöht die Zuverlässigkeit und bewegt größere Gruppen, die eher an Messaging als an Sensor- oder Positionsdatenfreigabe interessiert sind, zum Wechsel auf MeshCore
- MeshCore ist jedoch nicht in dem Sinn ein vollständiges Mesh, wie öffentliche Mesh-Enthusiasten es sich wünschen
- Geräte werden grob in Companion und Repeater unterteilt
- Companion-Geräte sind die Endgeräte, über die die meisten Nutzer Nachrichten senden und empfangen
- Repeater bilden untereinander das Mesh und erweitern die Gesamtreichweite des Netzes
- Ein Companion muss sich für den Netz-Zugang immer in Reichweite eines Repeaters befinden und leitet keine Nachrichten für andere Companions weiter
- MeshCore unterstützt bis zu 64 Hops, und da LoRa-Repeater unter idealen Bedingungen mehrere Meilen voneinander entfernt stehen können, kann die reale Größenordnung sehr groß werden
- Die Standardgrenze von drei Hops bei Meshtastic setzt der Ausbreitung des Meshes eine praktische Beschränkung, selbst wenn sich bis zu sieben Hops konfigurieren lassen
- Zwar kann grundsätzlich jeder als MeshCore-Repeater teilnehmen, doch das erfordert zusätzliche Planung, Abstimmung und Zentralisierung
Das Problem proprietärer Software bei MeshCore
- Das größere Problem von MeshCore ist, dass mehrere Bestandteile proprietäre Software sind
- Das zugrunde liegende Protokoll und die Firmware für einige Funkgeräte sind Open Source, die offiziellen MeshCore-Clients sind jedoch alle proprietär, und einige Funktionen sind hinter einer Bezahlschranke gesperrt
- Für ein Off-Grid-Mesh-Netzwerk zur Katastrophenvorsorge ist proprietäre Software ungeeignet, und die Abhängigkeit von einem zentralen Zahlungsabwickler verschärft das Problem
- Wenn das zentrale Ziel eines Off-Grid-Mesh-Netzwerks Freiheit und Kontrolle ist, ist eine geschlossene Lösung schwer zu unterstützen
- Es gibt bereits Bestrebungen, einen inoffiziellen Open-Source-Client für MeshCore zu entwickeln
- Dennoch dürfte der Großteil der Nutzer im MeshCore-Ökosystem beim offiziellen proprietären Ökosystem bleiben, und derzeit bietet es wohl noch nicht genug Vorteile, Nutzer und Zuverlässigkeit, um eine breite Einführung zu rechtfertigen
- Noch besteht die Chance, eine bessere Lösung zu wählen, bevor Netzwerkeffekte Nutzer an eine bestimmte Plattform binden
Gemeinsame Grenzen von Meshtastic und MeshCore
- Weder Meshtastic noch MeshCore sind besonders gut skalierbar
- Meshtastic lässt sich selbst unter idealen Bedingungen kaum über die Größenordnung eines lokalen Meshes hinaus skalieren
- MeshCore ist besser, dürfte sich aber nur schwer auf große Regionen, Länder oder gar planetare Maßstäbe erweitern lassen
- Beide Projekte ähneln eher Anwendungen als einem Protokoll
- Sie ermöglichen einfaches Instant Messaging auf LoRa-Basis
- Mesh-Networking-Anwendungen jenseits dessen, was die offiziellen Client-Apps unterstützen, stehen nicht im Fokus
- Sie sind für die Kommunikation kleiner lokaler Gruppen ausgelegt, und öffentliche Meshes auf dieser Basis sind eher Ausnahme als Standardanwendungsfall
- Beide Projekte verlassen sich fast vollständig auf LoRa
- LoRa ist nützlich für den Aufbau provisorischer Mesh-Netze mit geringer Bandbreite, da es in vielen Ländern lizenzfrei nutzbar ist und moderne digitale Techniken wie Verschlüsselung erlaubt, die im Amateurfunk meist verboten sind
- Dennoch ist LoRa nicht in jedem Szenario die perfekte Lösung und zudem recht langsam
Trennung von physischem Netzwerk und Routing
- Ideale Software für Mesh-Networking und Routing sollte unabhängig vom physischen Netzwerk sein, das Geräte miteinander verbindet
- Es sollte möglich sein, günstige lokale LoRa-Netze für Nachbarschaften und regionale Gemeinschaften aufzubauen und diese über leistungsfähigere Punkt-zu-Punkt-Mikrowellenverbindungen, Glasfaser oder das Internet miteinander zu verbinden
- Meshtastic und MeshCore bieten Möglichkeiten, verschiedene Meshes per MQTT miteinander zu koppeln
- Bei Meshtastic ist dieses Erlebnis nicht besonders gut
- MQTT-Bridging über das Internet kann die Netzqualität schon bei mehr als nur wenigen Nutzern so stark verschlechtern, dass die Nutzung praktisch unbrauchbar wird
- Benötigt wird eine Lösung, die Pakete intelligent über verschiedene Verbindungstypen hinweg routet, damit die Nutzererfahrung im Mesh nicht von einer bestimmten Schnittstelle abhängt
Reticulum
- Reticulum ist ein Networking-Stack, der starkes verschlüsseltes Routing über verschiedene physische Netzwerke einschließlich LoRa bereitstellt
- Wie MeshCore bietet es automatisches Routing über Netzpfade, doch diese Pfade können nicht nur über LoRa, sondern über alle unterstützten Schnittstellen laufen
- Wie bei Meshtastic funktionieren Geräte im selben lokalen Netzwerk unmittelbar miteinander
- Verbindet man zwei Geräte auf derselben LoRa-Frequenz, entsteht sofort ein funktionierendes Mesh
- Fortgeschrittenes Netzwerk-Know-how oder dedizierte Repeater sind nicht nötig
- Dadurch eignet sich Reticulum sowohl für kleine private Netze, für die Meshtastic gut passt, als auch für größere Netze, in denen MeshCore vergleichsweise besser funktioniert
- Auch ein kleines Reticulum-Netz funktioniert bereits sinnvoll, und wenn eines seiner Mitglieder gleichzeitig mit einem anderen Reticulum-Netz verbunden ist, können beide Netze ohne Konfigurationsänderung natürlich zusammenwachsen
- Reticulum-Verbindungen können LoRa, lokales LAN, Punkt-zu-Punkt-Wi‑Fi und Mikrowellenlinks, das Internet, Tor, I2P sowie Netze wie Packet Radio für Amateurfunknutzer kombinieren
Wie verschiedene Netzwerke als eines behandelt werden
- Reticulum kann theoretisch jedes Netzwerk unterstützen, das sich über TCP, UDP oder eine einfache serielle Schnittstelle ansprechen lässt
- Unter Berücksichtigung der Bandbreite jedes verbundenen Netzes bestimmt es den optimalen Pfad für Nachrichten und optimiert dabei sowohl Distanz als auch die Ressourcen des physischen Netzwerks
- Der Kern von Reticulum ist heterogene Konnektivität
- Laut der Dokumentation erfordert das Mischen unterschiedlicher Übertragungsmedien im traditionellen Networking Gateways, Übersetzungsschichten und sorgfältige Konfiguration, während Reticulum Heterogenität als Grundannahme behandelt
- Netzwerkdesigner können je nach Situation frei ein günstiges und passendes Medium wählen
- LoRa für weiträumige Abdeckung mit niedriger Bandbreite
- Wi‑Fi für lokale Verbindungen mit hoher Kapazität
- I2P für anonyme Internetverbindungen
- Ethernet für Infrastruktur-Backhaul
- Reticulum übernimmt die Übersetzung und Koordination zwischen diesen Medien automatisch
- Auch wenn lokale Mesh-Netze langfristig nicht vom Internet oder von I2P abhängig sein sollten, ist die erstklassige Unterstützung für Verbindungen über TCP und Internetprotokolle ein großer Vorteil für alle, die öffentliche lokale Meshes aufbauen wollen
Zusammenschaltung lokaler Meshes
- Wenn unterschiedliche lokale Gruppen miteinander verbunden werden können, steigt die im Netzwerk erreichbare Menge an Inhalten erheblich
- In Reticulum werden zusätzliche Verbindungen automatisch zu redundanten Pfaden
- So könnte etwa ein lokales Mesh im Raum Minneapolis mit einem lokalen Mesh im Raum Chicago über das Internet verbunden werden
- Später könnte ein separater Betreiber zusätzlich eine direkte Mikrowellen- oder LoRa-Verbindung zwischen beiden Städten aufbauen
- Im Normalbetrieb ließe sich dann der schnellere Internetpfad nutzen
- Bei einem Ausfall könnte ein alternativer oder provisorischer Pfad nahtlos denselben Routing-Pfad im Reticulum-Netz übernehmen
- Selbst ein lokales Reticulum-Mesh ohne jede Verbindung zu anderen Reticulum-Netzen behält im schlimmsten Fall zumindest den Zugang zu lokalen Inhalten
- Das entspricht ungefähr dem Maximum dessen, was sich mit Meshtastic und MeshCore realistischerweise erreichen lässt
Verbindungen über Grenzen und Frequenzunterschiede hinweg
- Reticulum ermöglicht grenzüberschreitende Verbindungen
- Bei LoRa ist problematisch, dass je nach Rechtsraum unterschiedliche Frequenzen genutzt werden
- In den USA arbeitet es auf 915 MHz mit bis zu 1 W
- In weiten Teilen Europas auf 868 MHz oder 433 MHz mit geringerer Leistung
- In Asien unter anderem auf 923 MHz
- Deshalb können Meshtastic- oder MeshCore-Netze in Asien nicht nativ mit solchen in Europa verbunden werden
- Zwar lässt sich das mit Bridges wie MQTT umgehen, doch Reticulum kann unterschiedliche LoRa-Netze nativ verbinden, solange es gemeinsame Gateway-Punkte gibt
- Ein 868-MHz-Funkgerät in einem Land kann über eine Glasfaserverbindung mit einem 923-MHz-Funkgerät in einem anderen Land verbunden werden
- Ebenso lassen sich 2,4-GHz-Mikrowellenlinks, das Internet oder Packet Radio verwenden
- Schon ein oder mehrere Verbindungspunkte reichen aus, damit Reticulum-Routing zwischen unterschiedlichen physischen Netzen ohne zentralen Server nahtlos funktioniert
- Netzbetreiber können ohne zentrale Abstimmung Netzsegmente nach ihren Vorstellungen aufbauen, und sobald sich diese Segmente verbinden, übernimmt Reticulum die Konvergenz des Netzes automatisch
- Der Adressraum von Reticulum ist global, und jeder Knoten besitzt eine durch Kryptografie abgesicherte eindeutige Adresse
- Adressüberschneidungen zwischen verschiedenen Reticulum-Netzen sind ausgeschlossen, und es braucht keine zentrale Stelle wie IANA, ARIN oder RIPE zur Adressvergabe
Das Anwendungsökosystem von Reticulum
- Die Stärke von Reticulum endet nicht beim Netzwerk selbst; es gibt auch ein Ökosystem von Apps, die darauf aufbauen
- NomadNet ist eine der verbreitetsten Anwendungen
- Es bietet Messaging, Dateifreigabe und textbasiertes Browsing in einer Terminal-App
- Mausunterstützung ist ebenfalls vorhanden
- Nutzer, denen die Terminal-Nutzung zu aufwendig ist, können Sideband nutzen, eine GUI-App für Android und PC
- Auch Meshchat kann für Kommunikation verwendet werden, daneben gibt es weitere Apps, die Reticulum nutzen
- Mehrere Kommunikations-Apps können miteinander zusammenarbeiten, sodass Nutzer die App ihrer Wahl verwenden können
- Auf Reticulum lässt sich nahezu jede App oder jedes Protokoll aufbauen, viele Messenger verwenden jedoch einige eigene Protokolle wie LXMF, LXST, RRC quasi als Standard
- Für Reticulum existiert bereits ein App-Ökosystem, das weitgehend dasselbe Basisprotokoll teilt und Messaging-Funktionen ähnlich denen von Meshtastic- und MeshCore-Apps bietet
Das größte Problem von Reticulum
- So stark Reticulum als Plattform für öffentliches Mesh-Networking auch ist: Die große Schwäche, die es derzeit daran hindert, öffentliche MeshCore- und Meshtastic-Netze zu ersetzen, liegt nicht bei den Apps oder der Software selbst
- Das Kernproblem ist, dass es anders als Meshtastic und MeshCore keine dedizierte Firmware für LoRa-Funkgeräte besitzt
- Installiert man Meshtastic auf einem günstigen Gerät wie dem Heltec V3, wird es zu einem eigenständigen Meshtastic-Knoten, der Nachrichten senden und empfangen und Daten für das gesamte Netzwerk weiterleiten kann
- Auch bei Reticulum lässt sich dieselbe günstige Hardware mit der RNode-Firmware für LoRa-Verbindungen verwenden
- Die RNode-Firmware von Reticulum arbeitet jedoch nicht als eigenständiger Mesh-Knoten, sondern eher als LoRa-Modem für einen angeschlossenen Computer
- Das RNode selbst ist nicht intelligent und muss mit einem Computer verbunden sein, auf dem Reticulum läuft, um Nachrichten zu senden, zu empfangen und an andere Knoten im Reticulum-Netz weiterzuleiten
Unterschiede bei Endgeräten und Infrastruktur
- Für gewöhnliche Nutzer muss die RNode-Struktur kein echtes Problem sein
- Auch bei Meshtastic wird nur selten direkt ausschließlich über eigenständige Geräte kommuniziert; Geräte wie das LILYGO T-Deck sind eher die Ausnahme
- Die meisten Nutzer verbinden ein Meshtastic-kompatibles LoRa-Funkgerät mit einem Telefon oder Computer
- Da Telefone und Computer leistungsfähig genug sind, können sie bei einem Wechsel Reticulum ausführen, während sie mit einem RNode verbunden sind
- Problematischer wird es im Bereich der Infrastruktur
- Bei Meshtastic und MeshCore installieren viele Nutzer fernzugängliche, solarbetriebene Knoten auf Hügeln oder Gebäuden, um die Netzkapazität zu erhöhen
- Bei Reticulum benötigen solche entfernten Knoten nicht nur ein LoRa-Funkgerät mit RNode, sondern auch einen Computer, auf dem Reticulum läuft und der die Mesh-Funktion übernimmt
- Dieser Computer kann zwar so einfach wie ein Raspberry Pi Zero sein, doch zusätzliche Kosten und Stromverbrauch sind für unbeaufsichtigte Installationen, besonders mit Solarstrom, eine Belastung
- Es gibt aber Fortschritte bei der Lösung dieses Problems
- Ein microReticulum-Port für Geräte ab ESP32 wird weiterentwickelt
- Wenn bestehende Meshtastic- und MeshCore-Betreiber ohne zusätzliche Hardware auf Reticulum-Routing umsteigen könnten, könnte das die Einführung leistungsfähigerer öffentlicher Mesh-Netze deutlich beschleunigen
Wofür die drei Ansätze jeweils geeignet sind
- Reticulum ist eine Lösung, mit der sich kleine lokale und große Netzwerke aufbauen und organisch zu einem nahtlosen globalen Mesh verbinden lassen
- Meshtastic eignet sich gut für Wandergruppen, die statt Sprach-Walkie-Talkies einfach Text und GPS austauschen wollen
- MeshCore bietet attraktive Funktionen für lokales oder nachbarschaftliches Messaging sowie für Off-Grid-Messaging bei großen Veranstaltungen wie der DEF CON
- Viele Gruppen versuchen, öffentliche Meshtastic-Netze im Maßstab einer ganzen Region oder darüber hinaus aufzubauen, doch für dieses Szenario ist es eher die falsche Lösung, und in der Praxis sind Mesh-Ausfälle und Kommunikationsprobleme häufig
- Es ist ein Unterschied, ob man nur die Existenz benachbarter Knoten erkennt oder tatsächlich mit ihnen interagiert
- Reticulum bietet über Messenger-Apps oder den Austausch von GPS- und Sensordaten hinaus eine umfassende Netzwerkgrundlage, die eher einer Alternative zum Internet selbst nahekommt
- Auch wichtige Anwendungen, die in Meshtastic und MeshCore schwierig sind, werden möglich
- Über Retipedia kann Nutzern von Reticulum der Zugriff auf Kiwix-Dateien einschließlich der gesamten Wikipedia bereitgestellt werden
- Das kann in Katastrophensituationen für den schnellen Informationsaustausch nützlich sein
1 Kommentare
Hacker-News-Kommentare
Ich habe seit letztem Dezember mit Meshtastic experimentiert, aber bisher ist das Netzwerk so still, dass ich das vom Autor betonte Überlastungsproblem nicht erlebt habe.
Laut meshmap sollte es einen Node etwa 2 Meilen von meinem Haus entfernt geben, aber er ist nicht zuverlässig sichtbar, und auch der nächste Node in 4,3 Meilen Entfernung ist nicht zu sehen. Eine Zeit lang war ein Node in ungefähr 8,4 Meilen Entfernung ein paar Tage lang sichtbar und verschwand dann wieder. Seit Weihnachten hat mein Node 583 Nodes gesehen, aber kein einziger war stabil.
Mein Node ist ein solarbetriebener Node, den ich etwa 25 Fuß hoch in einen Baum gehängt habe, und ich pendle im Südosten von Michigan normalerweise etwa 30 Minuten bis in eine Vorstadtstadt. Der Artikel war gut, hat aber eher mein Vertrauen in Meshtastic gestärkt, und es gibt keinen Bedarf, einen Computer an den Node anzuschließen oder für MeshCore-Funktionen zu bezahlen. Ich wünschte mir nur mehr feste Nodes zum Ausbau des Netzwerks.
MeshCore ist zu 100 % kostenlos. Das letzte Problem war, dass die Android-/iPhone-Clients Closed Source waren, aber es gibt einen Open-Source-Client auf Flutter-Basis: https://github.com/zjs81/meshcore-open
Nahegelegene Nodes waren nur selten sichtbar, und die tatsächliche Kommunikation kam nicht über ein einfaches „HELLO“/„ACK“ hinaus. Für Dinge wie verteilte Sensornetze auf dem eigenen Grundstück oder andere IoT-Kommunikation ist das interessant, aber als Plattform für menschliche Kommunikation ist es nicht praktikabel und aus meiner Sicht besonders für Katastrophensituationen ungeeignet.
Ich wohne in einer dicht besiedelten Innenstadt, und trotzdem gibt es in meiner Nähe nur sehr wenige Nodes, sodass man wohl auf dem Trockenen sitzen bleibt. Ohne ein richtiges Mesh dürfte es schwer sein, selbst einem Freund in 2 Meilen Entfernung ohne Sichtverbindung eine Nachricht zu schicken.
Ich finde, dieser Artikel verpasst einige wichtige Punkte.
Erstens: Wenn ein Mesh das Internet oder andere Transportmittel nutzen kann, wird es sie am Ende auch nutzen, und es wird in einer Form aufgebaut werden, in der solche Mittel erforderlich sind. Wenn man nur eine neue, unkomplizierte Möglichkeit will, Freunden Textnachrichten zu schicken, dann ist so etwas wie Reticulum vielleicht in Ordnung. Wenn man aber eine ernsthafte Lösung für Katastrophenschutz und freie Kommunikation will, also Kommunikation, bei der „mich niemand stoppen oder meine Äußerungen kontrollieren kann“, dann ist es sehr wichtig, sie von Anfang an unabhängig aufzubauen.
Zweitens hat der Autor auch eine wichtige Funktion von MeshCore übersehen. Selbst bei Stromausfall läuft das Mesh-Netzwerk weiter. Das ist für Notfallvorsorge und Katastrophenwiederherstellung enorm wichtig, besonders in Regionen mit häufigen Naturkatastrophen. Es steht noch ganz am Anfang und hat noch einen langen Weg vor sich, aber ich halte ein vollständig dezentrales solarbetriebenes Netzwerk für eine sehr wichtige einfache Alternative zum zu Konzernriesen gewordenen Internet.
Die Reichweite ist sehr begrenzt, und schon nach wenigen Hops bricht der Durchsatz massiv ein. Allein diese beiden Faktoren reichen aus, um das Ganze von vornherein als Spielzeug einzustufen.
Wenn man mesh* in irgendeiner Form als skalierbares und zuverlässiges Transportmittel positionieren will, gibt es bereits lizenzfreie Funkgeräte mit größerer Reichweite, und das wäre der bessere Ausgangspunkt.
Dass ein Mesh bei Stromausfall weiterläuft, ist kein Alleinstellungsmerkmal von MeshCore und auch keine Garantie. Jedes Gerät mit Solarversorgung und Batterie-Backup kann theoretisch ohne Netzstrom laufen. MeshCore-Nodes sind nicht standardmäßig solarbetrieben, und dasselbe Solarkonzept lässt sich auch auf andere Funktransceiver oder Protokolle anwenden.
Ist das Internet wirklich so? Die Konzernriesen wurden auf der Ebene des World Wide Web darauf aufgebaut, aber das Internet selbst wirkt vergleichsweise neutral.
Ich habe meine Karriere bei Netzbetreibern und im Networking verbracht und mochte die Zeit, als Wi‑Fi aufkam. Als die Frequenzen sauber waren, habe ich beeindruckende Langstreckenverbindungen hinbekommen, mit denen ich sogar vor Freunden aus dem 3G-/Mikrowellen-Backhaul-Bereich angeben konnte, und ich verfolge LoRa und verwandte Technologien weiterhin.
Ich habe auch ein paar HelTec-Boards, aber die jüngeren Entwicklungen wie Meshtastic/Core erinnern mich an die frühe Wardriving-Community oder an CB-Funk: spaßig und voller Ideen, aber mit zu wenig Struktur oder Breitenattraktivität, um wirklich groß zu werden.
Trotzdem würde ich mir einen brauchbaren Notfall-Mesh-Standard wünschen, am besten einen internationalen Standard.
Angenommen, es gibt ein Mesh-Netzwerk — und dann? Man kann anderen Nerds Nachrichten schicken, aber was genau will man ihnen eigentlich schicken? Deshalb ist auch der Amateurfunk wohl irgendwann auf Contesting, Morse-Challenges und den Austausch von Gerätespezifikationen geschrumpft. Es gibt einfach nichts zu sagen.
Das größte Problem von Mesh-Netzwerken ist vielleicht nicht technisch, sondern sozial. Wenn es auch nur für 0,1 % der Bevölkerung, also für Nerds, einen nützlichen Zweck gäbe, wäre das schon großartig, und breite Massenattraktivität würde wahrscheinlich eher Probleme schaffen als wünschenswert sein.
Genau das zeigen Mesh-Netzwerke, und je schlimmer die Situationen sind, in denen Menschen sich vorstellen, dass solche Technologien nützlich wären, desto eher neigen sie dazu, gerade dann am schlechtesten zu versagen.
Die einleitende Bemerkung, dass bei Meshtastic und MeshCore viele Funktionen weggelassen würden, passt zu meinem allgemeinen Eindruck, den ich jedes Mal bei Mesh* habe.
Es ist coole Funktechnik und ein unterhaltsames Spielzeug, um Nerds in der Nähe zu finden, aber darüber hinaus fallen sofort gravierende Probleme auf, die einem Wachstum im Weg stehen. Für kleine spezialisierte private Netze ist es okay, aber es wirkt eher wie eine Technikdemo als wie etwas, das dafür ausgelegt ist, in der Praxis lange durchzuhalten.
Als Ausgangspunkt braucht man so etwas, und es funktioniert auch jetzt schon, aber große Erwartungen habe ich nicht.
Die Leute, die man im Mesh trifft, sind tatsächlich echte, atmende Nerds, und allein weil sie in der Nähe sind, hat man vieles gemeinsam. Sie wollen dich weder beeinflussen noch dir etwas verkaufen.
Wie viele solche Orte gibt es heute noch?
Es gibt Nischen wie private Netze, lokale Nerd-Netzwerke oder Notfallreaktion, und die tatsächlichen Rettungskräfte sind nach meiner Erfahrung in der Community nicht gerade die Gruppe, die so etwas am offensivsten ausprobiert. Je nachdem, wen man fragt, kann all das ein Vorteil oder ein Nachteil sein.
Ich halte es durchaus für möglich, in einem kleinen Wohnviertel mit einem drahtlosen Mesh-Netzwerk Internet zu teilen und dabei eine Erfahrung zu liefern, die der Standardlösung ziemlich nahekommt.
Dieses Thema war hier in den letzten Tagen oder Wochen mehrfach zu sehen, und ich habe mich schließlich entschieden, einen Seeed Studio Wio Tracker L1 Pro für MeshCore zu kaufen.
Die Idee eines Quasi-Internets, das gerade schnell genug ist, um textbasierte Inhalte über ein einziges Medium zu übertragen, finde ich sehr reizvoll. Da spielt sicher Nostalgie mit hinein, aber auch eine nüchterne Einschätzung. Wenn ein Netzwerk zu langsam ist, um Fotos, Audio und Video zu verschicken, dann vermeidet es Probleme wie Spam und illegale Pornografie womöglich auf elegante Weise schon durch sein Design.
Ein paar Mesh-Knoten aufzustellen, Tests laufen zu lassen und dann zu glauben, man habe ein Kit für den Notfall, erinnert an die vielen Disaster-Recovery-Übungen, die wir alle erlebt haben. Solche Übungen, die nur Idealbedingungen annehmen.
Wie wenn man jeden Tag vorbildlich Tape-Backups gemacht hat, aber im Bare-Metal-Recovery-Fall merkt, dass niemand Installationsmedien fürs OS bereitgelegt hat oder dass die Installationsdateien und Lizenzschlüssel der Backup-Software im Rechenzentrum lagen und deshalb zu spät unbrauchbar sind.
Die Schwierigkeit bei solchen Mesh-Systemen ist, dass es kaum Regionen gibt, die weit genug sind, um realistische Übungen durchzuführen, bei denen die Kommunikation tatsächlich von diesem System abhängt.
Es ist ein interessantes Experiment, aber in mancher Hinsicht fühlt es sich für mich auch wie ein Schritt zurück an. Meshtastic und MeshCore sind Messaging, und genau das macht sie zur standardisierten Killer-App.
Reticulum löst einen zwar von der Bindung an LoRas schmalbandigen Funk und scheint viele coole Funktionen zu haben, aber wenn man die gesamte Netzwerkschicht neu erfindet, muss man auch Dienste, Discovery-Verfahren und so weiter neu bauen. Am Ende wird sich alles daran entscheiden, ob man die Backbone-Bandbreite kontrollieren kann, und wenn man darauf noch die zusätzliche Schwierigkeit eines P2P-Meshs setzt, frage ich mich, ob das nicht vergeudete Zeit ist.
Immer mehr fühlt sich das zwar wie eine unterhaltsame Beschäftigung an, realistisch aber auch wie eine Selbstberuhigung angesichts einer Welt, in der sich leider alles zentralisiert.
Eine Sache, die mir an Technik wie MeshCore gefällt, ist, dass direkte Kommunikation zwischen Endgeräten nahtlos möglich ist.
Wenn zwei begleitende MeshCore-Geräte in der Nähe sind, können sie ohne Relais direkt Nachrichten austauschen.
Zwei moderne Smartphones dagegen können ohne Wi‑Fi-AP oder Mobilfunkabdeckung mit gewöhnlichen Messaging- oder Datentransferdiensten nur schwer direkt miteinander kommunizieren. Es gibt zwar Wege über Bluetooth oder mobile Wi‑Fi-Hotspots, aber das wirkt eher wie widerwillig angeflanschte Funktionen als wie etwas, das die großen mobilen Betriebssystem- und Hardwareanbieter wirklich gut und einfach nutzbar unterstützen.
Letztes Wochenende habe ich einen Solar-Knoten installiert. Jetzt komme ich auf 200 Meilen Reichweite. Nerds, verrückte Ideen, gute Zeiten.
Ich habe mich gefragt, ob es legal wäre, einfach ein paar an beliebige Bäume zu werfen.
Nachdem ich heute den Gemini-, Gopher- und Finger-Beitrag gesehen habe https://news.ycombinator.com/item?id=48297467, frage ich mich, ob das gut zu Reticulum passen würde.
Vieles von dem, was Finger, Gopher usw. leisten, besteht darin, Semantik auf Anwendungsebene zu definieren, um Dokumente über streamorientierte Protokolle zu übertragen.
Allerdings gibt es in Reticulum bereits eine aktive eigene „kleine Web“-Implementierung mit NomadNet und dem Micron-Markup.
Ich habe erst letzten Monat angefangen, Meshtastic auszuprobieren, aber in meiner Stadt macht das sonst niemand, also verteile ich esp32 an Freunde und baue mir mein Mesh selbst auf.
Allerdings kenne ich nicht genug Leute, um genug Verbindungen dazwischen zu schaffen, und stoße deshalb an Entfernungsgrenzen.
Ich habe auch versucht, das Funk-Preset auf Very Slow Long umzustellen, aber die Reichweite wurde dadurch kaum besser, und ich weiß nicht, warum.
Ich halte das für eine großartige Entwicklung. Gleichzeitig mache ich mir Sorgen, dass es offenbar auch bei Kriminellen beliebt werden dürfte.
Bei solchen neuen Technologien gibt es immer ein Katz-und-Maus-Spiel. Ich kenne die Interna dieser Technik nicht gut genug, um weitergehende Vermutungen anzustellen.