wiki:UserStories/FreifunkMap

Version 14 (modified by MK, 11 years ago) (diff)

Plan

FF-Karte

Ziel der Anwendung soll es sein, sowohl ein Werkzeug für das technische, als auch für das soziale Netzwerk zu sein. User sollen in einer Karte sehen können, wo es bereits FF-Accesspoints gibt. Ausserdem soll der Eigentümer (Nickname) des Accesspoints angezeigt werden und die Möglichkeit bestehen, mit dem User Kontakt aufzunehmen.

Requirements/Features

  • Verschiedene Ansichten, z.B. GeoMap, Community-Blackboard, Chat
  • User soll sich selbst einen Account erstellen können
    • Das sollte Server-Seitig für die Domain FF-Karte einstellbar sein (Wer kann neue user anlegen? admin||user)
  • User hat einen Nickname, über dem man ihm interne Nachrichten schicken kann.
  • User kann einstellen, welche seiner Daten welcher Community angezeigt werden sollen.
  • Das System kann User per Mail über neue Nachrichten informieren.
  • Anfragen in Sachen Community
    • Kalenderansicht, wann treffen sich welche Communitys
    • ...
  • Facebook etc.-Integration, was wäre da möglich?
    • ...

Datenmodell (in DeepaMehta)

  • User, Node, Community
    • Node gehört-zu User (Eigentümer = Admin?)
    • User gehört-zu Community
    • Community wird-administriert-von User
    • Node wird-administriert-von User
  • User: Nickname*, Name, E-Mail*, Wikitext als Beschreibung
    • Leute können User per Webmail über Nickname kontaktieren.
  • Node: Name, Position, Kanal, Protokoll...
    • User soll neuen Accesspoint erstellen können.
  • Community: Name, Ort, Wikitext als Beschreibung, Treffenstermin/-ort/-periode
    • Beschreibungstext sollte insbesondere auch Links zu zugeordneten Foren und Wiki-Seiten enthalten (per Template motivieren)
    • User soll eine neue Community erstellen bzw. beliebig vielen Communitys beitreten können.
    • Community kann nur gelöscht werden, wenn leer = keine Mitglieder
    • Ort/Gebiet? kann sehr lokal (Strassenzug) und sehr global (Berlin, D, A, CH) sein.
    • Termin wäre für einen Service wie "upcoming meetings" interessant, aber wohl kaum wirklich aktuell zu halten
      • Deaktivieren, falls Meetings nicht nach Nachfrage-Mail bestätigt?

Vorgehen

  • Andrés openwifimap ist Basiskomponente (JavaScript, benutzt CouchDB)
  • openwifimap kümmert sich auch um das Zusammenstellen der Nodes und bietet ein Query-Interface nach außen an
  • openwifimap so erweitern, dass es auch mit DM spricht
    • auf DM-Seite wird dafür ein entsprechendes Datenmodell gebaut, in dem nur die Community-Daten gespeichert werden (keine Geodaten, die bleiben in der CouchDB)
    • die Erweiterungen der Karte benutzen den dmx-webclient? Oder direkt das normale REST-Interface?
    • CouchDB von openwifimap und DeepaMehta liegen hinter Apache httpd-Proxy, damit Same Origin Policy passt
  • Benutzerverwaltung
    • Account anlegen (erstmal einfach per Web, ohne Verifizierung der E-Mail-Adresse etc.)
    • Später: Verifizierung der E-Mail-Adresse, Login über OAuth/Google/Facebook etc., Accounts automatisch deaktivieren falls inaktiv
  • Java-Plugin für DM
    • eigene API Richtung für die Community-Funktionen der Karte
    • implementiert Zugriffsrechte auf Benutzerebene
  • Nachrichten verschicken
    • via Karte/Webfrontend, ohne Offenlegen der E-Mail-Adresse des Empfängers
  • Weitere Community-Funktionen für die Karte (siehe Requirements)
  • Allererster Schritt
    • Die openwifimap-Karte in der VM gängig machen (GeoCouch? installieren etc.) => André fragen
    • Einen Beispiel-Node bzw. seine ID in der Karte raussuchen
    • Plugin für DeepaMehta bauen, dass einfaches Datenmodell und Beispieldaten in DM importiert (beinahe fertig) => mit Jörg
      • Beispiel-Node sollte dabei die ID des o.g. Nodes aus der Karte haben
    • Karte so erweitern, dass es weitere zum Node gehörige Daten per REST aus DM holt

Veraltet

Hier gibt es auch schon eine Menge Infos von Aaron zum dem Thema:

NodeMap (jetzt: Andrés OpenWifiMap)

  • Was sind im Moment die größten Probleme?
    1. verschiedene Datenformate.
    2. nicht replizierbar.
    3. läuft nicht auf Smartphones/Tablets.
    4. Map skaliert nicht weltweit.
    5. Code unmaintained oder unmaintainable.
  • In einer GeoMap sollen alle Accesspoints sichtbar sein (Standort).
  • Sofern diese meshen (mindestens OLSR, besser auch batman), soll die Linkverbindung und Linkqualität angezeigt werden.
  • Schneller Überblick, wie groß ist FF?
  • Wo ist der nächste von mir aus vermutlich sichtbare AP?
    • Also irgendwie auch mindestens Einberechnen von Höhe der APs?
  • Anzeige technische Infos der APs (Verfügbarkeit etc.)
  • Wishlist: Vielleicht ginge auch eine "Bin hier, noch ohne Verbindung - passender AP gesucht"-Funktionalität
  • Social-Kram - die Teilnehmer anzeigen und direkt mit ihren Facebook etc.-Profilen verknüpfen?
    • "Zeige mir den nächsten FFler, der gerne lötet"
  • Gibt's besondere Services im FF-Netzwerk, die man nach außen sichtbar machen kann/will und die spannend sind?
    • ...
  • feste ewig gültige kurze schöne URLs für alles, was sich im System findet
  • einfaches REST-Interface