Einfach um die Welt zu inspirieren habe ich doch mal mithilfe von Ramaze und XMPP4R einen web-basierten PEP-Aggregator gebaut. Dieser wurde auch schon auf Planet Jabber von Dave Cridland erwähnt.
Er wird natürlich exzessiv von User Tune dominiert, da hier die allermeisten Updates kommen.
Übrigens experimentiert Twitter auch mit PubSub.
Bei Jabber hat sich was getan. Etwas, worauf ich schon eine ganze Weile gewartet habe. Der neue ejabberd 2.0.0 bringt nämlich Unterstützung für Personal Eventing via Pubsub mit.
Dabei geht es um Updates, die gut in das Schema Presence passen würden. Würden, denn eigentlich möchte man nicht jeden Buddy im Roster mit für ihn unwichtigen Informationen belasten. Das würde ja gar nicht skalieren, denn Presence Stanzas erhält jeder im Roster, dem man die Erlaubnis erteilt hat.
Wie das bei Jabber eben so ist, abstrahiert man da und hat für solche Funktionalität Publish-Subscribe erfunden.
Davon hat der ein oder andere sicherlich schon mal gehört, wird es doch hier und da als ein Killer-Feature angepriesen. Das Konzept könnte man grob mit Mailinglisten umreissen: es gibt Entitäten mit Owner- oder Publisher-Berechtigung, und es gibt Subscriber. Alles ist XML und Konfigurierbarkeit ist vorgesehen. Nur fehlte bislang die Umsetzung.
Wenn man sich diese Erweiterung anschaut, dann wird man ganz schnell von Komplexität, insbesondere was die Einstellungsmöglichkeiten betrifft, erschlagen. Soviel braucht man nicht um seine derzeitige Stimmung oder den aktuellen Musiktitel zu publizieren. Ausserdem trifft die Menge der Empfänger ganz gut auf einen Teil des Rosters zu. Deshalb hat man sich eben jenes PEP ausgedacht, ein rudimentäres Publish-Subscribe.
Das funktioniert nun so, dass man selbst, also die eigene Jabber-Id ein Pubsub-Knoten ist. Wenn der eigene Server das kann (findet man mit Service Discovery raus), dann braucht man dorthin einfach nur drauflospublizieren.
Das mit dem Empfangen gestaltet sich schon etwas komplizierter. Man hat dabei wieder mehrere Jabber-Grundsätze bedacht.
Es muss für viele Interessenten und viele Updates gut skalieren. Deshalb muss irgendwie herausgefunden werden, wer an den Informationen interessiert ist.
Man hat wieder einen großen Teil der Komplexität den Servern überlassen. Die übernehmen hier nicht nur das entgegennehmen und verteilen, sondern auch die Entscheidung, an wen verteilt wird.
Und wie bekundet man nun Interesse an Informationen?
Zuerst einmal sollte gesagt werden, dass diese Strukturen immer mit XML-Namespaces typisiert werden. Anhand derer wird nun unterschieden und wenn man sie verarbeiten kann, dann kündigt man das in der Service Discovery an. Für PEP hängt man da noch ein +notify dran.
Wenn man also beispielsweise an aktuellen Musiktiteln (http://jabber.org/protocol/tune) interessiert ist, dann wird da http://jabber.org/protocol/tune+notify draus.
Service Discovery ist aber nix was man in einer <presence/> mitschickt, dafür wäre es ein bisschen zu gewichtig. Die muss aktiv abgefragt werden (dafür gibts bei Jabber die dritte Art Pakete: <iq/>).
Hier hätten wir schon den nächsten Flaschenhals. Mein Server kann doch nicht jeden Buddy einzeln abfragen.
Dafür hat man sich einen Cache-Mechanismus einfallen lassen: Entity Capabilities. Hierbei werden die Informationen der Service Discovery zusammengehashed. Das kann irgendwie passieren, es muss nur halbwegs eindeutig sein. Zirka so eindeutig, dass gleiche Clients in gleichen Versionen mit gleichen Einstellungen mit, und darauf liegt eben der Fokus, gleichen Features den selben Hash haben.
Trifft man (im Falle von PEP der eigene Server) nun auf einen unbekannten Hash, so holt man sich die unterstützten Features des Senders und hält sie für weitere Clients mit dem gleichen Hash vor.
Zurück zu PEP: man muss also die Namespaces der gewünschten Informationen in Service Discovery ausspucken und schon erhält man Updates. Wenn man Empfänger ist, dann muss es der eigene Server auch gar nicht unterstützen. Aber zugucken ist ja langweilig.
Laut turbo24prg kann Pidgin bereits User Tune empfangen. Dies und User Mood können Psi und Gajim auch. Gajim kann auch noch User Activity und die SVN-Version seit ein paar Tagen auch noch publizieren. Bewundern kann man das dann in den Popups im Roster.
Adium zeigt auch irgendetwas an, laut klobs.
Aber die Zukunft wird uns noch mehr bringen. User Viewing ist für den aktuellen Film, User Gaming für das aktuelle Spiel und User Chatting informiert über aktuelle IRC- und MUC-Chats. Wer sich jetzt an den Kopf greift, der versteht auch Dienste wie Twitter nicht. Ich übrigens auch nicht.
Sinnvoller wirds dann schon mit User Browsing, was einfach mal URLs austauschen ist. Ich bin gespannt, ob das effizient benutzbar umgesetzt wird. Richtig interessant, und das finde ich eine wirklich interessante Anwendung, wird dann noch File Repository and Sharing.
Schon jetzt hätte ich Lust einen Web-basierten Aggregator für Tune, Mood und Activity zu bauen. Das wäre viel weniger Aufwand als ihn beispielsweise der Harvester erforderte. Aber noch benutzt PEP niemand. Noch unterstützen es zu wenig Server. Abwarten, bis die soziale Welle über Jabber rollt.
So langsam glaube ich wirklich, Jabber-Clients könnten in ein paar Jahren die Dienste ablösen, die sich Social Networking oder Web 2.0 nennen. Ich bin einerseits gespannt, ob wir dann immernoch auf kleinen, von Privatpersonen betriebenen Server hängen, oder wir kommerzielle Infrastruktur verwenden werden, so wie das beim heutigen Web 2.0 der Fall ist. Ausserdem spannend, wie das User Interface zukünftiger Jabber-Clients aussehen wird. Es bleibt ja scheinbar nicht beim lediglichen Message & Presence. Social Networks haben ein schickes 2.0-Design in Pastellfarben, alles ausserhalb des Browsers sollte sich aber einheitlich in das restliche GUI einfügen. Aber das ist wohl generell die Frage nach dem UI der Zukunft.
Kluge Menschen anonymisieren möglichst viele Internetverbindungen, die nicht auf Performance angewiesen sind, und welche Requests herumschicken, anhand welcher man ein Profil erstellen kann. Feedreader sind zum Beispiel ganz sinnvoll.
nulli fragte mich letzten August, ob es nicht möglich sei, jegliche TCP-Verbindungen eines Ruby-Programms durch einen Tor-Proxy umzuleiten. Ich schrieb ein Drop-in, welches den alten Konstruktor von TCPSocket umbenennt und einen neuen, welcher nach dem Verbindungsaufbau zu einem beliebigen festen Server eine SOCKS5-Verbindung zum gewünschten Ziel aufbaut.
Ich habe das Repository zwar schon einmal auf ruby-talk@ geschickt, aber es kamen keine Reaktionen. Deshalb veröffentliche ich einfach mal eine Version 1.0. Es muss doch paranoide anonymisierende Ruby-Hacker geben da draußen.
Da Releases zubereiten ziemlich Zeit frißt, habe ich mich nur um eine kleine Dokumentation und ein Gem gekümmert. Zum SOCKSifizieren eines beliebiges Ruby-Skripts genügen folgende Zeilen:
% sudo gem install socksify % tor & % socksify_ruby localhost 9050 skript.rb
Wie Henning gerade verifiziert hat, kann OpenBGPD nun endlich über Adressen aus dem Link-local scope (fe80::/10) peeren. Das ist eine häufig genutzte Konvention im DIAC24, weshalb man dort nun nicht mehr zu Quagga gezwungen ist und Wahlfreiheit hat. Die Wahl zu haben rockt.
Für die Benutzung muss man natürlich immernoch das Interface angeben. BSD-typisch sieht das so aus: fe80::cafe:babe:dead:beef%tun23.
Was auf dem 24C3 ganz großartig geklappt hat, sind die Mitschnitte. Davon sind bereits nicht zu wenige aufgetaucht als der Kongreß noch im Gange war. Ich habe auch schon in mehrere reingeschaut. Das sind dann Events die entweder mit meinem Schlafverhalten kollidierten oder bei denen mir nach der Hälfte die Füße zu weh taten. Eine sehr tolle Sache ist das also mit den Mitschnitten.
In entsprechendem Wikiartikel sind auch schon ganz viele Mirrors zu finden.
spaceboyz.net ist auch dabei. Nicht nur per HTTP & HTTPS, sowie IPv4 & IPv6, sondern auch per BitTorrent. Das würde ich mir von jedem Mirror wünschen, denn mein ungeschultes Auge und die nicht besonders ausführlichen Informationen von rtorrent sagen mir, es sind nicht sehr viele schnelle Seeder.
Dabei hat P2P so einige Vorteile gegenüber den klassischen Protokollen. Als erstes sind .torrent-Files natürlich mittlerweile auf vielen Desktops auch ganz einfach anklickbar.
Ausserdem kommt der (partielle) Integritätscheck for free, denn in BitTorrent sind immer kleine Stückchen (Pieces) mit Prüfsumme versehen. Ersetzt rsync, und HTTP sowie FTP haben das erst gar nicht.
In einer Mirrorliste muss man das Glück haben auch wirklich die schnellen zu finden, damit es einem den Downstream ordentlich saturiert. Entfällt mit P2P, sobald es genügend oder genügend schnelle Seeder gibt. Die müssen natürlich nicht handerlesen werden.
Bei BitTorrent kann man sich zwei Flaschenhälse überlegen: die .torrent selbst und die Tracker.
Die .torrent-Files können natürlich gespiegelt werden, ausserdem ist bei diesen kleinen Häppchen die Downloadgeschwindigkeit meistens unerheblich.
Die Tracker haben leider mit sehr viel Last zu kämpfen, da scheinbar sehr viele Ersteller dieselben verwenden, wie man dem sehr schönen Talk Tracker fahrn entnehmen konnte. Aber auch hier kann Redundanz gegeben werden, man schreibt einfach mehrere Tracker in die .torrent. So einfach ist das.
Fazit: mehr BitTorrent-Usage!
Vor einiger Zeit entdeckte ich bei irgendjemandem in der Suppe ein Zitat, welches wieder mal sehr schön einfach die Welt erklärt. Leider verlor ich es dann aus den Augen, habe es jedoch wiedergefunden, und statt es nur zu reposten, möchte ich es langlebiger hier festhalten:
Die wohlfeilste Art des Stolzes hingegen ist der Nationalstolz. Denn er verrät in dem damit Behafteten den Mangel an individuellen Eigenschaften, auf die er stolz sein könnte, indem er sonst nicht zu dem greifen würde, was er mit so vielen Millionen teilt. Wer bedeutende persönliche Vorzüge besitzt, wird vielmehr die Fehler seiner eigenen Nation, da er sie beständig vor Augen hat, am deutlichsten erkennen. Aber jeder erbärmliche Tropf, der nichts in der Welt hat, darauf er stolz sein könnte, ergreift das letzte Mittel, auf die Nation, der er gerade angehört, stolz zu sein. Hieran erholt er sich und ist nun dankbarlich bereit, alle Fehler und Torheiten, die ihr eigen sind, mit Händen und Füßen zu verteidigen. ― Arthur Schopenhauer