Nachdem der Multi Meshviewer nicht alle Communities umfasst und ziemlich schlecht performt. Haben wir uns mal hingesetzt und was kleines gebaut.
Der Crawler geht auf die Freifunk API und versucht daraus alle Communities automatisch zu finden und baut diese dann auf der Karte automatisiert ein. Alle Livedaten werden dann jeweils aus den Meshviewern, Hopglasses und Grafanas zusammen gebaut.
Vielleicht findet ihr das Projekt interessant.
Sourcecode gibts hier:
schön!
wie habt ihr die Knoten von ffm und da hineinbekommen. Bei der https://freifunk-karte.de fehlen die seit Monaten.
Alles über sehr kreatives parsen und raten der Freifunk API. Es wäre echt schön wenn mehr Communities die pflegen würden :D.
Nice, danke für den Einsatz.
Aaaaber: die Kontakt(!)daten (»Owner« ist vollkommen irreführend) ungefragt zu veröffentlichen, ist ein no-go. Daher …
ffgt@granny:~$ wget -4 -O /dev/null --save-headers http://stats.4830.org/freifunk-rhwd.json
--2026-02-24 22:16:49-- http://stats.4830.org/freifunk-rhwd.json
Resolving stats.4830.org (stats.4830.org)... 87.253.188.148
Connecting to stats.4830.org (stats.4830.org)|87.253.188.148|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2509 (2.5K) [application/json]
Saving to: ‘/dev/null’
/dev/null 100%[===================>] 2.45K --.-KB/s in 0s
2026-02-24 22:16:49 (399 MB/s) - ‘/dev/null’ saved [2509/2509]
ffgt@granny:~$ wget -4 -O /dev/null --save-headers http://stats.4830.org/freifunk-rhwd.json
--2026-02-24 22:28:34-- http://stats.4830.org/freifunk-rhwd.json
Resolving stats.4830.org (stats.4830.org)... 87.253.188.148
Connecting to stats.4830.org (stats.4830.org)|87.253.188.148|:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Username/Password Authentication Failed.
ffgt@granny:~$ wget -6 -O /dev/null --save-headers http://stats.4830.org/freifunk-rhwd.json
--2026-02-24 22:28:47-- http://stats.4830.org/freifunk-rhwd.json
Resolving stats.4830.org (stats.4830.org)... 2a06:e881:1709:1111:0:57ff:fefd:bc94
Connecting to stats.4830.org (stats.4830.org)|2a06:e881:1709:1111:0:57ff:fefd:bc94|:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Username/Password Authentication Failed.
… sind nur noch legitime Abrufe zulässig. Wir zeigen die Kontaktdaten ausdrücklich nicht auf unseren Karten an und auch nicht auf den Statusseiten der Knoten (dort findet sich bei hinterlegten Daten nur eine Aliasadresse). Offensichtlich müssen wir diese Daten leider also doch schon auf den Knoten verschlüsseln — bis dahin gibt’s notgedrungen den Datenzugriff auf die Daten gem. API eben nur noch per Whitelist, schade.
EDIT: per User-Agent als unkritisch erkannte Abfragen wurden IP-whitelisted, bekannte API-Konsumenten per Mail informiert und um Angabe der Abfrage-IP gebeten.
Außerdem habt Ihr evtl. noch ein Problem im Parser? Wir ziehen derzeit die geographischen Netzgrenzen durch und somit gibt es die selben Knoten in verschiedenen Meshes in on- und offline gleichzeitig; u. a.diese Knoten haben das Mesh gewechselt …
… und sind da auch alive and kickin’:
Obiges Beispiel führt in die Irre, da Bad Oeynhausen alte Daten publiziert; sorry.
Aber ›echtes‹ Beispiel: Freifunk Map vs. https://map03.4830.org/map03/#!v:m;n:98ded0c1d0fa; jener Knoten hat vor >22 Tagen das Mesh gewechselt (vgl. https://map03.4830.org/map02/#!v:m;n:98ded0c1d0fa), und die Daten beider Meshes werden von uns publiziert (API).
FTR, FFMUC vs. 4830.org:
Gibt es irgendwo einen Debug-Möglichkeit, für Communities, die in
drin sind
und auch ein „nodeMaps“ URL gelistet haben, unter der ein gültiges JSOn kommt,
aber deren Knoten nicht erscheinen.
(oder gibt es irgendwo minimum Requirements, z.b. dass "nodelist” nicht mehr gelesen wird, sondern mindestens “meshviewer”?)
Also konkret:
Warum ist
schaffen es die Nodes von dieser nicht auf die Karte:
https://raw.githubusercontent.com/Neanderfunk/communities/refs/heads/master/Flingern-api.json
Gleicher Mapserver liefert aber auch für Wuelfrath aus, die sind auf der neuen Karte.
https://raw.githubusercontent.com/Neanderfunk/communities/master/Wuelfrath-api.json
Die veröffentlicht ihr über die APi die stehen also so oder so im Internet nur FYI, wenn dann müsst ihr sie auch aus dem JSON löschen.
Also dass sie hier dargestellt wurden hat quasi euer Problem veröffentlicht, dass schon lange Bestand.
Die Community flingern hat in ihrer API-Datei den technicalType: "nodelist" mit der URL https://dusfl13.map.ffdus.de/data/nodes.json. Das Format an dieser URL ist aber kein Nodelist-Format (mit id, name, status), sondern das Yanic nodes.json-Format (mit nodeinfo, flags, statistics).
Unser Parser hat die Datei brav als „nodelist“ versucht zu parsen, dabei 0 Nodes rausbekommen (weil die Felder nicht passen), und die Community wurde übersprungen.
Wülfrath funktioniert, weil dort ein zweiter hopglass-Eintrag existiert. Von der Base-URL leiten wir /data/meshviewer.json und /data/nodes.json ab, die dann korrekt erkannt werden.
Fix: Wenn der Nodelist-Parser 0 Nodes liefert, probieren wir jetzt automatisch den nodes.json-Parser als Fallback. Damit werden auch Communities korrekt eingelesen, deren API-Eintrag den technicalType falsch als „nodelist“ deklariert, obwohl es eigentlich nodes.json (Yanic) ist.
Das betrifft wahrscheinlich noch weitere Communities Flingern hat z.B. 71 Nodes die jetzt auftauchen sollten.
Wie wäre denn der korrekte Eintrag für das community file, um so ein hoppglss Yannick zu deklarieren (wenn “nodelist” falsch ist)
Ich habe nun einen Debug Endpunkt eingebaut, der anzeigt welche Quellen verwendet werden:
Ich glaube aus der API wäre “technicalType” hopglass richtig, denn das enthält bei den anderen Communities die nodes.json im richtigen Format.
Wenn man yanic nutzt sind die Output Types TOML Arrays in der Config. Man kann also z.B. mehrere verschiedene meshviewer.json Dateien mit einer yanic Instanz exportieren. Auch mit unterschiedlichen Filtern. no_owner ist dort ein expliziter Filter welchen es gibt.
Wenn man also selbst einen export mit owner (z.B. hinter Auth) haben möchte dann kann man das unabhängig davon machen das man das generell nicht zur Verfügung stellt.
Als Außenstehender betrachtet wirkt die Kritik hier etwas inkonsequent: Wenn Kontaktdaten von einer Community bewusst über eine öffentlich und ohne Authentifizierung erreichbare API ausgeliefert werden und im Konfigurationshinweis sogar ausdrücklich steht, dass diese Informationen öffentlich einsehbar sowie von jedem herunterladbar und verarbeitbar sind, dann ist eine Aggregation durch Dritte technisch erwartbar. Selbst wenn man die zentrale API einschränkt, bleiben die Daten faktisch weiterhin öffentlich zugänglich, da sie über die jeweiligen Knoten-Statusseiten abrufbar sind und sich durch systematisches Crawlen oder schlichtes Scannen der erreichbaren Adressbereiche ebenso automatisiert erfassen lassen. Eine Map, die vorhandene API-Daten auswertet, schafft daher keine neue Veröffentlichungsebene, sondern nutzt lediglich bereits öffentlich exponierte Informationen. Eine nachträgliche Einschränkung dieser Daten widerspricht zudem dem Freifunk-Gedanken: Die Kontaktdaten werden von den Betreibern bewusst hinterlegt, und jede KI, jeder Crawler oder Bot hat sie ohnehin bereits indexiert, sie nachträglich „herauszubekommen“ ist praktisch unmöglich. Wenn bestimmte Felder, insbesondere potenziell personenbezogene Angaben wie das Owner-Feld, nicht extern verarbeitet oder angezeigt werden sollen, müsste das konsequenterweise serverseitig unterbunden werden, etwa durch entsprechende Filter im Monitoring-Stack wie z. B. Yanic. Solange die Daten jedoch offen ausgeliefert werden, erscheint ihre maschinelle Verarbeitung als legitime und technisch naheliegende Nutzung der bereitgestellten Infrastruktur.
Und zum rechtlichen (ist hier jedoch keine Rechtsberatung) 
Aus rechtlicher Sicht greift die Kritik nicht: Die betreffenden Kontaktdaten werden vom Betreiber bewusst auf dem Knoten hinterlegt und über die öffentlich zugängliche API bereitgestellt. Laut DSGVO gelten diese Daten als freiwillig veröffentlicht, wodurch die maschinelle Verarbeitung durch Crawler oder Maps rechtmäßig ist, solange keine Schutzmechanismen umgangen werden. Das Recht auf Löschung besteht jederzeit direkt am Knoten, sodass Betreiber ihre Daten entfernen können. Eine nachträgliche Einschränkung durch Dritte ist technisch nicht durchsetzbar, da die Daten ohnehin über Statusseiten oder Netz-Scans erfasst werden könnten. Solange die Map ausschließlich diese öffentlich bereitgestellten Informationen nutzt, besteht kein Verstoß gegen die DSGVO, und die Verantwortung für die Veröffentlichung liegt primär beim Betreiber des Knotens.
Ich möchte vorschlagen, hieraus NICHT eine neue PPA-Diskussion zu machen. Und wenn doch, evtl. abszuspalten.
Die Veröffentlichung von E-Mail-Adressen seitens der Knotenaufsteller ist Bedingung, damit FReifunk draufstehen darf. Das ist nicht optional!
https://www.picopeer.net/PPA-de.shtml Punkt 2.3
Und das haben wir schon x mal diskutiert.
Wo möchtet ihr denn die Infos von Freifunk-Domains haben, die “wegen der Regeln” nicht in Berlin (bei der großen API) gelistet werden können/dürfen?
Asking for a friend. (Unsere entsprechenden Domains im Neanderfunk habt ihr ja schon gefunden und gelistet (bis auf 2 ;-). Danke dafür.)
Das sehe ich anders, wer in Hauptstraße 1, 12345 Musterstadt wohnt, kann jeder, der dort hinfährt, am Briefkasten sehen. Diese Info bundesweit zu plakatieren ändert auch meiner Ansicht nach nichts an der prinzipiellen Öffentlichkeit der Information; die Frage ist allerdings, ob dieses Vorgehen opportun ist – und unter der DSGVO rechtlich zulässig.
Natürlich ist klar, daß diese Daten da, ja auch aus Gutem Grund™, drin stehen. Bislang hatten die anzeigenden Aggregateure (i. e. freifunk-karte.de) Fingerspitzengefühl gezeigt, genau jene Daten nicht zu veröffentlichen. Aber siehe Dejanews, die Zeiten und die Mitspieler ändern sich, also bleibt’s bei der IP-Whitelist und im nächsten Schritt eine firmwareseitige Änderung, die dieses Problem ein für alle Mal löst (wir brauchen die Daten; wenn Dritte sie ungefragt leichter zugänglich machen, gibt’s diese halt nicht mehr in dem Datensatz).
Ihr macht sie ohne Hindernis schon für alle Suchmaschinen und co zugänglich, jede Suchmaschine, AI Crawler etc hat die schon im Index.
Das hat nichts mit Fingerspitzengefühl zu tun, das war nur Security by Obscurity.
Ein passendes Beispiel sind meines Erachtens öffentliche APIs wie OpenStreetMap oder GitHub. Wer dort freiwillig Daten wie Hausnummern, Standorte oder E-Mail-Adressen hinterlegt, kann diese Daten über die API abrufen oder aggregieren. Niemand würde sagen, dass eine Map, die diese Daten ausliest, eine neue Veröffentlichung darstellt. Sie nutzt, wie jetzt auch z.B. bei den Knoten bzw Kontaktinformationen bereits öffentlich bereitgestellte Daten. Der Vergleich mit einem Briefkasten hinkt mMn ebenfalls, weil die Freifunk-API die Daten maschinenlesbar und, soweit nicht anders von euch/dir @wusel gefirewalled, verfügbar macht, genau wie andere offene APIs.
Dem ist mMn auch nix hinzuzufügen.
Seit geraumer Zeit werden Netze, aus denen Bot- oder unplausible Anfragen kommen, gedroppt. Gerade hat’s Netcup erwischt.
Das Gute ist, das hilft halt auf Dauer nicht. IPs gibts für die großen wie Sand am Meer und User Agents etc sind fakebar.
