Mit den Region-Filtern steht eine wichtige Entscheidung an, die wir besser gemeinsam treffen als jeder für sich – denn das System funktioniert nur, wenn Repeater und Companions den gleichen Regionsnamen verwenden. Wenn einer muc konfiguriert und die andere munich, sehen sich die Pakete nie.
Warum dieser Thread?
Region-Filter erzeugen kryptographische Transport-Codes aus dem Regionsnamen. Jeder Name → eigener Schlüssel → eigener Code. Damit Pakete weitergeleitet werden, muss jeder Repeater auf dem Weg exakt den Regionsnamen kennen, mit dem der Companion gesendet hat.
Das betrifft nicht nur die aktuellen Betreiber – wer neu dazukommt und seinen Repeater oder Companion einrichtet, braucht eine klare Antwort: „Welchen Regionsnamen trage ich ein?"
Wie funktioniert das?
Ein Companion mit konfigurierter Region sendet Transport-Floods. Nur Repeater mit genau diesem Regionseintrag leiten weiter. Die Wildcard * F greift ausschließlich bei Companions ohne Region – sie ist kein Catch-All.
Wichtig: Es gibt kein Parent-Matching. Ein Paket mit Scope de-by-muc matcht nicht auf einen Repeater-Eintrag de-by. Die Namens-Hierarchie ist rein kosmetisch – jeder Name ist kryptographisch unabhängig.
Warum getrennte Regionsnamen problematisch sind
Transport-Codes werden beim Weiterleiten nicht verändert – jeder Repeater auf dem Weg prüft gegen den ursprünglichen Code. Das bedeutet: Getrennte Regionen erzeugen harte Partitionen, keine weichen Grenzen.
Beispiel:
München verwendet
de-by-muc, Augsburgde-by-aug. Selbst wenn ein Repeater an der Grenze beide Einträge hat und ein Münchner Paket weiterleitet – der nächste Augsburger Repeater sieht weiterhin den Transport-Code vonde-by-muc, hat keinen Match und verwirft das Paket. Um Floods durchzuleiten, müsste jeder Repeater in Augsburg auchde-by-muckennen. Das hebt die Trennung komplett auf.
Betroffen davon sind alle Flood-basierten Funktionen: Gruppen-Nachrichten, Adverts und – besonders kritisch – die DM-Pfadsuche. Ohne durchgehenden Flood-Pfad findet ein Companion keinen Weg zum Empfänger, und die Direktnachricht kann nicht gesendet werden. Einen protokollseitigen Bridging-Mechanismus gibt es aktuell nicht.
Konsequenz für die Namenswahl
Solange es kein Region-Bridging gibt, bedeutet jeder unterschiedliche Regionsname eine Netzwerk-Trennung. Die Frage ist also nicht nur „wie nennen wir uns?„ - sondern „mit wem wollen wir kommunizieren können?“.
Verwaltungsgrenzen (de-by, de-by-muc) klingen total systematisch und simpel, bilden aber nicht ab, wie ein Mesh tatsächlich funktioniert – Funkreichweiten und Topografie folgen keiner Landkarte. Ein Community-basierter Name wie isarmesh würde die tatsächliche Gemeinschaft abbilden, keine künstlichen Grenzen ziehen und niemanden ausschließen, der sich in Funkreichweite befindet.
Was wir klären sollten
-
Welchen Regionsnamen verwenden wir gemeinsam?
-
Brauchen wir aktuell eine Unterteilung – oder erzeugt sie mehr Probleme als sie löst?
-
Soll * F in der Übergangszeit auf allen Repeatern aktiv bleiben, damit Companions ohne Region nicht abgehängt werden?
Bin gespannt auf eure Gedanken.