Ich habe etwas über Social Networking nachgedacht, nachdem ich mich der Diaspora Community angeschlossen hatte. Diaspora hat mich überzeugt. Klar ist, dass das Projekt im Alpha-Status nicht gerade ein Facebook-Gegener sein kann, aber die Ansätze sind klar vorhanden und das Potential liegt ebenfalls in vollem Mass vor.
Ich habe mir einige Gedanken dazu gemacht, wie Diaspora schneller bekannt und populär werden kann. Dazu habe ich Wissen aus der Netzwerktechnik und dem Web vereint und mir daraus eine Vision aufgestellt.
Diaspora verfolgt einen guten Ansatz, in dem es seine Server verteilt und jeder Besitzer eines Webservers einen eigenen Diasporaserver betreiben kann. Die Server können untereinander verbunden werden. Dies spart Geld, da die Server auf sehr vielen kleinen und bereits vorhandenen und bezahlten Ressourcen laufen können. Da so die Nutzerzahl auf einen Server eher beschränkt bleibt, ist die nicht ganz optimale Skalierbarkeit von Diaspora nur zweitrangig wichtig. Das aktuelle Konzept von Diaspora lässt mir einen Aspekt leider etwas zu sehr ausser Acht, welchen man bei verteilten Systeme dieser Art beachten sollte: die Skalierbarkeit.
Das aktuelle Konzept von Diaspora sieht vor, dass die Administratoren auf einer Diaspora-Instanz eigenhändig Verbindungen zu anderen Instanzen erzeugen müssen, dass die Nutzer der beiden Systeme kollaborieren können. Wenn man nun davon ausgeht, dass Diaspora mit derselben Geschwindigkeit wie Facebook seinerzeit wachsen könnte, wird genau dieser Aspekt zu einem Problem.
Der entscheidenen Vorteil von zentralisierten Systemen wie Facebook ist der, dass sich die Nutzer nicht überlegen müssen, ob ihr Freund, den sie in den Ferien kennengelernt haben, über ihren Server erreichbar sein wird oder nicht. Dies ist bei Diaspora nicht gegeben. Es ist möglich, dass mein Server denjeneigen des Freunden aus den Ferien nicht erreichen kann, somit verfehlt das SocialNetwork seinen Zweck.
Gesucht ist also ein Lösungsansatz welcher diese Mauer fallen lässt. Hier kommt das Wissen aus der Netwerk Welt ins Spiel. Denn Router innerhalb eines Netzwerkes sehen sich mit einer ähnlichen Problematik konfrontiert: Wie finde ich meine Nachbaren automatisch? Wie sende ich die Posts eines Nutzers an den richtigen Server, auch wenn ich diesen nicht kenne? Gelöst wir dies im Bereich der Netzwerke mittels einer Vielzahl unterschiedlicher Routing-Protokolle. Dieses Wissen und dieses Konzept kann nun auch auf ein verteiltes Soziales Netzwerk angewendet werden, denn Sie haben eines gemeinsam: Es sind beides Netzwerke und verteilte Infrastrukturen.
Wie könnte dies nun im Fall Diaspora aussehen? Wir möchten nun also den Diaspora-Server ‘Bern’ mit dem Diaspora-Server ‘Alaska’ bekanntmachen. Wie dies bei Routern der Fall ist muss natürlich zuerst eine Verbindung zwischen den zwei Instanzen bestehen. Dies wir mit einem sogenannten ‘Link’ realisiert. Links können grundsätzlich vom Administrator manuell oder aber vom Server autonom erstellt werden. Wir machen nun Instanz Bern mit Instanz Alaska bekannt. Nun kann der Benutzer ‘bob@diaspora-bern.ch’ mit seiner Flamme ‘alice@diaspora-alaska.com’ in Verbindung treten. Dies ist der einfachste Fall und braucht keine Routingfunktionalität. Wie sieht es jedoch aus, wenn der Server in Alaska noch einen weiteren Server in China kennt? Wie kann nun Bob in der Schweiz mit einer Ferienbekanntschaft aus Taiwan in Kontakt bleiben? Wie kann der Server in Bern herausfinden, dass sein Gegenüber in Alaska, den taiwanesischen Diaspora-Server kennt? (einfach dass keine Verwirrung entsteht – Diasporaserver sind nicht an Hoheitsgebiete oder Landesgrenzen gebunden, die hier geschilderte Ausgangslage dient als anschauliches Beispiel) Die Lösung der Netzwerkwelt zu dieser Fragestellung lautet: Routingtabellen. Jeder Router hat eine solche Routingtabelle in die er die Wege zu den gewünschten Netzwerken einträgt. Ein ähnliches Konstrukt könnte nun jede Diaspora-Instanz implementieren.
In diese ‘Linktables’ werde nun alle Netzwerke eingetragen welche manuell von einem Systemadministrator erstellt wurden. Der Server in Alaska trägt nun den Server in Taiwan mit Name und IP-Addresse in seine Linktable ein. Im Moment in dem Server Bern und Alaska verbunden werden, tauschen die beiden Server ihre Linktables aus. Der berner Server nimmt nun Alaskas Linkstable entgegen und vergleicht diese mit seiner eigenen Tabelle. Der Eintrag des Servers Taiwan fehlt in seiner Tabelle höchstwarscheinlich und wird nun hinzugefügt.
Bei klassischen Routingprotokollen würde nun der Router Bern seine Routingtable so ergänzen, dass er weiss: eine Nachricht für den Router in Taiwan muss über den Router in Alaska geleitet werden. Dies ist bei Routern deshalb notwendig, da der Router Bern keine physikalische Verbindung nach Taiwan besitzt, daher muss er den Umweg über den Router in Alaska gehen. Bei einem sozialen Netzwerk wie Diaspora ist dieser Schritt nicht notwendig, da die Netzwerkverbindung nach Taiwan besteht und sich der OSI-Stack darum kümmert, dass unser Nachrichten korrekt von Bern nach Taiwan gelangen. Der Diaspora Server in Bern trägt also einfach die IP-Adresse des Diaspora-Servers in Taiwan in seine Linktable ein, und erstellt eine direkte Verbindung nach Taiwan. Es ist somit kein Zwischenschritt über Alaska mehr notwendig. Somit erspahrt man dem Diaspora-Server in Alaska viel Datenverkehr, welcher ihm nichts nützt und reduziert die Latenzzeit bei der Übertragung zwischen den Servern.
Auf diese Art kann nun Bob auf dem Server in der Schweiz mit seinen Freunden auf dem Diasporaserver in Taiwan in Verbindung treten ohne, dass die Administratoren in Taiwan oder Bern einen neuen Link auf den jeweiligen Server erstellen.
Nun kann also ein Diaspora-Netzwerk auf die hier geschilderte Art selbständig konvergieren. Bedenken treten bei mir jedoch bei der Sicherheit der neu erstellten Verbindung zwischen Taiwan und Bern auf, denn das Einrichten der verschlüsselten Verbindung könnte mitgehört und somit die Verschlüsselung angreifbar werden. Da ich mich gerade entschlossen habe, dieser Idee etwas mehr Aufmerksamkeit zu schenken, werde ich ein Whitepaper aufsetzen worin ich auch den Aspekt der Sicherheit näher beleuchten werde. Ebenfalls weiterverfolgen werde ich den Spezialfall, dass ein Diaspora-Server einen anderen Server nicht in seine Routingantworten einbinden möchte, sodass dieser versteckt bleibt. Auch wichtig zu wissen ist, in welchen UseCases ein solchen Bedürfniss entstehen könnte.
