PubSubHubbub - Publizieren auf allen Kanälen?

1266672597|%d.%m.%Y

Wer heute im Netz publiziert, tut das immer seltener nur noch an einem Ort. Neben eigener Webpräsenz, eigenem Blog werden immer häufiger auch Microblogging-Services und Social-Networking-Plattformen genutzt. Meist mehrere gleichzeitig. Je mehr solcher Services jedoch bedient werden wollen, desto mehr Zeit geht dafür drauf. Der Wunsch nach automatischem „Publiziere-das-überall“ wird stärker. PubSubHubbub ist eine technische Lösung dafür. Ob sie in jedem Fall sinnvoll ist, steht auf einem anderen Blatt.

Fast alle Social-Media-Plattformen generieren aus den Inhalten, die dort publiziert werden, benutzerindividuelle Feeds. Der Vorteil von Feeds ist, dass die Inhalte dadurch aus dem ursprünglichen Publikationsort herausgelöst und in andere Publikationsorte eingespeist werden können. Das Problem dabei ist nur: wie erfährt die Zielplattform eines dort eingespeisten Feeds davon, wenn sich der Feed in der der Ursprungsplattform geändert hat?

Eine Möglichkeit sind Poll-Verfahren, bei denen die Zielplattform in regelmäßigen Abständen bei der Ursprungsplattform nachfragt, ob sich der Feed geändert hat. Besonders intelligent ist das jedoch nicht, da häufig nachgefragt wird, obwohl sich gar nichts geändert hat, und wenn sich etwas geändert hat, dauert es bis zur nächsten Nachfrage, bis die Änderungen dort übernommen werden. Besser geeignet sind Push-Verfahren. Dabei teilt die Ursprungsplattform abonnierenden Zielplattformen automatisch mit, wenn ein Feed geändert wurde, sodass die Zielplattform die neuen oder geänderten Inhalte des Feeds sofort übernehmen kann. Eine technische Lösung dafür bietet das PubSubHubbub-Protokoll.

PubSubHubbub steht für Publish (Publizieren), Subscribe (Abonnieren) und Hubbub (Tumult, Radau). Im letzteren Wort steckt auch das Wort Hub, was in der Netzwerktechnik ein Netzknotengerät bezeichnet. Außerdem steckt in der Gesamtbezeichnung auch das Wort PuSH.

Das Verfahren besteht darin, dass zusätzlich zum Webserver ein Hubserver zum Einsatz kommt. Hub-Server sind selbst unter HTTP-Adressen erreichbar. Auf der Projekt-Homepage von PubSubHubbub ist eine Liste bekannter Hub-Server zu finden.

pubsubhubbub.png

Wichtig zum Verständnis ist, dass Publisher und Subscriber in diesem Fall normalerweise keine einzelnen Personen bzw. deren Client-Programme sind, sondern eher große Networking- und Microblogging-Plattformen, die diese Rollen im Auftrag ihrer Endnutzer einnehmen. Angenommen, Plattform A und Plattform B unterstützen das HubSubHubbub-Protokoll und kennen den gleichen Hub-Server. Veröffentlicht nun ein Benutzer auf der Publisher-Plattform einen Beitrag, sendet diese eine entsprechende Information an den Hub-Server. Der Hub-Server wiederum sendet die Information umgehend an die Subscriber-Plattform weiter. Die Subscriber-Plattform wird also informiert, wenn auf der Publisher-Plattform neue Inhalte vorliegen, und kann diese nun direkt auf dem üblichen Weg (z.B. Auslesen des betroffenen Feeds auf der Publisher-Plattform) beziehen. Meistens sind die beteiligten Plattformen zugleich Publisher und Subscriber. Bei jedem Einzelvorgang sind sie jedoch entweder in der Publisher-Rolle oder in der Subscriber-Rolle.

Der Endeffekt besteht darin, dass abonnierte Inhalte wie etwa Feeds quasi in Echtzeit aktualisiert werden, sobald sie sich ändern. Wenn also Benutzer 1 auf Plattform A eine Statusmeldung postet und in seiner Präsenz auf Plattform B von der Möglichkeit Gebrauch macht, seinen Neuigkeiten-Feed von Plattform A einzuspeisen, so erscheinen seine Statusmeldungen von Plattform A quasi in Echtzeit auch auf Plattform B.

