Swift 1.0 Released
Gestern wurde der OpenSource XMPP/Jabber-Client Swift in seiner ersten "reifen" Version 1.0 herausgegeben.
Bei Swift handelt es sich um einen sehr schlicht gehaltenen, aber technisch sehr interessanten und leistungsfähigen Jabber-Client.
Er ist besonders für Leute geeignet, die sich keinerlei Gedanken um das wie machen wollen, sondern nur um das dass - er bietet kaum Einstellmöglichkeiten, sondern funktioniert einfach.
Mehr Infos und Download unter: www.swift.im
Swift Kontaktliste
Swift Chatfenster
(Quelle der Bilder: swift.im)
Persönliche Meinung: Sehr guter Client "für die Massen", einfach, schick und technisch einwandfrei.
Was richtige "Power-User" wohl abhalten wird, sind der (tw. noch) fehlende Funktionen wie GPG-Unterstützung, kein Message Delivery Receipt (dafür aber partiell Stream Management!) oder auch LocalStorage. Derzeit unterstützt der Client nur einen Account gleichzeitig, wer mehr hat, guckt in die Röhre. Das wird sich aber vielleicht schon mit dem diesjährigen GSoC ändern. Generell läuft das Programm allen gängigen Betriebssystemen. Einfach mal ausprobieren!
Unterschiede zwischen Jabber und XMPP
versus
Was sind eigentlich die Unterschiede zwischen Jabber und dem XMPP-Standard?
Diese Frage haben sich bestimmt einige schon gestellt. Die Suche im Internet führte (jedenfalls mich) auf die Schnelle nicht zu einer befriedigenden Antwort. Entweder werden die Begriffe gleichgesetzt oder aber XMPP wird nur als die "standardisierte" Version von Jabber bezeichnet.
Nun, das stimmt natürlich auch mehr oder minder. Und dass die Unterschiede überschaubar sein würden, davon konnte ausgegangen werden. Schließlich ist aus dem in der Community entwickelten Jabber das von der IETF offiziell abgesegnete XMPP geworden. Nun bin ich auf eine Auflistung der Unterschiede gestoßen - am dafür naheliegendsten Ort, nämlich dem Standard-RFC selbst (RFC3920). Hier einmal kurz (und hoffentlich korrekt 
) zusammengefasst, was dort so aufgelistet wird:
Channel Encryption
Bei Jabber war SSL vorgesehen. Bei XMPP wurde der "Nachfolger" TLS vorgeschrieben.
Authentication
Beim XMPP wurde das standardisierte SASL-Verfahren für die Authentifizierung festgelegt, bei Jabber wurde diese wohl in einer selbstgebackenen Lösung realisiert. Für die Server-zu-Server Verbindung wurde vor der Standardisierung kein vollständiges Verfahren festgelegt. Auch hier springt bei XMPP SASL in die Presche.
Resource Binding
Das Hinzufügen der vorgeschriebenen Ressource-ID war früher Teil des Authentifizierungs-Mechanismus, heute wurde dafür ein eigener Namespace definiert
JID Processing
Die Verarbeitung von JID's waren schlecht oder gar nicht definiert. Dieser Missstand wurde im XMPP behoben.
Error Handling
Im XMPP wurde ein erweiterter Mechanismus eingeführt, welcher sich um die Fehlermeldung innerhalb von Streams und Stanzas kümmert. In Jabber wurde hier wohl mit HTTP-ähnlichen Error-Codes verwendet.
Internationalization
Auch wenn UTF-8 schon seit eh und je in Jabber verwendet wurden, wurde keine Möglichkeit vorgesehen, um die Sprache des menschenlesbaren Parts zu definieren. Hierfür wurde im Standard ein "xml:lang"-Attribut eingeführt.
Stream Version Attribute
XMPP führt für Streams eine Versionierung ein, welche es beispielsweise ermöglichen soll, Rückschlüsse auf die Unterstützung für verschiedene Authentifizierungs- und Verschlüsselungsmechanismen zu signalisieren.
So, mehr wird im RFC nicht aufgelistet. Klingt ja nach recht sinnvollen Änderungen, die sie da vorgenommen haben. Vielleicht hilft diese Zusammenstellung ja mal dem Einen oder Anderen, der eine Präsentation oder ähnliches über das Protokoll halten will oder sich einfach auch fragte, was sich wohl geändert haben mag. Fest steht jedenfalls, dass der Name Jabber (zu deutsch: plappern, quasseln) wesentlich leichter von der Zunge geht, als XMPP - von daher wird er wohl (zu Recht) langfristig ein Synonym hierfür bleiben.
Das XMPP-Logo steht unter dem Copyright der XSF, vgl. [1], [2].
XMPP/Jabber ist doof, weil…
Genug gelobt. Wollen wir doch mal motzen.
Jabber/XMPP ist doof, weil...
- ...die Clients (und auch Server) oft kleinere Bugs haben, die nerven.
- ...die praktischsten XEPs oftmals nur von wenigen Clients und Servern unterstützt werden.
- ...Dateitransfers über peer2peer-Verbindungen in "verwinkelten" Netzwerken nicht ohne Proxy funktionieren.
- ...Server und Clients merken teilweise erst spät, dass die Verbindung zwischen Ihnen abgebrochen ist, weil sie dafür relevate Protokollerweiterungen (z.B. XEP-0199) nicht implementieren und richtig nutzen, was dazu führen kann, dass Nachrichten verloren gehen (ebenfalls wegen nicht implementierter XEPs, vgl. hier).
- ...(menschenlesbares) XML ein gutes Stück mehr Bandbreite braucht, als eine kompakte Binärkodierung (kleiner Scherz am Rande dazu). Dies ließe sich durch eine sauberere Implementierung diverser Erweiterungen zwar reduzieren, aber es bleibt ein großer Overhead.
- ...es einfach zu wenig aktive Nutzer gibt.
- ...fast alle Entwickler von Servern und Clients ihr eigenes Süppchen kochen und nicht zusammenarbeiten.
So, wenn mir noch etwas einfällt, wird die Liste ergänzt. Soll mir keiner nachsagen, ich würde einseitig über Jabber schreiben
XMPP – Ein (abwärts-)kompatibles Protokoll
Wenn man Aufzählungen mit den Vorzügen von XMPP liest, sticht einem häufig die Eigenschaft der (Abwärts-) Kompatibilität ins Augen. Nun, aber was bedeutet das eigentlich?
Früher ging ich davon aus, dass damit schlicht und ergreifend gemeint ist, dass wenn sich das Protokoll ändern sollte, bzw. eine neue Version davon erscheint, alte "XMPP-1.0"-kompatible Clients trotzdem noch funktionieren werden. Das stimmt auch.
Allerdings ist das nicht der einzige Aspekt, der diese Eigenschaft erfüllt: Damit ist auch gemeint, dass das Extensible (!!!) Messaging and Presence Protocoll auch so designed ist, dass Clients/Server, die Erweiterungen (XEPs) anbieten nicht die Kompatibilität zu eben solchen, die diese nicht unterstützen, zunichte machen. Die schlichtest-mögliche Implementierung des Protokolls (Server oder Clientseitig) funktioniert immer noch mit der theoretisch "höchsten Ausbaustufe".
Das ist jetzt keine allzu große Erkenntnis, aber bei mir hat es ein Weilchen gedauert, bis ich den Zusammenhang erkannte.
Warum man Jabber/XMPP nutzen sollte
Ich nerve gerne. Zumindest dann, wenn ich von einem Thema begeistert bin. So ein Thema ist auch Jabber/XMPP. Daher ist es höchste Zeit, hier einen Blogeintrag zu verfassen und darüber ein wenig zu schreiben - allein schon, damit ich zukünftig meinen "Opfern" nur diesen schicken kann und nicht immer auf's Neue lange Reden verfassen muss Ich werde das hier von der technischen Sicht her versuchen, so simpel wie möglich zu halten und auch einige Details eindampfen (ist nicht ganz einfach, wenn man angehender Software-Engineer ist und in der Materie drin ist ), auch wenn manches dadurch genau genommen nicht mehr zu 100% stimmt bzw. unvollständig ist. Wer sich wirklich für die Technik dahinter interessiert, wird das schnell in anderen Quellen finden können (Wikipedia ist unser aller Freund *g*).
Also, dann fangen wir doch mal an. Nun, zunächst sei zu erwähnen, dass die Begriffe „Jabber“ und „XMPP“ quasi gleichzusetzen sind. Ich werde sie ab jetzt bunt mischen .
Was ist dieses Jabber/XMPP eigentlich?
Jabber ist ein kostenloses Chatprotokoll, vergleichbar mit MSN oder ICQ. Es gibt jedoch eine ganze Reihe Unterschiede, auf einige werde ich weiter unten eingehen. Die Jabber-Adressen sehen folgendermaßen aus Benutzername@Anbietername.bla , also exakt so, wie E-Mail-Adressen aufgebaut sind.
Warum Jabber? Was für Vorteile habe ich dadurch?
- XMPP ist ein freies Protokoll - es "gehört" also niemandem. Wenn ICQ pleite geht oder kostenpflichtig werden würde, dann hieße es "Aus die Maus!". Jabber indes ist ein offenes, standardisiertes (!) Protokoll.
- XMPP ist flexibel und abwärtskompatibel - Man ist nicht gezwungen, nach ein paar Monaten/Jahren das Programm zu wechseln, weil die Entwickler etwas geändert haben und das Alte nicht mehr geht.
- Es ist generell an kein Programm gebunden - man hat die freie Wahl. Das führt natürlich zu dem einen oder anderen Vorteil, z.B. haben die Chatprogramme/Clients keine Werbeeinblendungen und sind zumeist nicht klickibunti-überladen. Auch bremsen sie den Rechner nicht so aus, wie beispielsweise das ICQ-Programm.
- Jabber sieht von vornherein Verschlüsselung vor, was dafür sorgt, dass die Dialoge von dritten nicht einfach mitgelesen werden können.
- Wenn man bedenkt, dass Google, Web.de/GMX/1und1, Facebook und StudiVZ auf Jabber setzen, brauche ich nicht zu erwähnen, dass das Protokoll wirklich gut ist und sich in Zukunft wohl auch weiter durchsetzen wird.
- Man kann an mehreren Rechnern (oder auch Mobiltelefonen..) gleichzeitig online sein und wird nicht „herausgeworfen“.
- Chaträume lassen sich einfach mit wenigen Klicks erstellen, somit kann man mit mehreren Leuten in einem Fenster gleichzeitig chatten.
Was spricht gegen die anderen Protokolle?
- Der Zwang zu einem speziellen Programm, welches mitunter Sicherheitslücken mitbringt und dadurch den Computer gefährdet (war bei ICQ des öfteren der Fall...)
- ICQ beispielsweise schreibt in seinen AGBs, dass sie sich das Recht herausnehmen, alles, was von den Nutzern geschrieben wird, frei zu verwenden und daran die Copyrights zu haben. (Vgl.: Wikipedia )
- Bleiben wir mal bei ICQ: Vor kurzem wurde es von AOL an eine russische (sehr vertrauenserweckend...) Firma für über 187 Millionen Dollar verkauft - es wird also mit aller Macht versucht, Profit aus den Nutzern - euch - zu schlagen.
Nachteile von Jabber - Sind wir mal fair
Natürlich gibt es auch den einen oder anderen Nachteil, das will ich nicht verschweigen.
- Es ist noch weniger weit verbreitet, was dazu führt, dass man mitunter trotzdem noch sein vertrautes ICQ oder MSN parallel nutzt, um mit anderen Leuten zu kommunizieren. Dass es sich hierbei um einen Teufelskreis handelt, brauche ich nicht zu erwähnen. Aber meine Kontaktliste wächst stetig, es geht also voran.
- Da es nicht "den einen, heiligen Gral" als Programm gibt, zu dem man quasi gezwungen wird, ist so manch einer ein wenig abgeschreckt. Aber es ist alles kein Hexenwerk, ganz im Gegenteil, versprochen.
- Um Daten zu versenden, KANN es sein, dass man ein wenig an den Einstellungen spielen muss, bis es geht. Wobei das bei ICQ bei mir auch nicht immer funktioniert hat.
- Es gibt sogar die Möglichkeit, zu telefonieren und Videokonferenzen zu halten, jedoch unterstützen das noch nicht viele Programme und es funktioniert in manchen Netzwerken derzeit eher schlecht als Recht. Aber GoogleTalk ist ein Beispiel dafür, dass es auf jeden Fall auch gut funktionieren kann – andere Programme müssen hier noch verbessert werden.
Neugierig? Was brauche ich zum Ausprobieren?
Da Jabber ein Protokoll-Standard ist, gibt es kein offizielles Programm von irgend einer Firma. Daher hat man die Wahl zwischen verschiedenen Programmen, wovon ich einfach mal zwei (drei) herauspicken möchte.
- Psi (www.psi-im.org) Ist ein reinrassiges Jabber-Programm. Es ist relativ schlicht, sieht meiner Meinung nach aber dennoch gut aus. Ich verwende es seit geraumer Zeit.
- Pidgin (www.pidgin.im) ist ein Chatprogramm, das neben XMPP auch andere Protokolle, wie zum Beispiel ICQ, Facebook (welches aber auch Jabber einsetzt...),MSN, Yahoo und viele mehr unterstützt. Es ist ebenfalls übersichtlich und schlank.
- Ein Programm, welches durch seine Einfachheit besticht, ist Swift (www.swift.im ), jedoch befindet es sich noch in der Entwicklung (Januar 2011), daher empfehle ich es nur eingeschränkt – wenngleich es bei mir im Test wunderbar funktionierte. Wenn es fertig ist, wird es aber von der Nutzerfreundlichkeit bestechend sein – perfekt für Menschen, die sich nie mit Konfigurationen beschäftigen wollen und sich ein Stück Software wünschen, das einfach funktioniert und dabei auch noch gut aussieht.
Wie man die Programme konfiguriert, ist sehr schön unter einfachjabber.de erklärt.
Um Jabber zu nutzen, muss man sich einen Account auf einem Server anlegen (vgl. auch einfachjabber.de), so denn man nicht schon einen hat. Woher ihr schon einen haben sollt? Nun, beispielsweise wenn ihr eine E-Mail-Adresse von GoogleMail, Web.de oder auch GMX habt -> hier könnt ihr euch einfach mit den Login-Daten anmelden und ab geht die Post. Sollte dem nicht so sein, würde ich spontan zu jabber.ccc.de raten.
Es ist wirklich kinderleicht, glaubt mir einfach
So, das sollte jetzt mal ein 'kleiner' Abriss über Jabber und XMPP sein. Vielleicht kann ich ja den einen oder anderen 'bekehren', würde mich freuen! Wir sehen uns in Jabber, erreichbar bin ich unter
zwei-und-vierzig {Ät-Zeichen} jabber.org
Bis dann und danke für's Lesen! 
Weiterführende Links:
- http://www.einfachjabber.de - eine sehr gute Seite für den Einstieg. Erklärt die Einstellungen in verschiedenen Programmen etc.
- http://j-u-n-e.org/wiki/JUNe/Jabber-Einfach – Argumente für Jabber
- http://de.wikipedia.org/wiki/XMPP_Extension_Protocol - wer sich mit der Technik befassen möchte, sind aber auch noch ganz ein paar Hintergrundinfos aufgelistet.
- http://www.xmpp.org Offizielle Seite, auf welcher der Standard definiert ist.
- http://blog.jbbr.net/against-icq/ - Argumente gegen ICQ und für Jabber.
Das XMPP-Logo steht unter dem Copyright der XSF, vgl. [1], [2].
Psi+ und Acknowledgements via XEP-0184 & XEP-0198
Ich ja bin ein riesen Fan vom Jabber/XMPP-Protokoll (ich werde da auch irgendwann mal hoffentlich drüber schreiben...). Als Client verwendete ich eigentlich immer Psi und war relativ zufrieden. Jetzt habe ich die Tage aber Psi+ für mich entdeckt. Es handelt sich dabei um einen (wenn ich es richtig verstehe russischen) Fork von Psi, welcher Patches und neue Funktionalität mit integriert. Ich kann nur sagen: Da geht was! Kann ich wirklich nur weiter empfehlen.
Da ich in letzter Zeit immer wieder mit Leuten "gejabbered" habe, die eine unstabile Internetverbindung haben, hat es mich immer sehr gefuchst, dass ich nie wusste, ob eine Nachricht jetzt angekommen ist, oder nicht, da keine Acknowledges im Standard festgelegt sind (was auch okay ist, da XMPP ja sehr leichtgewichtig und dafür umso erweiterbarer ist). Meine große Hoffnung war daher das Google Summer of Code-Projekt von Tobias Markmann, bei welchem er XEP-0198: Stream Management für Psi implementiert hat. Ich habe mir den Standard nicht ganz durchgelesen*, kann also nicht allzu viel dazu sagen, was er noch kann, aber mit ihm sind Server-ACKs möglich und man weiß dadurch, ob eine Nachricht beim Server angekommen ist und was nicht. Aber ich fürchte, bis das in allen Jabber-Servern integriert (sowohl implementiert als auch im Live-Einsatz) ist, wird es noch lange dauern.
Über Psi+ bin ich nun auf die XEP-0184: Message Receipts [Aktualisierung, 12.03.2010: Der Name der Erweiterung wurde zu "Message Delivery Receipts" geändert] gestoßen (keine Ahnung, warum ich die XEP immer überlesen habe...), bei welchem der Client eine Message-Stanza schickt, in der er den Empfang bestätigt. Natürlich müssen beide Clients die XEP implementiert haben, aber dann funktioniert das super. Der Sender schickt in seiner Nachricht die Anforderung nach einem ACK mit und der Empfänger schickt ein "received" zurück. Das funktioniert auch, wenn der Empfänger zwischenzeitlich offline (==Offmessage) war mit Psi+ super. Ein sehr cooles Feature, das muss ich sagen. Vor allem weiß man so, dass die Nachricht wirklich beim Empfänger angekommen ist und nicht nur beim eigenen Jabber-Server*. Das war genau das, was ich gesucht habe und trifft es noch eher als die XEP-0198*. Hoffentlich werden das bald noch mehr Clients beherrschen! [Nachtrag 29.12.2010: Wie ich festgestellt habe, beherrscht Miranda IM ebenso XEP-0184; Receipts werden automatisch bestätigt und auf Wunsch (=wenn in den Optionen gewählt) auch angefordert.; 16.01.2011: Gajim unterstützt die Funktion standardmäßig auch.]
*[Update (06.02.2011): Nun, mittlerweile habe ich mir die XEP-198 einmal genau durchgelesen und muss meine Aussagen etwas revidieren. Der Standard erfüllt meine Ansprüche - sogar wesentlich besser, als XEP-0184. In diesem Fall prüft der Server nämlich auch, ob der Client die Nachricht wirklich bekommen hat - andernfalls lässt er sie im Offline-Speicher. Es ist eine interessante Technik, die über die drei "Standard-Stanzas" von XMPP hinausgeht, weil es auf ein tieferen Ebene angesetzt ist. Jedoch ist sie auch wesentlich aufwendiger zu implementieren und -besonders wichtig- sowohl vom Client als auch vom Server unterstützt werden. Und darin ist wohl auch der große Nachteil: Selbst das simple "Message Receipts" wird ja bei weitem nicht von allen Clients unterstützt, "Stream Management" erst recht nicht. Nun, vielleicht wird sich das in ein paar Jahren ändern und Message Receipts wird nur eine Fallback-Lösung, solange finde ich aber, ist es eine simple und ziemlich praktische Erweiterung des XMPP-Protokolls.]
Ja, soviel mal kurz zwischen drinnen von mir. Vielleicht kannte der eine oder andere Psi oder Psi+ ja noch nicht, und ist jetzt daran interessiert. Und wer noch gar keine Ahnung von Jabber hat, dem empfehle ich einfachjabber.de, da wird das ganze sehr schön anschaulich und praxistauglich erklärt, auch für Leute, die sich absolut nicht mit Computern/Software auskennen und sie einfach nur nutzen wollen (soll es ja geben )
P.S.: Nutzt Jabber zum Chatten!