Benutzer:Yanosz:Ideen

Einleitung

Der 31c3 steht vor der Tür und damit die Chance mit Freifunkern Ideen und Erfahrungen auszutauschen. Gleichzeitig sind wir mit der Umsetzung der Anforderungen weitesgehend fertig -- wenn man von Crypto absieht.

Mit dieser Wiki-Seite möchte ich gerne eine Diskussion-Starten, in welche Richtung wir in Zukunft weiterarbeiten.

Gruß, Jan

Zukunft: register.kbu.freifunk.net

Meine Idee für die Anwendung war eine Art Wiki-Ansatz: Es gibt einen Server mit Webanwendung, in der jeder eine Seite zu "seinem" Knoten anlegen kann und dazu weitere Infos bekommt. Die Anwendung ist technisch ziemlich alt (-> Rails Upgrade steht an) und kommt aus einer Zeit, inder alle Communities unübersichtliche Wiki-Tabellen für ihre Knoten gepflegt haben. (Lübeck hatte damals sogar eine Wiki, aus der ffmap Knoten parsed hat).

Hierbei hab' ich aber viele Fragezeichen

1. Trifft der Ansatz die Benutzererwartung?
2. Wie sollen die Use-Cases (Node-Daten bereitstellen, Node-Daten abrufen) aus Benutzersicht ablaufen?

• • Im Config-Mode?
  • Durch eine Register-Seite?
  • Ganz anders?

1. Wollen wir im Config-Mode Internet bereitstellen um eine Kartenposition zu suchen (afair nicht in gluon). Welche Konsequenzen ergeben sich für den config-Mode?
2. Welche Informationen stellen wir da (-> Chat, Nodekontakt, etc.). Wie sollen Benutzer sie finden?
3. Wo legen wir die Informationen ab? Alfred, MySQL-Datenbank? NoSQL-Datenbank, clustered auf Supernodes...
4. Verhältnis zum Raketenkontrollzentrum

• • Existieren beide Parallel?
  • Wird eins in das andere eingebettet?
  • Schnittstellen?

Ich hab' hierzu keine feste Meinung und bislang auch wenig überzeugende Argumente / Ideen gehört. Wichtig wäre mir vor allem die Use-Cases aufzuschlüsseln ohne direkt über technische Details zu reden - ich denke, dass wir damit eine Sprache finden, die keinen abhängt.

In diesem Kontext kommt auch die Port-Belegung, das dezentrale Chat-System und ggf. auch avahi zum Zuge

• These: Ein Benutzer, der ein Kabel in einen LAN-Port steckt, erwartet dort eine IP zu bekommen um den Router erreichen / konfigurieren zu können
• These: Der config-mode braucht wlan-Support, da es immer mehr Geräte ohne LAN-Port gibt
• These: Der config-mode muss an OSM-Daten kommen können, damit dort Standortdaten der Nodes konfigurierbar sind
• These: Webseiten-Besucher wollen Daten zum Netz sehen. Was liefern wir? Register? Wiki? Map? Wollen wir die ffmap um Informationen anreichern?
• These: Benutzer sollten sehen können, mit welchem Node sie verbunden sind und wie sie den Administrator bei Problemen erreichen können (aktuell: E-Mail Kontaktfeld in register)

Aus den letzten beiden Thesen kommen ein paar Punkte:

• Warum machen Node-Aufsteller falsche Angaben / nutzen nicht-funktionierende E-Mail Adressen als Kontaktadresse in register?
  • These: Sie wollen nichts über Probleme hören oder haben kein Interesse an der Kontaktaufnahme mit Nutzern
  • These: Register ist ein "Telefonbuch" wo zu einem Node eine Kontaktmöglichkeit hinterlegt wird. Register ist sinnlos, wenn es falsche Kontaktadressen beinhaltet. Die gibt es, also ist register sinnlos.

Neue Firmware-Releases / Folgen des Gluon / LFF upstreams

1. Welche Software-Pakete / Features wollen wir aus gluon nutzen?

• • Zur Zeit verwenden wir bspw. nicht das batman-adv-Paket, da es mit der Visualisierung Probleme gab - gibt?
  • Den autoupdate wohl nicht
  • config-mode / expert mode wikt eher schwer
  • Build-Prozess site-file: Eher nicht, schränkt den build stark ein

1. Wie weit wollen wir uns konzeptionell an gluon annähern, bzw. gluon an un?

• • Unterstützen wir Christof bei dem Ansatz, collectd und auto-key-upload in "gluon aufzunehmen"?
  • Was bedeutet "aufnehmen" eigentlich an der Stelle?

1. Was stört uns an Gluon?

batman-adv Migration

1. Da müssen wir wohl durch - irgendwie
2. Johnny Bee hat einen Test - gibt es Ergebnisse?
3. Sind die aktuellen batman-adv releases stabil?

Raketenkontrollzentrum

1. Was ist das eigentlich technisch? Eine JavaScript-Anwendung für Nodes?
2. Eine Android / iPhone App? Eine monolithische Webapp?
3. Wie intergriert sich das Zentrum in die bisheringen Dinge? Wer liefert welche Daten?
4. Wann gibt es ein Release?

Doku

• Serverdoku - aktueller Stand?
• Schreiben wir nochmehr Konept-Doku für andere Communities?

Sonstiges

1. QoS:

• • Wie verhindern wir, dass eine Überlast-Situation das Netzwerk hart trifft?
  • Wer hat Erfahrung mit QoS. Evtl. macht Jan dazu mal eine Session mit PEra

1. FFFM: Was hat Christof für Pläne und Visionen