Regions sind die geografischen Festlegungen, die in Repeatern eingetragen werden.

Ein Scope ist der geografische Reichweitenwunsch, den der Anwender einer Message zufügt.

Ein Repeater leitet eine Message weiter, wenn ihr beigefügter Scope in seiner Region-Liste zu finden ist.

Auf jedem Repeater ist standardmäßig die Wildcard-Region * (Stern) hinterlegt und aktiviert. Diese sorgt dafür, dass Pakete OHNE Scope auf jeden Fall weitergeleitet werden.

Das Matching des Scopes auf die Region geschieht über einen 1:1 Vergleich eines vom Namen der Region abgeleiteten Keys. Es findet kein „String-Matching“ statt und auch kein Teilstring-Matching. (Scope #de-he ist NICHT in Region #de enthalten.)

• Länge maximum 30 bytes (UTF-8).
• Nur Kleinbuchstaben, # (Hash) und - (Bindestrich)
• Regions müssen im Netz eindeutig sein.
• Regions und Scopes matchen nur exakt (1:1), es gibt kein „Teilmatch“ anhand des Namens. Hierarchische Strukturen müssen über jeweils eigene Regions abgebildet werden.
• Die Anzahl der Regions auf dem Repeater ist auf 32 begrenzt, ABER: Beim Auto-Discover der Regions können nur 172 Zeichen übertragen werden. Alles Weitere wird abgeschnitten. Es ist daher sehr zu empfehlen, die Anzahl der Regions und deren Namen so klein wie möglich zu halten. Die abgeschnittenen Regions sind im Repeater trotzdem aktiv. Wenn der Nutzer diese kennt, kann er sie trotzdem nutzen. Sie werden lediglich nicht im Auto-Discover angezeigt.

• Ripple Blog - Region Filtering
• YouTube-Video mit Erklärung/Vorstellung

Mit Firmware 1.11.0 sind Regions/Scopes enthalten (sowohl Repeater, als auch Companions).

Mit App-Version 1.38.0 können in den Channels nun auch Scopes angegeben werden.

In einer zukünftigen Firmware- und App-Version soll ein Auto-Discover der Regions im Umkreis möglich sein (siehe Blog-Beitrag).

Die Diskussion in der deutschen Telegram-Gruppe (Link hier einfügen) brachte einige wiederkehrende Erkenntnisse zu Tage:

• Eine zu feingranulare Aufteilung der Regions (runter zu Stadt/Ortsteil) macht keinen Sinn, weil
  • … zum Weiterleiten der Nachrichten dann auch entsprechende Repeater mit genau diesen Regions (z.B. im Ortsteil) vorhanden sein müssen
  • … die Konfiguration der Repeater exorbitanten Aufwand erzeugen würde, den JEDER Repeater-Betreiber tun müsste

• Eine Nutzung vorhandener geografischer Klassifizierungen ist sinnvoll, die Auswahl der passenden und einzig Richtigen aber schwierig. Besprochen wurden:
  • PLZ → Kann sich jeder was drunter vorstellen. Alle 5 Stellen sind zu feingranular, eine Beschränkung auf die ersten beiden Stellen als „Zone“ wäre ausreichend. Es gibt aber auch Städte, die in mehreren Zonen liegen. Es ist schwer abzuschätzen, welche Reichweite die Zone z.B. „84“ hat.
  • ISO → Geht nur bis Bundesland. Ein einheitlicher Code für Landkreise gibt es nicht.
  • KFZ-Kennzeichen → Da es inzwischen pro LK mehrere mögliche Kennzeichen gibt, gibt es hier keine Eindeutigkeit.
  • IATA-Code → Zu grob und zu ungleichmäßig über DE verteilt. Kennt außerdem kaum jemand.
  • EBU-Code → Sehr unbekannt.
  • Locator → Eher nur bei den Funkamateuren gebräuchlich. Lässt sich schwer abschätzen, welche Reichweite der Locator z.B. „JO40“ hat.
  • AGS (Gemeindeschlüssel) → Eher unbekannt

• Regionen mit lokaler Bedeutung lassen sich über diese Schemata meist nicht abbilden. Z.B. „Region Hannover“ oder „Rhein-Main“.

• Es wird nicht „das eine Schema“ geben, was jeder versteht und alle Wünsche/Anforderungen auch regionaler Interessen erfüllt.

Folgender Vorschlag wurde mehrfach in der Diskussion angebracht und mehrheitlich für gut befunden.

Um eine grundlegende geografische Eingrenzung des Flood-Verhaltens zu erreichen, werden die Ebenen „Land“ und „Bundesland“ in jedem Repeater als Regions konfiguriert. Das Namensschema folgt der ISO 3166-2. Wenn jeder Repeater in Deutschland diese Basis-Regionen konfiguriert hat, können die Nutzer einigermaßen sicher und nach immer gleichem Schema ihre Nachrichten zumindest auf Deutschland und das jeweilige Bundesland einschränken. Alleine das würde Flood-Nachrichten nachhaltig verringern.

Die Regions würden gemäß ISO folgendermaßen lauten:

ZUSÄTZLICH zur Basis-Konfiguration können regional weitere Regions erstellt werden. Das Namensschema und die Information an die Repeater-Betreiber unterliegt dann den regionalen Communities. Möglich wären dann z.B. folgende Regions:

Ein Repeater in Rüdesheim am Rhein (Nahe der Grenze HE/RP) könnte folgende Regionen haben:

#de
#de-he
#de-rp
#rheingau
#taunus
#rhein-main
#plz-65

Über die CLI (per USB oder remote über den Companion) lassen sich die Regions im Repeater verwalten. Dazu gibt es folgende Kommandos:

> region
  *^ F
  -> OK

Mit dem Befehl region werden die auf dem Repeater konfigurierten Regionen angezeigt. Bei einem „frischen“ Repeater wird nur die Wildcard-Region (Stern) angezeigt.
Das ^ (Dach) hinter dem Stern bedeutet, dass dies aktuell die Home-Region ist. Das F am Ende bedeutet, dass hier „Flooding“ und damit diese Region aktiviert ist. Regionen ohne F sind daher deaktiviert und werden nicht weitergeleitet.

> region load
>  #de F
>   #de-he F
>
  -> OK - loaded 2 regions

Mit dem Befehl region load kann man nachfolgend zeilenweise eine Liste der Regionen über die CLI eingeben, die dann die bestehende Liste auf dem Repeater überschreibt! *Der Befehl wird NICHT dazu verwendet, die Regions aus dem Speicher des Repeaters zu laden!* Im Beispiel oben würde man die Regionen #de und #de-he hinzufügen und beide mit F direkt aktivieren. Wichtig zu beachten sind die Leerzeichen vor den Regionen, die die Hierarchie ausdrücken. So hängt #de unter der Wildcard-Region und #de-he unterhalb #de Soweit bekannt, dienen die Hierarchien nur der optischen Anzeige, sie haben KEINEN Einfluss auf das Matching der Scopes.

> region load
>
  -> OK - loaded 0 regions

Ein region load mit direkter Leezeile dahinter, lädt KEINE Region und löscht die interne Region-Liste!!

> region put #de
  -> OK

> region put #de-he #de
  -> OK

> region remove #de
  -> Err - not empty

> region get #de
  #de F
  -> OK

> region remove #de-he
  -> OK

Mit dem Befehl region put kann man eine einzelne Region zur Liste hinzufügen.
Als ersten Parameter gibt man den Namen der neuen Region an.
Der zweite Parameter für den „parent“ ist optional. Lässt man ihn weg, wird die neue Region automatisch unter die Wildcard-Region gehängt. Mit der Parent-Region kann man die Regionen hierarchisch ablegen, was rein der Optik dient und keinerlei Auswirkungen auf das Matching hat. Jede Region zählt trotz Hierarchie für sich alleine und der Name wird mit dem Scope 1:1 gematcht. #de und #de-he haben keinerlei Beziehung zueinander, auch wenn der Name das „logisch“ vermuten lässt.

Mit dem Befehl region remove kann man eine einzelne Region wieder von der Liste löschen.

Mit dem Befehl region get kann man die Infos zu einer einzelnen Region abrufen, oder prüfen, ob diese existiert.

> region allowf #de
  -> OK

> region
 *^ F
  #de F
  -> OK

> region denyf #de
  -> OK

> region
 *^ F
  #de
  -> OK

Mit region allowf kann man eine Region aktivieren. In der Region-Liste erscheint dann ein F hinter dem Namen. Nur wenn die Region aktiviert ist, werden Nachrichten mit diesem Scope weitergeleitet.
Mit region denyf kann man die Region entsprechend deaktivieren.

Es ist auch möglich die Wildcard-Region zu deaktivieren. Damit wird das Weiterleiten von Nachrichten OHNE Scope deaktiviert. Diese Einstellung sollte auf keinen Fall aktiviert werden, da sonst eine Großzahl der Nachrichten im Netz nicht weitergeleitet werden.

> region save
  -> OK

Damit alle über die CLI gemachten Änderungen auf dem Repeatern gespeichert werden und nach einem Reboot zur Verfügung stehen, muss unbedingt ein region save ausgeführt werden. Am besten nach jeder einzelnen Änderung durchführen, um nicht aus versehen die ganze Arbeit zu verlieren.

> region home
  -> home is *

> region home #de
  -> home is now #de

> region
  * F
   #de^ F

Mit region home lässt sich die aktuelle Home-Region abfragen und setzen. In der Region-Liste erkennt man die Home-Region an dem ^ (Dach) hinter dem Namen.
In der aktuellen Firmware hat die Home-Region keine Bedeutung. Das ist ein Feature, was ggf. mal kommen wird.