Immer mehr Plattformen bieten an, Benutzer-Feeds aus anderen Plattformen einzubinden. Ob das nun mit dem Hintergedanken geschieht, Benutzern den Umstieg von der anderen Plattform zur eigenen Plattform zu erleichtern, oder aus dem Open-Network-Gedanken heraus, dass Benutzer, egal auf welcher Plattform sie gerade aktiv sind, nichts von dem verpassen, was ihre Netzkontakte auf anderen Plattformen gerade posten, sei mal dahingestellt. Der Trend, alles überall zur Verfügung zu haben, ist auf jedenfall feststellbar, und durch das PubSubHubbub-Protokoll wird dieser Trend sicherlich verstärkt. Nicht zuletzt auch deswegen, weil PubSubHubbub durchaus schon namhafte Implementierungen vorzuweisen hat. Vor allem Google, so weiß Golem, nutzt PubSubHubbub mittlerweile in verschiedenen Services, etwa in seinem RSS-Dienst FeedBurner, im Google Reader, in der Blogplattform Blogger, in Google Alerts und natürlich auch in Google Buzz. Wegen letzterem ist das PubSubHubbub-Protokoll auch erst so richtig ins Gerede gekommen, da Buzz intern voll auf dieses Protokoll setzt, um Inhalte zu aktualisieren.

PubSubHubbub fördert also das automatisierte, zeitnahe Publizieren auf mehreren Kanälen. Damit nährt es die Hoffnung, dass es irgendwann egal sein könnte, auf welcher Plattform man sein Networking-Zuhause hat. Durch Echtzeit-Feed-Präsenz ist man in anderen Plattformen ja gleichzeitig präsent.

Ob diese Rechnung jedoch aufgeht, darf bezweifelt werden. Eine Präsenz auf einer Networking- oder Microblogging-Plattform, die sich nur auf Echtzeit-Feeds stützt, läuft leicht Gefahr, die „biotop-gerechte Kommunikation“ innerhalb der einzelnen Microblogging- und Networking-Plattformen zu ignorieren. So gibt es beispielsweise innerhalb von Google Buzz bereits Initiativen, die sich gegen den den Import von Twitter-Meldungen wenden, weil Buzz eher auf größere Diskussionen ausgelegt ist und viele, kurze Tweets mit reinem Radarmeldecharakter in diesem Zusammenhang nur stören. Auch eine Facebook-Präsenz, die vorwiegend aus importierten Twitter-Meldungen besteht, ist eigentlich fehl am Platz. Denn Facebook bietet mehr und andere Formen von Statusmeldungen, wie etwa Foto-Sharing, Fan-Bekundungen, Apps-Meldungen usw., also ganz andere Formen des persönlichen Outings. Die Charakteristika der einzelnen Plattformen unterscheiden sich teilweise so sehr, dass es praktisch wenig sinnvoll ist und sogar schädlich fürs Image sein kann, in einer davon primär aktiv zu sein und die Präsenz in den anderen davon automatisiert abzuleiten.

Also doch weniger Kanäle? Vielleicht nur einen einzigen, und den dafür richtig? Nicht unbedingt. Eine mögliche Lösung besteht sogar darin, noch einen weiteren einen Publikationsort im Netz zu eröffnen. Nämlich einen, den man ausschließlich für Statusmeldungen nutzt, die man in allen Plattformen, in denen man präsent ist, veröffentlichen will. Alle anderen Statusmeldungen veröffentlicht man dagegen nur und direkt in den Plattformen selber, im dort passenden Rahmen.

Ein geeignetes Tool dafür ist beispielsweise ein Blog bei Posterous. Das ist umgehend eingerichtet, benötigt keine aufwändige Layout-Einrichtung, und kann sogar mittels einfacher E-Mails mit Inhalten versorgt werden. Posterous generiert aus Beiträgen automatisch ein ordentliches, einfaches Blog, inklusive Feed, und — im hier behandelten Zusammenhang ganz wichtig — inklusive Unterstützung des PubSubHubbub-Protokolls, was aus dem Feed einen Echtzeit-Feed macht. In das Posterous-Blog postet man ausschließlich Meldungen, die man auf allen übrigen Plattformen veröffentlichen möchte, also etwa auf Twitter, Facebook und Buzz. Zu berücksichtigen sind dabei natürlich Beschränkungen wie die 140-Zeichen-Grenze in Twitter. Den Posterous-Feed speist man in anderen Plattformen als Nachrichtenquelle ein, z.B. in Facebook (mittels einer Feed-App) oder in Buzz. Posterous kann auch automatisch Twitter-Posts aus Blog-Einträgen generieren.

Es gibt wohl noch weitere, interessante Lösungen. Das Problem, wie man auf immer mehr Plattformen gleichzeitig präsent sein kann, und das nicht nur als „Echtzeit-Geist“, wie viel Zeit man dafür zu investieren bereit ist, und wie wichtig es tatsächlich ist, überall präsent zu sein — all das muss letztlich jeder Web-Aktive für sich selbst entscheiden. Auch und erst recht, wenn seine Präsenzen kommerziell motiviert sind.

button-compact-static-100x17.png

Kommentare

Neuen Kommentar hinzufügen
oder Anmelden als Wikidot User
(wird nicht veröffentlicht)
- +
Sofern nicht anders angegeben, steht der Inhalt dieser Seite unter Lizenz Creative Commons Attribution-ShareAlike 3.0 License