Gegenstrategie
- Daten bleiben beim Nutzer
- Daten liegen in einem standardisierten Format vor
- Der Nutzer entscheidet, wohin er seine Daten (als Kopien) verteilt
- Was der jeweilige Server mit den Daten anstellt, bleibt ihm überlassen (Layout)
Scenario 1: World Outline
Dave Winers Flucht aus den Datensilos.
World Outline
- OPML Editor als (Web-) Server auf dem Desktop
- Die Daten werden sowohl lokal gespeichert als auch als OPML-Dateien nach Amazon S3 hochgeladen
- Andere OMPL Editoren können auf diese Daten (nach Freigabe/Bekanntgabe der URL) zugreifen
- Das können sowohl lokale Server als auch Server z.B. auf Amazon EC2 sein (EC2 for Poets)
- Synchronisierung mit der Dropbox.
River of News
River of News und Radio2
River2:
- Twitter »für Arme«
- RSS-Reader, der einen »Nachrichtenfluß« erzeugt
- »Retweet«-Button
- Teil des OPML Editors
- Funktioniert Peer to Peer sowohl auf dem Desktop als auch auf einem Server
Radio2
Radio2:
- Eine (minimalistische) Reinkarnation des legendären Radio Userland
- Schreibt »nur« noch RSS heraus
- Geschaffen, um Software wie River2 zu »füttern«
- Kann auch zum Verteilen von Podcasts genutzt werden
Threads
Fazit 1
Mit Threads und River2 ist die World Outline
- Eine Art Peer-to-Peer-Facebook
- mit einem Twitter-ähnlichen Nachrichtenfluß
- und einer Art Labortagebuch
Kommentare via Disqus (ist inkonsistent, ich weiß – könnte man hier noch auf dem Server (OPML Editor) erledigen, aber für statische Seiten (kommt später) sehe ich keine Alternative)
Das Konzept ist genial, aber …
- Die Software ist etwas in die Jahre gekommen (kein UTF-8)
- Es gibt kaum (andere) Server, die OPML-Dateien erstellen oder verarbeiten
Scenario 2: World Markdown
Mein Fluchtplan: Mit Markdown aus den Datensilos.
World Markdown
- Markdown-Dateien werden im Texteditor erstellt (in meinem Fall mit TextMate)
- Eine Template-Engine (RubyFrontier) generiert daraus statische HTML-Seiten.
- Diese werden zusammen mit den Markdown-Dateien auf einem Server der Wahl abgelegt (in meinem Fall auf Amazon S3).
- Synchronisierung mit der Dropbox.
- Realisiert mit RubyFrontier und Twitter Bootstrap.
Node Types
- Verschiedene Node Types (Threads, Blogpost etc.) werden durch unterschiedliche Templates realisiert.
- Bisher implementiert: Threads, Blogpost, Photo, Essays (Worknotes), Galerie
- Kommentare via Disqus (ist immer noch inkonsistent, aber da es hier um statische Seiten geht, sehe ich wirklich keine andere Alternative, als die Kommentare »zuzukaufen«)
Threads
Worknotes
Photo
Galerie
Die Navigation unter den Photos wird automatisch erzeugt.
Markdown
Markdown ist eine einfache Auszeichnungssprache, für die es Tools gibt, die sie sowohl nach HTML (Website, Ebook) als auch nach LaTeX herausschreiben.
Alternativen
- Jekyll: Ebenfalls Markdown, aber in meinem Augen zu »bloggish«
- nanoc ist ein weiterer in Ruby geschriebenes Tool, das mit Markdown umgehen kann und statische Seiten herausschreibt. Sehr vielversprechend, aber der Bedienungskomfort ist noch verbesserungsfähig (Terminal).
- Emacs Org-mode: Lange Zeit mein Favorit, aber leider nicht »Geisteswissenschaftler kompatibel«
Pros und Cons
- Einfache Erstellung (+)
- Sehr flexibel und erweiterbar (+)
- RSS-Feeds müssen (noch) mühselig von Hand erstellt werden (aber wir arbeiten daran) (-)
- Aus historischen Gründen ist das Markdown von RubyFrontier (noch) nicht überall »standard-konform« (aber wir arbeiten daran) (-)
- Zur Zeit läuft RubyFrontier nur unter MacOS X mit TextMate (aber …) (-)
Nächste Schritte
- Einen Server zum Einlesen und verarbeiten der Markdown-Dateien entwickeln, der sowohl auf dem Desktop als auch auf einem Server oder in der Cloud läuft.
- Als Basis-Engine werde ich web2py nehmen und diese dann eventuell auf Googles App Engine (kostenlos) implementieren.
- Einen News River für diesen Webserver implementieren.
- Das wäre dann die Grundlage für eine Peer-to-Peer World Markdown
Zurück in die Zukunft
- Github ist ebenfalls ein hervorragendes Publishing-Tool für Markdown-Dateien (erspart einem unter Umständen den »eigenen« Server)
- Eine Server-Implementierung auf Heroku (anstelle von Googles App Engine) habe ich ebenfalls schon angedacht
- Erweiterung für (HTML5-) Videos (denn das Netz ist multimedial)
- Markdown, Fußnoten, Tabellen und mathematische Formeln (die Frage nach den Supersets)
Let's Do It
Fassen wir zusammen:
- Ziel ist der Entwurf und die Implementierung eines Peer-to-Peer Social Networks, das den Nutzer nicht entmündigt.
- Er bleibt Herr seiner Daten
- Er entscheidet, wer auf seine Daten zugreifen darf und mit wem er diese diskutiert
- Die Nutzung ist so einfach wie möglich
- Die Nutzung kostet so wenig wie möglich
In der besten aller Welten …
Da wir (leider) nicht in der besten aller Welten leben:
- Als kostengünstige Datenablage sind Cloud-Anbieter wie Amazons S3, Dropbox, Github etc. unproblematisch, da die Daten immer noch einmal beim Nutzer bleiben (das befreit von teuren ISPs)
- Auch im Falle politischer Repressionen (Zensur, Wikileaks) ist es einfach, die Daten auf einem anderen Server (Island) zu transferieren und erneut zu publizieren
- Wissenschaftsnomaden: Auch sie behalten ihre Daten und Ergebnisse unter ihrem Einfluß und können sie trotzdem anderen Instituten zur Publikation zur Verfügung stellen.
