MunichMesh.de

Ob es jetzt um die Karte oder das Forum geht macht keinen großen Unterschied. Am Ende speicherst und veröffentlichst du Daten, die du nur sehr begrenzt unter Kontrolle hast. Außerdem erhebst du hier impliziert den Anspruch auf "ganz München". Das ist schon mehr als nur ein kleiner privater Kreis.

Da kann alles mögliche dabei sein. Illegale Inhalte, personenbezogene Daten etc. Du musst als Betreiber greifbar sein, damit man dich in die Verantwortung nehmen kann. z.B. Löschung falls jemand versehentlich oder böswillig die Standorte, Bewegungsprofile, Telefonnummer eines Anderen ins Mesh sendet und diese jetzt bei dir öffentlich zugänglich verewigt sind.

Mir geht es hauptsächlich darum, dass du nicht versehentlich oder aus Naivität in Schwierigkeiten gerätst. Ich denke du weißt jetzt Bescheid mit welchen Themen du dich beschäftigen solltest.

Es liegt an dir als Betreiber der Seite(n) deine persönlichen Risiken zu kennen, bewerten und minimieren. z.b. durch vernünftige Rechtsberatung zu DSGVO, Impressum, Disclaimer, AGBs usw. Du kannst es auch darauf ankommen lassen und warten bis jemand klagt/abmahnt und dann hoffen, dass das Gericht deine Interpretation bzw. die von abmahnung.org teilt. Das wäre mir persönlich aber zu stressig.

Vllt findet sich hier ja noch jemand mit rechtlichem Background, der eine professionelle Meinung abgeben kann.

Ich bin neu in dem Thema und etwas verwirrt. Es gibt laut der Kanaldatenbank wohl zwei Kanal-Konfigs mit München-Bezug.

"RaumMUC" mit dem Key: DasPasswortHierIstNurA==
und
"[DE] Munich" mid dem Key: mjw1yMZmrQSkL8BNH+3egZ1jt3cEVfiEVdn89AfAkqc=

Wie unterscheiden sich diese? Und welche Konfig gehört nun zu dieser Community?

Ich würde auch gerne verstehen, ob die Channel-Konfiguration des QR-Codes bewusst so gewählt wurde.

{
  "settings": [
    {
      "psk": "DasPasswortHierIstNurA==",
      "name": "RaumMUC",
      "uplinkEnabled": true,
      "downlinkEnabled": true,
      "moduleSettings": {
        "positionPrecision": 16
      }
    }
  ],
  "loraConfig": {
    "usePreset": true,
    "bandwidth": 250,
    "spreadFactor": 11,
    "codingRate": 5,
    "region": "EU_868",
    "hopLimit": 7,
    "txEnabled": true,
    "txPower": 27,
    "sx126xRxBoostedGain": true,
    "ignoreMqtt": true
  }
}

Zum Vergleich folgt die Link-Konfiguration von Mesh Hessen, die das modemPreset "SHORT_SLOW" nutzen.

{
  "settings": [
    {
      "psk": "+uTMEaOR7hkqaXv+DROOEd5BhvAIQY/CZ/Hr4soZcOU=",
      "name": "Mesh Hessen",
      "uplinkEnabled": true,
      "downlinkEnabled": true,
      "moduleSettings": {
        "positionPrecision": 16
      }
    }
  ],
  "loraConfig": {
    "usePreset": true,
    "modemPreset": "SHORT_SLOW",
    "region": "EU_868",
    "hopLimit": 7,
    "txEnabled": true,
    "txPower": 27,
    "overrideDutyCycle": true,
    "sx126xRxBoostedGain": true,
    "configOkToMqtt": true
  }
}

Die erste Hälfte der Settings ist soweit identisch (abgesehen von psk und name).
Bei der LoraConfig gibt es jedoch Unterschiede.

Anstatt "modenPreset" wird in unserem Link "bandwidth", "spreadFactor" und "codingRate" explizit angegeben. Das ist vermutlich auch gut so.

Warum in Hessen "overrideDutyCycle": true verwendet wird, kann ich mir nicht erklären. Mehr dazu hier: https://meshtastic.org/docs/configuration/radio/lora/#override-duty-cycle-limit

Während wir "ignoreMqtt": true seten, nutzt Hessen "configOkToMqtt": true. Ich bin mir hier nicht ganz über die Implikationen klar.

Sie nutzen "SHORT_SLOW" statt "LONG_FAST" (entspricht unserer Konfig), da ihr Mesh wohl überfordert war mit der Anzahl der Knoten auf engem Raum. Sollten wir in München oder sogar Bayern nicht lieber so früh wie möglich auf SHORT_SLOW setzen, damit wir uns in Zukunft Frustration und eine mühsame Umstellung ersparen? Mehr zum Thema hier: https://meshtastic.org/blog/why-your-mesh-should-switch-from-longfast/. oder hier https://26269.de/meshtastic-boomt-kommt-aber-ins-stolpern/.

Den Link-Decoder um an die Konfig zu kommen findet man übrigens hiert: https://meshlink.elebree.com/