Nachdem ich euch das letzte Mal die Idee von sp!!k vorgestellt habe, wollte ich euch diese Woche erklären, was ich mir überlegt hatte, um die Theorie praktisch umzusetzen. Dabei sollte man wissen, dass mit der Umsetzung mehrere Fliegen mit einer Klappe geschlagen werden sollten:
- Es sollte möglich sein, dass man seinen eigenen sp!!k-Server betreibt, aber trotzdem andere Nutzer auf diesem Server arbeiten können.
- Es sollte möglich sein, alle wichtigen, schriftlichen Kommunikationsformen mit sp!!k abzudecken.
- Der Erzeuger eines Inhaltes sollte stets die Kontrolle über seine eigenen Inhalte haben.
- Spam sollte, soweit möglich, verhindert werden.
Fangen wir mit der Beschreibung der Lösung an der Wurzel an – den Conversations (engl. für “Gespräche”). Alle Gespräche laufen in sogenannten Konversationssträngen ab – diese bestehen aus einem Ausgangspunkt und beliebig vielen Anhängen (sogenannte Chapter [engl. für "Kapitel"]). Die Anhänge sind dabei selbst auch wieder Konversationsstränge, die Anhänge beinhalten können.
Nehmen wir als Beispiel ein Forum: In so einem Forum können Mitglieder “Threads” anlegen – das sind Themen, die besprochen werden sollen. Ein Thread besteht immer mindestens aus dem Ausgangspost und den Antworten der Threadteilnehmer. Je nach Forensoftware kann entweder nur auf den Ausgangspost geantwortet werden (wodurch alle Antworten automatisch zeitlich geordnet sind), oder aber man kann auf die Antwort eines anderen Threadteilnehmers antworten. Genau dies ist in sp!!k durch die Conversations und die Chapter möglich.
Aber nicht nur dort sind sie möglich. Ein gutes Beispiel sind E-Mail-Konversationen: Dort gibt es die verschiedensten Versuche, Konversationsstränge abzubilden – anhand der Betreffzeile, anhand der Empfängeradressen, anhand von zusätzlichen Header-Informationen… bei sp!!k handelt es sich beim “E-Mailing” einfach um eine Conversation (“Initial-E-Mail”) und beliebig vielen Chapters (“Antworten”).
Bei Chaträumen ist es wieder da gleiche: Irgendjemand eröffnet durch die erste Nachricht den Raum (die Conversation) und alle anderen können Antworten in diesen Raum posten.
Wer jetzt mitgedacht hat, weiß, dass es bei Webseiten natürlich der gleiche Vorgang ist: ein Inhalt (zB ein “Blogeintrag”) plus beliebig viele Kommentare… es ist immer das gleiche Bild. 
So eine Conversation (und damit auch die Chapter) zeichnen sich durch ein paar Besonderheiten aus. Zum einen gibt es für jede Conversation eine Art Access Control List , mit der der Initiator bestimmen kann, wer die Konversation lesen darf und wer der Konversation weitere Kapitel hinzufügen darf. Über diesen Mechanismus wird der Unterschied zwischen öffentlichen Inhalten und privaten Inhalten erreicht: Eine “E-Mail” hat also eine sehr strenge ACL, während eine öffentliche “Webseite” eine weitreichende ACL hat. 
Zudem besitzt so eine Konversation eine Art Haltbarkeitsdatum – je nach Aufgabe (E-Mail, Webseite oder Chat) muss so ein Inhalt nämlich unterschiedlich lang gültig sein. Die Haltbarkeitsspanne fängt an bei “für immer” und endet bei “bis die Nachricht abgerufen wurde” .
Der nächste Punkt dürfte ein wenig überraschend sein: ALLE Inhalte, die jemand produziert, verbleiben in dem Speicherbereich dieser Person. Dabei ist es egal, ob es sich um eine Webseite, einen Forenbeitrag, eine Chatnachricht oder um eine E-Mail handelt. Es gibt keine Inhalte, die irgendwo anders hin dupliziert werden oder ähnliches.
Dadurch wird gewährleistet, dass jeder sp!!k-Nutzer zu jederzeit bestimmen kann, welche seiner Inhalte abrufbar sind und von wem diese abrufbar sind. Ein netter Nebeneffekt ist, dass Spam-Nachrichten damit (hoffentlich) effektiv unterbunden werden. Der Grund ist, dass ein Spamer jede Spam-Nachricht in seinem eigenen Bereich aufbewahren muss. Sollte sich eine Nachricht also als Spam herausstellen, könnte man soetwas wie eine Blacklist verweden, um andere Empfänger vor dieser Nachricht zu warnen.
Jetzt stellt sich der ein oder andere sicherlich die Frage: “Wenn die Nachrichten beim Absender bleiben, wie weiß der Empfänger dann, dass er sie lesen soll?”
Genau dafür gibt es sogenannte Calls (engl. für “Anrufe”). Sollte ein neues Dokument veröffentlicht werden, das an eine (oder mehrere Personen) addressiert ist, wird den Empfängern ein Call zugesendet, der ihnen mitteilt “hier gibt es eine neue Nachricht, auf die ihr Zugriff habt” . Neben diesen Calls für private Inhalte kann man zudem die Calls öffentlicher Inhalte abonnieren – damit man zB über neue Blogbeiträge informiert wird.
Da öffentliche Inhalte normalerweise nicht per Call verteilt werden, gibt es für sie zwei Catalogs (engl. für “Kataloge”), in denen alle öffentlichen Inhalte indiziert werden. Dabei ist der eine Katalog für lokale Conversations gedacht (Konversationen, die nur Mitglieder des eigenen Servers lesen dürfen) und ein Katalog für globale Konversationen (also Conversations, die auch von Mitgliedern anderer Server gelesen werden dürfen).
Und da wären wir auch schon beim letzten Thema für heute: andere Server. Ich habe mir sp!!k als Mischung zwischen einem zentralen und einem dezentralen Netzwerk vorgestellt. Dafür gibt es einige Gründe: So wird es wahrscheinlich Nutzer geben, die lieber ihren eigenen Server betreiben wollen, um ihre Daten keinem Provider anvertrauen zu müssen. Andere wiederum haben wahrscheinlich garnicht die Technik und das Wissen, um einen Server zu betreiben – die werden dann auf freie oder bezahlte Angebote zurückgreifen. Natürlich sollen trotzdem alle die Möglichkeit haben, miteinander zu kommunizieren, wenn sie das wollen.
Um nun den Zugriff auf die Inhalte eines anderen Servers zu erleichtern, habe ich mir überlegt, dass es das einfachste wäre, jeder Conversation einen eindeutigen Namen zuordnen zu lassen. Die URL-Struktur habe ich mir so vorgestellt:
spiik://Username@Host:Port/Conversation Wenn solch eine URL nun auf einen fremden Host zeigt, soll sich der eigene Server zu dem fremden Server verbinden, die Identität sicherstellen und anschließend den Inhalt abrufen und an den User weiterleiten. Wie das ganze sicherheitstechnisch ablaufen soll, erkläre ich euch beim nächsten Mal… 
Konversationsgrüße, Kenny