Das Jabber-basierte soziale Netzwerk: Eines für alle !
Johnny von Spreeblick ist offenbar genervt von der schieren Anzahl Hypes um neue Web-Services wie Facebook oder Twitter: Während diese wohl durchaus neue Kommunikationsmuster zulassen, sind ausnahmslos alle immer noch proprietäre Plattformen, die wohl eher mit umzäunten Spielplätzen als vergleichbar sind – wer bei Myspace ist, kann Nutzern von StudiKVZ keinen Antrag machen, virtuelles Angrabbeln ist auch nur im eigenen Netzwerk möglich und überhaupt braucht man, um noch mitzuhalten, über 9000 Accounts bei verschiedenen Anbietern.
Die Lösung liegt sozusagen seit Jahren auf der Straße: Jabber / XMPP kann alles Notwendige – u.A. Single- und Multi-User-Chat, Verschlüsselung (via PGP / GPG), sogar mit fremden Netzwerken kommunizieren. Wer also z.B. Twitter nachbauen möchte, installiere sich also einfach einen Jabber-Server samt SMS-Transport und sorge für ein ansehnliches Webfrontend. Zudem ist XMPP, da XML-basiert, erweiterbar; illustre Features wie Geolocation, Audio und Video kranken allerdings zur Zeit an bestenfalls mangelhafter Implementation. Dass die Anbindung an andere, zumeist proprietäre Netzwerke jedoch offenbar funktioniert, lässt die folgende Grafik wohl erahnen:
Angeregt durch Johnnys Beitrag möchte ich nun einen groben Implementationsvorschlag machen, der sich weniger mit der Nutzererfahrung, als vielmehr mit architektonischen Fragestellungen auseinander setzt. Hierzu ist zunächst einmal zu bemerken, dass die Neuentwicklung eines traditionellen Desktop-Clients nicht notwendig ist – eine Weiterentwicklung von z.B. Gajim (oder sogar Evolution) bedeutet einerseits weniger Entwicklungsaufwand, andererseits spart man sich die Administration von Repositories, Packaging und vieles mehr. Für maximale Penetration wäre allerdings ein Webservice eine gute Idee und genau da fängt mein Vorschlag an.
Die Ausarbeitung neuer Protokolle sowie Implementation von Server- und Client-Software ist mit Aufwand verbunden, zudem bedeutet eine Entwicklung neuer Protokolle und APIs eine weitere Fragmentation im Bereich freier Protokolle. Aus diesen Gründen schlage ich vor, Protokoll-Neuentwicklungen zunächst zu unterlassen und statt dessen bereits spezifizierte XMPP-Erweiterungen (z.B. das Nutzerprofil) zu implementieren; die resultierende Web-Anwendung könnte mit bestehenden Jabber-Servern und -Services wie Google Talk reibungslos zusammenarbeiten und das Momentum von Jabber / XMPP nutzen.
Beim Backend des hier erörterten (fiktiven) Clients handelt es sich um ein Programm, dass sich ausschließlich um das Senden und Empfangen von Nachrichten (d.h. XML-Streaming) kümmert. Ähnlich wie bei Yolanda beschäftigt sich das Backend des Clients kaum mit der Darstellung – diese Aufgabe fällt XSLT – einer Programmiersprache zum Umformen von XML-Dokumenten – zu (man erinnere sich: XMPP ist XML). Vorteil dieser Vorgehensweise ist eine komplette Unabhängigkeit des Frontends vom Backend – will man zusätzlich zu XHTML und RSS eine Darstellung in einem weiteren Dokumentenformat wie ATOM oder WAP, fügt man einfach ein weiteres XSL-Stylesheet hinzu. Ich habe das einmal skizziert:
(SVG)
Ob man meinem Vorschlag nun zustimmt, oder nicht, wichtig ist jetzt – da Johnny die Tauben aufgescheucht hat – ein Kristallisationspunkt für Ideen: Dank Josch existiert nun ein mit Trac verwirklichtes Wiki: Klick hier !