Es gab schon einmal einen Aufruf, die API aktuell zu halten.
Wir sind derzeit beim Aufräumen. Einträge mit nicht lesbaren Dateien und die auch nicht per Mail erreichbar sind, wurden bereits gelöscht [1]. Als nächsten folgen die Einträge, welche schon länger als 12 Monate nicht mehr funktionieren (siehe Log).
Das alles soll kein Rausschmiss sein. Nach wie vor ist jeder mit aktuellen Daten willkommen.
[1] PR: https://github.com/freifunk/directory.api.freifunk.net/pull/577
Sagt bitte auch Bescheid, wenn sich die Kriterien für Listungen geändert haben sollten in den letzten 2-3 Jahren, z.B. wenn man wieder „Landstrich“-Communities listen kann, also in ländlichen Regionen nicht willkürlich 5-6 „Orte mit gelbem Schild am Ortseingang“ herausgreifen muss, um dafür dann jeweils ein „Freifunk $ORTSCHAFT“ zu erfinden, nur weil „Freifunk $LANDSTRICH“ nicht gelistet werden darf.
Das Konzept der Freifunk Community Registry (Community Directory) kennt die Begriffe: „Community“ und „Meta Community“ und dass nur „Communities“ eingetragen werden.
Ich nehme an Du meinst mit „Landstrich“ eine „Meta Community“. Diese können nicht direkt eingetragen werden. In Deinem Fall würde es reichen, wenn 5-6 Community API Dateien erstellt werden, die nur die absoluten Basics enthalten + das Feld „metacommunity“ (bei allen der Communities hier bitte den selben Meta Community Namen eintragen). Vermutlich möchtest Du dann bei einer dieser Communities etwas mehr Daten eingeben (wie jetzt auch), z.B. den Ort für Meetings, eine NodeList (für alle Communities dieser Meta Community), etc.
Warum das ganze? Weil wir auf den Landkarten gerne alle Städte anzeigen wollen, wo es Freifunker (lokale Nutzergruppen) gibt. Zudem kann man so automatisiert das Gebiet der Meta Community ermitteln. Selbst wenn die Meta Community „Freifunk Elfenland“ heißt, also keine allgemein (und automatisiert) verarbeitbare Region ist.
Ich kann Dich gerne bei der Erstellung der Community API Dateien unterstützen, falls Du möchtest.
Eigentlich möchte ich das Thema nicht hijacken.
@Olaf 100% Unterstützung für Dein Vorhaben! Weg mit dem alten und toten Zeug.
Das Konzept funktioniert halt so nicht in Flächen-Gegenden ohne echte Metropolen.
Genauso wie das Konzept nicht funktioniert bei überlappenden Communities.
Es ist eine ziemlich zentralistische Denke, die so weit bei vielen an der Realität vorbeigeht, dass sie sie schlicht seit geraumer Zeit ignorieren, weil niemand Lust hat, das lokale Freifunk zu ändern, nur damit es irgendeiner API einer Zentralinstanz von Gatekeeppern in Berlin (oder wo auch immer) gefällt.
Wenn ihr da den Wildwuchs nicht akzeptieren möchtet und eine Regionalisierungs-Pflicht mit starren Stadt/Gemeindegrenzen („Gebietsschutz“) möchtet: Das sei Euch unbenommen. Nur dann wundert Euch nicht, dass das vielen keinen Spass macht.
Was ist eine »Metacommunity«? Anders rum: Auf Sylt finden sich Leute zusammen, die eine eigene, inselweite Community, »Freifunk Sylt« gründen. Eben nicht »Freifunk Kampen« und »Freiifunk Westerland«, sondern »Freifunk Sylt«. Warum können die sich nicht in die API als »Freifunk Sylt« eintragen, sondern müssen Fake-Communities wie eben Kampen oder Westerland erfinden?
Und wieso kann das hypothetische »Freifunk Sylt« nicht einfach angeben, daß es sich jeden geraden Monat in Hörnum, jeden ungeraden Monat in List auf Sylt trifft, z. Zt. in Westerland, Hörnum und Kampen aktiv ist, aber gerne die ganze Insel abdecken möchte?! Die Fixierung auf Städte funktioniert nicht in der Fläche, und sie geht auch sonst an der Realität vorbei. (Freifunk Bielefeld ist nicht nur, eigentlich am wenigsten, im Stadtgebiet Bielefelds aktiv; Freifunk Münster wuchs zu Freifunk Münsterland; …)
Ein Domain „Freundenberg (Siegerland)“ hat Knoten in Freudenberg, Alchen, Dirlenbach Büschergrund, Oberholzklau und Niederfischbach.
Soll man jetzt da zwei Communities erfinden, nach der Gemeindegrenze die da quer durchgeht?
Gerade auf der „Nicht-Freudenberger“-Seite wird das aber schwierig… Denn die Gemeinde ist meines Wissens Betzdorf, dort steht aber kein Knoten dieser Domain, denn diese „Gemeindestadt“ gehört schon wieder einer anderen Community…
Will sagen: Wenn die API nur Eintrage mit Ortsnamen nimmt, dann gaukelt das eine Präzision vor, die es real nicht gibt.
Und führt dazu, dass Freifunk an Gemeinde- und Kreisgrenzen auseinandergehauen wird, nur um es irgendeiner API recht zu machen.
Die rege Diskussion zeigt, das an diesem Thema Interesse besteht - dafür möchte ich Euch sehr danken.
Freifunk möchte dezentral sein und das sind die lokalen Nutzergruppen (Communities) auch. Sie organisieren sich selbst und schließen sich teilweise mit anderen lokalen Nutzergruppen zusammen. Die Art der Zusammenarbeit ist dabei sehr unterschiedlich. Mal eher spirituell, mal handfest, in dem man gemeinsame Infrastrukturen schafft oder die Infrastrukturen einer anderen Community mitbenutzt oder die eigenen zur Mitnutzung freigibt. Zusammenarbeit findet nicht nur in und zwischen organisierten Communities statt, auch Einzelpersonen binden gelegentlich bei einer bestehenden Community an, um die Brücke ins Internet zu schlagen, ohne geografisch zu dieser Community zu gehören. Diese vielfälltige Vernetzung der Menschen untereinander ist es, was gelebte Dezentralität ist. Der Nachteil ist, dass dieses Geflecht für viele Leute, die Freifunk als ein kleines Hobby ansehen und auch für neue Freifunker, ein quasi undurchsichtiges Geflecht ist - ein Wildwuchs.
Trotz einer dezentralen Organisation der „Bewegung Freifunk“ gibt es, sinniger Weise, einige zentrale Services wie die Community-Map und freifunk-karte.de welche auf das zentrale Community Directory aufsetzt. Wer da nicht drin sein möchte muss es auch nicht.
Das Community Directory mag nicht perfekt sein, es bringt jedoch zumindest etwas Licht ins Dickicht, da es regionale Anknüpfungspunkte für Freifunker besser sichtbar macht. Es versucht nicht alle Eigenheiten einer jeden Community zwingend in einer gemeinsamen Datenstruktur abzubilden - es ist jedoch ein guter erster Schritt auf dem Weg regionale Zuordnungen herzustellen.
Als kleinste granulare Stufe auf der Landkarte sehen wir die „Stadt“. Natürlich könnten man auch versuchen noch granularer zu werden, was jedoch die Komplexität erhöht und Bedienbarkeit einschränkt. Je kleinteiliger wir werden, desto schwieriger wird es eine gute Qualität in den Daten aufrecht zu erhalten. Ich spreche mich gegen eine weitere Detailierung aus: also keine Stadtteile, keine Straßenzüge, keine Häuser und keine komplexen (haus-genaue) Polygone auf der Landkarte. Als kleinste darstellbare Einheit benutzten wir das Wort „Stadt“, meinen damit aber eine geschlossene Ortschaft (Stadt, Kleinstadt, Gemeinde, Dorf). Das ist m.E. ein guter Kompromiss für ein solches Projekt. Was passiert mit dem Bauernhaus auf dem freien Land, welches außerhalb von geschlossenen Ortschaften liegt? An dieser Stelle sind wir, aus gutem Grund, in der API nicht ganz Minderheiten-freundlich. Diese Person kann sich mit seinem Knoten technisch bei irgendeiner Community anschließen. Eine eigene Community, die sich in das Community Directory eintragen kann, ist er aber als One-Man-Show nicht. Eine Community soll versuchen quasi „jederzeit“ ansprechbar zu sein, dafür sollen sich mindestens 2-3 aktive Personen zusammenfinden - in der Fläche wird das sehr schwer (geringe Anwohnerzahl) - daher werden sich in der Praxis fast immer die „Sogwirkung“ nächsten „Stadt“ bilden. Das ist quasi der kleinste gemeinsame Nenner was die regionale Zugehörigkeit angeht. Als Landbewohner mit hoher lokaler Identifikation kann man das doof finden (da hilft einem vielleicht der die tolle Natur drüber hinweg), aber wer einen Freifunk-Router aufstellt um anderen (unbekannten) einen freien Zugang, zu so etwas globalen wie das Internet, zu schenken, der denkt doch eigentlich eher in größeren Zusammenhängen. …hoffe ich zumindest. Think bigger! Freifunker, der Du das hier liest, fühle Dich bitte trotzdem in Deiner lokalen Identität ernst genommen.
Auch wenn Freifunk dezentral ist, bedeutet eine zu starke Zergliederung auch immer eine Schwächung - Teile und Herrsche (Historisch war das oft eher: „werde beherrscht“) - je kleingliedriger wir sind, desto weniger finden wir in den Medien und in der Politik statt, das schränkt das Wachstum des Projektes unnötig und künstlich ein. Die aktuelle API mit „Stadt“ als kleinste Einheit macht für mich absolut Sinn und stellt meiner Meinung nach eine gute Balance dar.
Zur Zeit gibt es keine Möglichkeit mehrere Communities pro „Stadt“ abzubilden. Der aktuelle Modus ist, ähnlich wie bei Domains „first come, first served“. Wenn eine Gruppe jedoch einschläft halte ich es für Sinnvoll, dass eine andere Community aus dieser „Stadt“ zukünftig stattdessen in das Community Directory aufgenommen wird. Bis wir einen besseren Modus haben um überlappende Communities abzubilden schlage ich den „the winner takes it all“ Modus (wie im britischen Wahlkampf) vor. Also die Community die (deutlich) die meisten (aktiven) Mitglieder hat bzw. die meisten Knoten betreibt - denn das dürfte für die API-Clients den größten Mehrwert haben. Persönlich meine ich das Fusionen auf „Stadt-Ebene“ angestrebt werden sollten - gemeinsam ist man stärker und es reduziert die Komplexität. Die jeweilige Community ist natürlich frei darin, weiterhin „ihr eigenes Ding“ zu machen und in „Stadt-interner Konkurrenz“ zur eingetragenen Community agieren. Persönlich denke ich, sollte das keine Community tun - Ich mag Menschen die Zusammenarbeit fördern, lieber als Separatisten - aber das ist nur meine persönliche Meinung. Wenn es zwingende Gründe gibt (mir fallen gerade keine ein), die eine weitere Zerfaserung des Netzwerkes rechtfertigen stehe ich diesen (dann) Minderheitsgruppen der jeweiligen „Stadt“ aber trotzdem helfend zur Seite, auch wenn sie damit dann aktuell in die selbstgewählte „Unsichbarkeit in der API“ verschwinden. Wer den Wettbewerbgedanken wirklich „aufreiten“ will muss aktuell halt zusehen, dass er zur Mehrheit wird. Solange die Spielregeln klar sind, finde ich das auch Fair.
Vorschläge / Proposals zum Thema „Spielregeln für die Landbesetzung“ (mit Augenzwinkern) für das Community Directory solten wir dann hier sammeln:
Bei den Community API Dateien geht es primär um die organisatorische Seite - auch wenn wir viele Felder für die technische Seite in den API Dateien haben (das sind zumindest die Wurzeln der API). Bei der technischen Seite gibt es, zugegeben, sehr viel Verwirrung auch leider auch Interpretationsspielraum - ich hoffe das können wir in den nächsten Monaten gemeinsam zunehmend klarer definieren - dazu sollten wir aber einen separates Issue auf Github aufmachen. Ihr seid herzlich eingeladen.
Vorschläge / Proposals zum Thema „Technische Seite“ für die Community API Datei solten wir dann hier sammeln:
Was sind „Meta Communities“? Alle unsere Communties sind gleichberechtigt, es gibt keine Hierachien! Wenn sich mehrere lokale Nutzergruppen gemeinschaftlich mit anderen Nutzergruppen organisieren wollen oder schlicht eine Verbundenheit zu einander ausdrücken wollen, dann kann jede dieser Communities das Feld „metacommunities“ mit dem gemeinsamen Namen gelegen. Es gibt keine Pflicht zur Bildung von Meta Communities - man kann also auch ohne eine Meta Community zusammenarbeiten. Das Feld „metacommunities“: das ist dann der Name der Meta Community. Dieser Name soll NICHT identisch mit dem Namen einer der beteiligten Nutergruppen (Communities) sein. Es ist quasi nur ein Label / Etikett. Jeder der es „trägt“ gehört zu dieser Meta Community. Das Etikett sagt jedoch nichts über die Art der „Verbundenheit“ aus - diese kann esoterisch oder auch handfest sein, sie kann organisatorisch oder auch infrastrukturell sein. Es gibt keine Hierachie! Eine Meta Community ist KEINE eigenständige Entität, es ist nur eine gemeinsame Flage. Wenn eine der teilnehmenden Communities etwas (wie auch immer geartetes) Besonderes ist, dann gibt es dafür derzeit kein Merkmal in der API - Vorschläge sind willkommen, falls es dafür Bedarf gibt.
Vorschläge / Proposals zu „Meta Communities“ für die Community API Datei solten wir dann hier sammeln:
Technische Anbindung von Knoten:
Es dürfen auch Knoten außerhalb der eigenen Community angebunden werden - auch wenn diese dann im Niemandsland oder im Stadtgebiet einer anderen Community liegen. Berlin dürfte z.B. Knoten aus Bayern anbinden. Wie gesagt alle Node-Betreiber (Freifunker) sind frei in Ihrer Wahl, wo sie sich technisch anbinden wollen oder zu welcher Community sie sich zugehörig fühlen wollen. Für die API ist das kein (ernstes) Problem. Die Community, bei der der Freifunker angebunden ist muss dann dafür sorge tragen, dass sein Knoten z.B. in einer NodeList dieser Community, oder bei technischer Anbindung an eine Schwester-Community (aus der selben Meta Community; meine Wortschöpfung), eben durch diese, auftaucht, damit API-Clients diesen Knoten auch finden können.
Knoten auf der Map
Aktuell ist zwar noch die genaue Darstellung solcher Knoten ungelöst, also wie konkret diese Knoten einer Community oder einer geografischen Region zugeordnet werden sollen.
Es gibt Communities die alle Knoten in der Stadt darstellen, egal ob Sie von der eigenen Community betrieben werden oder nicht - wiederum andere Communities zeigen nur die eigenen Knoten an (ggf. über die „Stadtgrenzen“ hinaus) und wiederum andere Communities sind an optimaler Usability für nicht-Freifunker - also WLAN-Hotspot-Nutzer (ich nenn sie mal „Endkunden“, auch wenn es keine „Kunden“ sind) - interessiert und zeigen alle Hotspots an (eigene und fremde Communities, als auch offene WLAN-Hotspots die nicht zu Freifunk gehören). Auch gibt es aktuell Diskussionen, ob eine NodeList für alle Communities in einer Meta Community zentral bereitgehalten werden sollen, oder ob diese je Community API Datei in Teile zerlegt ausgeliefert werden soll. Solange das noch nicht entschieden ist (also Teil der API Spezifikation ist), darf das in allen o.g. Varianten in der API Datei eingetragen werde. Auch hier erwarte ich noch eine interessante Diskussion:
Vorschläge / Proposals zu „Freifunk NodeList Schema“ solten wir dann hier sammeln (ich glaube dieses Repo ist bei dem Thema führend):
Ich wünsch mir, dass alle Communities mit „Besonderheiten“ versuchen die API in diesem Sinne zu verwenden, zumindest aktuell. Gerne helfe ich dabei.
Am Beispiel „Insel Sylt“:
Die kleinsten Einheiten auf dieser Insel sind:
Demnach würde ich hier 5 Community API Dateien anlegen und bei allen das Feld "metacommunity z.B. auf „Inselfunk Sylt“ setzen - oder halt ein anderer Name, der Euch gut gefällt.
Die Communities würde ich z.B. so benennen:
Alternierende „Meeting Places“: das ist echt etwas „Besonderes“, was die Community API Datei derzeit nicht kann. Sinngemäß geht es darum, dort den Ort zu benennen, bei dem es am einfachsten ist, jemanden von Freifunk anzutreffen. Wenn Ihr 2 Orte habt, muss von euch aktuell eine Entscheidung getroffen werden, welche die „wichtigere“ / „primäre“ Adresse sein soll. Persönlich würde ich mich für den Ort mit mehr „Publikumsverkehr“ / besserer Verkehrsverbindung entscheiden, wobei beide gekannten Orte jeweils am anderen Ende der Insel sind. Das würde für mich als Kriterium schon mal ausscheiden. Wenn beide „gleichwertig“ sind könnt Ihr für die API auch einfach würfeln. Das macht den Perfektionisten nicht glücklich, ist aber ein pragmatischer Ansatz. Diese Adresse würde ich dann in alle Dateien eintragen. Die Besonderheiten, die in der API aktuell nicht erfasst sind, sollten m.E. dann prominent auf Eurer Website auftauchen: hier also einen deutlichen Hinweis auf 2 Orte inkl. Hinweis zur Alternierung.
Für zukünftige API Versionen können Vorschläge diesbezüglich gerne diskutiert werden.
Vorschläge / Proposals zu „Meeting Place“ für die Community API Datei solten wir dann hier sammeln:
Bei Bedarf bitte melden, ich helfe gerne.
Am Beispiel „Freundenberg (Siegerland)“:
Die technische Anbindung von Knoten oder auch technische Begriffe, wie „Domain“, haben für die Bestimmung der Anzahl an Communities (API Dateien) keine bzw. kaum eine Bedeutung. Eine Community gibt es erst, wenn es mind. 2-3 aktive Leute in dieser „Stadt“ (hier Gemeinde) gibt.
In der Meta Community „Siegerland“ sind aktuell folgende Communities:
Ich würde folgende Community anlegen (wenn es dort mind. 2-3 aktive gibt):
Und diese für diese dann ebenfalls „metacommuntiy“ auf „Siegerland“ setzen.
Hinweis: Für eine Meta Community ist es nicht erforderlich, dass sich die „Stadtgrenzen“ berühren, es sind also auch virtuelle Verbünde möglich z.B. „Freifunk Elfenwiese“ (über ganz Deutschland verstreut; erfundenes Beispiel).
Wenn es in „Betzdorf“ keine Freifunker gibt, dann gibt es auch keine API Datei.
In Betzdorf gibt es meines Wissens aktuell keine Freifunk Community.
Die „Präzision-Level der API“ ist das „Stadtgebiet“.
Bei Bedarf bitte melden, ich helfe gerne.
Puh, ganz schön lang, aber hoffentlich hilft es Licht ins Dunkel zu bringen.
Ich freue mich weiterhin auf rege Teilnahme.
Für „Inselfunk Sylt“ fällt mir gerade noch ein, dass die alternierenden Termine natürlich auch in einem Event-Feed eingetragen werden kann, welcher dann via Feld „feeds“ in der Community API Datei referenziert wird.
Ich biete hierbei ebenfalls meine Hilfe an.
So ist es eben, seit vielen Jahren in Düsseldorf.
Die eine Community hatte die Router früher online und die (denic-)Domains registriert, die andere hatte den API-PR zuerst.
Bleibt dann halt bei der zentralistischen Struktur von Freifunk. Zentrale Gatekeeper entscheiden auf Grundlage von „Gemeindegrenzen“ was legitime Freifunkende sind und welches nicht.
Ich kenne die Situation in Düsseldorf nicht.
Gibt es zusätzlich zu dieser Community hier:
github .com/freifunk/directory.api.freifunk.net/blob/master/directory.json#L75, also freifunk-duesseldorf .de
noch eine weitere lokale Nutzergruppe (Community), welche derzeit nicht in dem Community Directory Datei vertreten ist? Wie lautet deren URL?
Was spricht dagegen die Kräfte/Nutzergruppen dieser Stadt in einer einzigen Community zu vereinen? Gab es schon Gespräche dazu?
Für mich sieht es so aus als sei freifunk-duesseldorf.de recht aktiv:
PS: Die Schreibweise der URL ist absichtlich so, weil neue Forum Nutzer nur 2 Links pro Nachricht haben dürfen.
Willst Du wirklich diese alten Geschichten wieder hochholen?
Einer der Streitpunkte war, dass seitens eines Vereinsvorsitzenden bei Zusammenarbeit mit der Stadt vereinbart wurde, in deren Liegenschaften nur Geräte mit „Herstellerfirmware“ zu installieren, da bei Einsatz von Fremdfirmware die CE-Konformität nicht mehr gegeben sei. Daraufhin hat es für die aktiven der anderen Community ein Ausbau- und faktisch Hausverbot für die Geflüchtetenunterkünfte gegeben, weil man dieser Abrede nicht zustimmen wollte.
Der andere Punkt ist, dass es eine Vereinsgründung gegeben hat unter zumindest nicht einvernehmlichen Umständen (Es gab Leute, die dort anwesend waren und nicht mitgegründet haben).
Danach hat dieser neu gegründete Verein gesagt „Wir wird der Freifunk Düsseldorf, alle anderen sind kein Freifunk Düsseldorf“.
Kann man machen, ist dann aber halt soetwas wie „zentralistischer Gebietsschutz“, wenn das von einer zentralen Instanz so zementiert wird.
Faktum ist, dass es Gegenden mit mehreren langfristig aktiven Communities gibt, die auch „mehr als nur OnePersonShow“ sind.
Ich fordere nicht, dass die API das abbilden können muss.
Meine Aussage ist nur, dass ich sie nicht erstnehmen kann, wenn sie das nicht tut.
Danke für die Einleitung in das Thema „Düsseldorf“. Das war mir unbekannt und das ist schade zu hören, dass es dort so vertrackt ist.
Unter welchem URL kann ich die „Alternative Freifunk Düsseldorf“-Community finden?
Es ist überhaupt nicht vertrackt. Das finden vorwiegend Leute so, die einen geographischen zentralistischen Anspruch an Freifunk formulieren.
Freifunk Düsseldorf – wiki.freifunk.net bildet das auch ab, ohne dass es durch zum Streit käme.
Denn beide Seiten machen ihren Weg. Ist ja nicht so, dass die Beteiligten sich mit Mistgabeln in dunklen Ecken auflauern. Es gibt unterschiedliche Herangesehensweisen. Es ist doch kein Verdrängungswettbewerb nach dem Motto „es kann nur einen Geben“
Ich denke, dass vielen Communities (ich wage mal zu sagen „Dortmund“ und „Köln“, evtl sogar „Berlin“), geholfen hätte in den letzten 1-2 Jahren, wenn man dort hätte forken können.
Man denke an den ewigen Streit zwischen „Router für Kleingewerbe, das muss zuverlässig laufen“ vs „Wir machen hier nonkommerziellen experimentalfunk, hier muss gar nichts“. Wo sich häufig genug Leute gegenseitig aus dem Projekt geekelt haben.
Stellt Euch doch mal vor, wenn bei Linux-Distributionen sich jeder Hackspace (oder jede LUG früher) auf eine Distro hätte festlegen müssen. „Weil sonst ja lokal keine sinnvolle Zusammenarbeit möglich ist“
Oder wenn das Forken von Linux-Distributionen überhaupt irgendwelchen regionalen Einschränkungen unterworfen wäre.
Oder anders gesagt: Mehrere Domains pro Stadt/Landstrich tut niemanden weh!
Wirklich nicht!
Warum?
Diese strikte regionale Strukturierung von Freifunk-Domains ist der Denke von 2014/2015 geschuldet.
Als die meisten (mich eingeschlossen) dachten „Wir machen ein riesiges Meshnetz über eine Stadt, in jeder Strasse 10 Router, 5000+ in der ganzen Stadt, von Fensterbank zu Fensterbank… alle meshen mit allen“
In dieser Sicht ist es natürlich immens wichtig, dass alle Router in einer Domain sind, sonst klappt das mit dem Mesh nicht.
Aber inzwischen wissen wir
Und daher ist dann auch die Regel „eine Stadt, eine Domain“ nicht mehr zeitgemäß, weil ihre Rechtfertigung/Notwendigkeit gar nicht vorhanden ist.
Jetzt verstehe ich Deinen Punkt bzgl. API besser.
Wenn man Freifunk Düsseldorf – wiki.freifunk.net liest, dann hat man gar nicht den Eindruck, dass in Düsseldorf 2 Communities existieren.
Aus technischen Gründen hat man das Netz geteilt. Was aber nicht zwingend bedeutet, dass man sich organisatorisch in 2 Lager aufgeteilt hat. Eine Aufteilung in 2 Communities ist auf den ersten Blick nicht ersichtlich - zumal die links auf ffdus immer Deep-Links sind.
Es gibt andere Communities, die ebenfalls mehrere Netzwerk-Domains haben, um separate Netze zu haben, die trotzdem von dem selben Admin-Team betreut werden.
Das Community Directory ist jedoch, von der Denke her, eine Auflistung von Communities, nicht eine Auflistung von „technischen Zonen“ / „Netzwerk-Domänen“. Semantisch korrekt wäre m.E. demach 1 Eintrag, welcher in der Community API Datei unter einer „NodeList“ alle Knoten in allen Netzwerk-Domains veröffentlicht bzw. mehrere „NodeList“-Einträge, also je eine pro Netzwerk-Domäne, hat.
Erst wenn es auch organisatorisch, also nicht rein technisch, 2 Communities sind, wären es aus Sicht des Community Directory 2 Einträge. Technisch gäbe es dann die Möglichkeit den zusätzlichen Eintrag „duesseldorf_ffdus“ in dem Community Directory anzulegen, jede mit einer eigenen „NodeList“. Das wäre dann semantisch korrekt. Überlappungen in der NodeList, also der selbe Knoten sollte nur in einer Liste auftauchen, würde es m.E. dann nicht geben.
Der Wert „duesseldof“ bzw. „duesseldorf“ ist quasi ein Codename für eine Community - also eine ID. Diese muss eindeutig sein. Der offizielle Name der Community steht in der Community API Datei. Die ID folgt derzeit einer Namenskonvention: Stadtname, kleingeschrieben. Würde es mehrere Communities pro Stadt geben, müsste man die Konvention anpassen, z.B.: Stadtname_EindeutigerCommunityBezeichner (ebenfalls alles kleingeschrieben). Das dürfte in der Regel eine unkritische Änderung sein. Wenn API-Clients die Anzahl Einträge verwenden, um z.B: die Anzahl Communities zu ermitteln wäre das hier unproblematisch. Zählen die API-Clients alle Einträge hingegen als Anzahl Städte, dann würde o.g. Änderung den (unausgesprochenen Vertrag) mit dem API-Clienten brechen. Zugegeben, für diese wäre es ein leichtes alle Communities die in einer Stadt sind zu erkennen (o.g. Namenskonvention), dennoch wäre eine Anpassung notwendig. Daher ist eine Diskussion erforderlich. Gerne hier:
github .com/freifunk/directory.api.freifunk.net/issues
Persönlich würde ich es begrüßen, wenn Ihr Euch als 2 Arbeitsgruppen, mit je einer eignen Netzwerk-Domäne in der selben Community verstehen würdet. Dann könnte es so bleiben wie es ist. Nur die Community API würde ich dann um z.B. 2 NodeLists erweitern (aktuell ist dort gar keine NodeList angegeben).
Als „WLAN-Nutzer“ interessieren mich vor allem alle Knoten in der Stadt - also 2 unvollständige Karten, die jeweils nur ein Teil der Knoten in dieser Stadt abbilden, sind nicht gerade nutzerfreundlich. Wäre cool, wenn Ihr hier zusammenarbeitet und eine gemeinsame Karte prominent auf der Website habt.
Und wenn es keine „Fackeln und Forken“ zwischen Euch gibt, könnte man sich untereinander auf der eigenen Website prominent verlinken.
Wenn es eine technische und organisatorische Trennung, also echte 2 Communities sind, dann erstelle bitte ein PR:
github .com/freifunk/directory.api.freifunk.net/pulls
Wenn Du dabei Hilfe brauchst melde Dich bitte einfach.
Wenn wir uns einen Api-Eintrag teilen wollen, dann würde ich eher vorschlagen, das dann zu kombinieren mit Communities mit denen auch irgendwelche Berührungspunkte bestehen.
Ohne gemeinsamen API Eintrag mit Freifunk Düsseldorf würde es dann auf einen eigenständigen „duesseldorf_ffdus“ hinauslaufen. Sich in ortsfremde Community API Dateien einzutragen ist leider komplett gegen das Konzept. Bitte bitte, macht das nicht.
Besser wäre es einen PR für „duesseldorf_ffdus“ zustellen. Wenn Ihr Eure Verbundenheit mit anderen Communities zeigen wollt, dann könnt Ihr mit diesen eine Meta Community bilden. Dazu muss jede dieser Communities dann das Feld „metacommunity“ mit dem selben Wert belegen z.B. „Freifunk Elfenwiese“ (ich verwende diesen Begriff nur, weil er fast garantiert frei ist). Ein Wert der NICHT identisch mit einem Community Namen der teilnehmenden Communities sein soll.
Ich suche eigentlich keine Lösung für ein individuelles (oder gar „persönliches“) Problem:
Mir geht’s darum, dass ich die Community-Gliederung nach Ortschaften schlicht für wenig zielführend halte mit den Erfahrung der Jahre 2017 und 2018:
Ich denke ich habe den Sachverhalt nun hinreichend verstanden.
Es handelt sich hier NICHT um ein: „geht nicht mit der API“.
Wenn Du Dich entschließt einen der o.g. technischen Lösungsansätze zu verfolgen und solltest Du Hilfe benötigen, schreib mich einfach per PM an, ich helfe gern.
Für die nicht-technischen Herausforderungen möge bitte ein erfahrener Community Manager, ein Mediator, ein „Paar“-Therapeut oder sonst wie fachkundige Person die Mediation an dieser Stelle übernehmen.
Ich werde mich zwischenzeitlich, um diverse konkrete Freifunk-Aufgaben kümmern, sowie anderen Diskussionen folgen.
Oder auch nicht existent. Dies Problem hat die API zu lösen, nicht die Communities.
Mal ernsthaft, hast Du nicht zugehört? Es geht nicht darum, kleinteiliger zu werden, das Gegenteil ist der Fall!
»Was passiert mit dem Bauernhaus auf dem freien Land, welches außerhalb von geschlossenen Ortschaften liegt?« ist gar nicht die Frage, sondern: »warum muß die Community, die die Insel abdecken will, „Freifunk Sylt“, als „Freifunk Westerland“ sich in der API ausgeben‽«.
Hä?! Natürlich finden sich, gerade in der Fläche, Leute zusammen; nur wollen diese eben nicht als »Freifunk Kuhdorf« agieren, sondern wenigstens als »Freifunk Kuhmilchregion«. Nur entspricht »Kuhdorf« Euren falschen Eintragungsvoraussetzungen, »Kuhmilchregion« hingegen nicht.
›Wir‹ denken ja größer; es ist die kleinkarierte und antiquierte, der API zugrundeliegende, Denke, daß Freifunk in jedem Kaff mindestens 3 Aktive fesselt, die das Problem darstellt.
Randnotiz:
… und dennoch weichst Du keinen Deut von Deinen Prinzipien bei der API ab. Bei einem Open-Source-Projekt ist ein solches Verhalten ein guter Grund für einen Fork.
Du übergehst hier den Fakt, daß es eben keine dieser 5 Communities gibt; im Fallbeispiel wurde explizit gesagt, daß die Community sich eben »Freifunk Sylt« nennt und keinen sonstigen Ortsbezug hat:
Deine »kleinsten Einheiten« sind eben nicht die, in denen sich Communities zwingend organisieren. Faktisch widerspricht es je nach Fallkonstellation sogar den von Dir so hochgehaltenen Regeln, diese Fake-Communites einzutragen: »Freifunk Sylt« bestehe aus 1 Person aus Westerland, 1 Person aus Kampen, 2 aus List — erst mal 'ne Community. Gemäß Deiner Ausführung, daß »eine eigene Community, die sich in das Community Directory eintragen« könne, eine einzelne Person gerade nicht sei, wäre nur die Eintragung der beiden Leute aus List als Community möglich. Als »Freifunk List«, »Metacommunity Freifunk Sylt«. Hat mit der Realität nichts zu tun.
Und das deckt, wie wiederholt dargelegt, nicht die Realität ab. Eine Community hat oft (genau) eine Postadresse, schon bei Treffpunkten splittern sich die Möglichkeiten auf, bei Wohnorten der Mitglieder der Community ebenso. Somit funktioniert dieser erzwungene Ortsmodus nur mit Krücken, die den Datenbestand gezielt ungenauer machen. Cui bono?
Last but not least:
Umgekehrt wird aber erst ein Schuh daraus: wer auf freifunk-karte.de und ähnlichen Diensten stattfinden möchte, muß da rein — und stellt ggf. fest, daß seine Organisationsform nicht dem dogmatischen Ideal entspricht und eine Aufnahme mit unverfälschten Daten verweigert wird.
Mit jedem neuen Dienst, der auf der Freifunk-API aufbaut, erwächst den Initiatoren und Torwächtern der Freifunk-API mehr Macht — mit der sie umgehen müssen, und die sie vorzugsweise im Interesse der und Dialog mit der Community ausüben statt gegen diese. Und hier sehe ich noch Luft nach oben.