pubsubhubbub-logo

Seit ein paar Wochen scheint die Version 0.4 von PubSubHubbub relativ stabil zu sein… immerhin so stabil, dass Google und Superfeedr ihre Hubs an die neue Spec angepasst haben.

Die wesentlichen Unterschiede zu der Vorgängerversion sind:

  • Alle Datentypen werden unterstützt: Neben RSS/Atom können jetzt auch vCards, beliebige XML oder JSON Datein oder auch Bilder ge-push-t werden
  • Statt HTML/Atom-Links werden HTTP-Link-Header benutzt
  • Der Pubslisher-Prozess ist nicht mehr über die Spezifikation definiert

Für die zwei großen Hubs sollte es reichen wenn ihr eure Feed-<link />s („hub“ und „self“):

<?xml version="1.0"?> <atom:feed> <link rel="hub" href="http://myhub.example.com/endpoint" /> <link rel="self" href="http://publisher.example.com/happycats.xml" /> </atom:feed>
Code-Sprache: HTML, XML (xml)

…zusätzlich über die HTTP-Header ausliefert:

HTTP/1.1 200 OK Date: Tue, 03 Apr 2012 08:02:19 GMT Content-Type: text/html Content-Length: 11261 Link: <http://http://myhub.example.com/endpoint>; rel="hub" Link: <http://publisher.example.com/happycats.xml>; rel="self"
Code-Sprache: HTTP (http)

Leider ist die Version 0.4 aber nicht 100% abwärts-kompatibel… Die wahrscheinlich größte (und für mich enttäuschendste) Änderung ist das bewusste Weglassen des Publisher-Prozesses:

The publisher MUST inform the hubs it previously designated when a topic has been updated. The hub and the publisher can agree on any mechanism, as long as the hub is eventually able send the updated payload to the subscribers.

Auf der einen Seite kann das ein enormer Vorteil für Publisher sein, da Hubs in Zukunft auch per E-Mail, SMS, Pingbacks/Trackbacks oder XMPP über Updates informieren werden könnten. Auf der anderen Seite ist es aber auch sehr Wahrscheinlich, dass man für jedes v0.4 Hub eine individuelle Implementierung benötigt. Bisher unterstützen beide großen Hubs (Google und Superfeedr) aber weiterhin das alte Verfahren, also kein Grund sich jetzt schon Sorgen zu machen…

Alles in allem finde ich die Änderungen aber ganz nett und hoffe dass „Polling“ bald der Vergangenheit angehört…

Pingbacks (und Trackbacks) werden zwar immer noch von allen WordPress Blogs unterstützt aber mal ehrlich… wen interessieren sie denn noch wirklich? Das hängt hauptsächlich mit der etwas veralteten Spezifikation zusammen, in der folgendes vorgeschlagen wird:

Bob’s blog also retrieves other data required from the content of Alice’s new post, such as the page title, an extract of the page content surrounding the link to Bob’s post, any attributes indicating which language the page is in, and so forth.

Das führt bei WordPress zu Einträgen die ungefähr so aussehen:

[…] und Wertvorstellungen entspricht und nicht von der Mehrheit meiner Freunde abhängig sein.» Dezentrale Walled Gardens Hier erscheinen von Montag bis Freitag ausgewählte Links zu lesenswerten Texten und aktuellen […]

Der automatische generierte Ausschnitt lässt nicht wirklich erahnen was Markus Spath wirklich geschrieben hat und deshalb verüble ich es niemandem, wenn er die Pingbacks/Trackbacks auf seiner Seite auf eine simple Liste von Links beschränkt hat. Als die Spezifikation 2002 geschrieben wurde, war das mit dem „Ausschnitt um den Link“ sicherlich eine gute Lösung. Es gab keine andere Möglichkeit automatisch zu erkennen welcher Text genau zu dem Link gehört oder wann ein neuer Artikel, die Navigation oder sogar Werbung beginnt. Mittlerweile lassen sich Inhalte dank Websemantiken wie Microformats, RDFa oder Microdata sehr gut erkennen. Aber auch mit purem HTML5 Markup lässt sich problemlos ein <article /> und dessen Überschrift erkennen.

Pingbacks sind aktuell die einfachste und wahrscheinlich sogar die einzige Möglichkeit, Kommentare dezentral und vor allem Plattform unabhängig zu „verschicken“, deshalb verstehe ich nicht wieso es so lange gedauert hat, bis jemand (im Rahmen eines IndieWebCamps) auf die Idee kam sie den aktuellen Bedürfnissen und Möglichkeiten anzupassen anstatt sich weiter den Kopf über komplizierte dezentrale Protokolle zu zermartern. Wer sich das Salmon Protocol schon einmal angeschaut hat, weiß was ich meine…

Pingbacks haben diverse Vorzüge:

  • Sie sind leicht zu implementieren (einfacher XML-RPC Request an jedem, im Text erwähnte URL)
  • Sie bieten einen simplen Schutz (wenn auch keinen 100%igen) gegen Spam, da der Pingende zumindest für eine gewisse Zeit auf die ge-pingte Seite verlinken muss
  • DRY… Die Webseite dient als API und man muss seine Texte nicht zusätzlich in diversen XML oder JSON Formaten anbieten

Auf der IndieWebCamp Seite gibt es eine Reihe an interessanten Diskussionen wie sich mit Hilfe von Microformats und ein paar rel-Attributen auch „Likes“ oder „RSVPs“ über Pingbacks realisieren ließen.

Ein Like könnte beispielsweise folgendermaßen aussehen:

<div class="h-entry"><span class="p-autor h-card">Matthias Pfefferle</span> likes <a rel="object-of-like" href="http://hackr.de">hackr.de</a></div>
Code-Sprache: HTML, XML (xml)

Sandeep Shetty hat das auf sandeep.io sehr schön erklärt und implementiert!

Ben Werdmuller hat außerdem nochmal alles (Comments/Likes/RSVPs) als Video zusammengefasst:

Im nächsten Blogpost geht es dann um Webmentions, einer etwas moderneren Variante von Pingbacks.

indiewebcamp-logo

IndieWeb? Schon wieder so ein hippes Buzzword-Dingens wie DataPortability, Synaptic oder Federated Social Web? Naja, irgendwie schon aber irgendwie auch nicht… 😉

Seit dem ich das Internet für mich entdeckt habe hatte ich meine eigene Webseite… Von den ersten Frontpage (das hätte ich vielleicht besser verschweigen sollen) Versuchen auf Geocities mit Kostenlos-Domain-Weiterleitung (wer kennt noch kickme.to?), zum eigenen Webspace und Homesite, zu ersten PHP Erfahrungen und phpNuke, zu diversen Webseiten und Blogs und letztendlich auch zu meinem Beruf. Darum tue ich mich besonders schwer, Inhalte auf Facebook und Co. zu teilen/schreiben, wenn ich sie doch auch auf meiner eigenen Seite veröffentlichen könnte. Außerdem scheint sich meine Generation (oder vielleicht auch nur mein Freundeskreis) nicht sonderlich für Social Networks zu interessieren und man trifft sich lieber oder telefoniert.

Damit stecke ich natürlich in einer Zwickmühle… Einerseits interessiert mich Facebook nicht sonderlich, andererseits bringen Social Networks aber eine Menge Reichweite… und so ist mein Faible für DataPortability, DiSo oder dem Federated Social Web entstanden… Ich will weiterhin der Herr meiner Ideen und Texte bleiben aber schätze die Reichweite und die höhere Dialogbereitschaft von Twitter und Co. sehr.

Bisher hatten alle Bewegungen aber ein großes Problem: Sie hätten nur funktioniert wenn Google, Twitter und Facebook sich angeschlossen und ne Menge hippe „Standards“ eingebaut hätten. Das ist wohl auch der Grund weshalb man von vielen Projekten schon lange nichts mehr gehört hat. Das IndieWeb Credo spricht mir dagegen aus der Seele:

We should all own the content we’re creating, rather than just posting to third-party content silos.
Publish on your own domain, and syndicate out to silos.

Das IndieWebCamp findet in unregelmäßigen abständen statt und beschäftigt sich ausschließlich damit, wie man der Herr seiner Artikel/Tweets bleibt. Im Gegensatz zu DiSo baut die IndieWeb Idee aber nicht auf einem zentralen Framework, CMS oder Blogsystem auf, sondern motiviert jeden selbst aktiv zu werden. Im Vordergrund stehen recht allgemein gehaltene Konzepte und der Slogan eat your own dogfood… Programmiere für deine eigene Bedürfnisse und veröffentliche deinen Code, dass auch andere davon profitieren können. Ein paar Konzepte:

  • POSSE (Publish (on your) Own Site, Syndicate Elsewhere): Veröffentliche alles auf deiner eigenen Seite und verteile es dann über die verschiedenen Kanäle.
  • Comments: Veröffentliche auch Kommentare auf deiner Webseite und setze den Autor über Pingbacks oder Webmentions darüber in Kenntnis.
  • Login: Mit einer Kombination aus rel-me und OAuth (IndieAuth oder RelMeAuth) lassen sich ironischerweise fast mehr Dienste ansprechen als mit OpenID.
  • Web Actions: Ein ähnlicher (wenn auch pragmatischerer) Ansatz wie Web Intents. Share/Like-Buttons sollen sich dem Verhalten des Nutzers anpassen und ihm die Möglichkeiten anbieten die er benötigt, sei es das Teilen über Facebook oder eben über die eigene Seite.

(weitere „Building Blocks“ findet ihr im Wiki)

Ich mag die Idee schon alleine deshalb, weil sie aktuell Funktioniert und nicht von der Fertigstellung oder Einführung von diversen Protokollen abhängig ist (naja fast). So ne Art „Dezentrales Netzwerk für Arme“ 😉

Ich selbst versuche seit ein paar Wochen das NotizBlog IndieWeb tauglich zu machen und habe dazu auch ein paar Plugins auf Github veröffentlicht. Demnächst kommt aber sicherlich noch eine kleiner Anleitung in Form von einem Blogpost dazu.

Vielleicht hat ja jetzt der ein oder andere Blut geleckt und greift mir bei meinem WordPress Projekt ein wenig unter die Arme 😉

Macht euch unabhängig!

(Im Screenguide Magazin Ausgabe 17 gibt es übrigens noch eine etwas ausführlichere Beschreibung der einzelnen IndieWeb Building Blocks)

Garfield minus Garfield comic
Image from Garfield minus Garfield

Ich war nie ein großer Fan der Twitter Cards, was aber nicht wirklich schlimm ist, da Twitter das Open Graph Protocol als vollwertiges Fallback unterstützt… unterstützt hat…

Seit ein paar Wochen scheint den feinen Herren das Open Graph Protocol aber nicht mehr auszureichen und meinen Links fehlt der schöne, kleine Teaser 🙁

Zum Glück reicht aber ein Meta-Tag um das ganze wieder zum laufen zu bekommen. Twitter unterstützt verschiedene Arten von Previews, welche über <meta name="twitter:card" content="summary" /> festgelegt werden. Neben summary (für Texte) gibt es auch noch photo für Bilder und player für Audio/Video (die komplette Liste findet ihr hier). Ich würde euch außerdem noch den twitter:creator empfehlen, mit dem ihr auf den Twitter-Account des Autors hinweisen könnt. Für meinen Blog sieht das wie folgt aus:

<meta name="twitter:creator" content="@pfefferle" /> <meta name="twitter:card" content="summary" />
Code-Sprache: HTML, XML (xml)

Wenn ihr sicher gehen wollt ob ihr alles richtig gemacht habt, könnt ihr eure Seite mit dem Twitter Card Validator testen.

Den WordPresslern unter euch kann ich außerdem folgende Plugins empfehlen:

  • Open Graph – Keine Settings, kein Know-How, alles vollkommen Idiotensicher.
  • twitter:creator – Setzt zusätzlich die angesprochenen twitter:creator und twitter:card.

…also viel Spaß beim Twitter Cards Boykott ;).

Seit heute ist SemPress ein offizielles WordPress.com Theme 🙂

SemPress auf WordPress.com

Eigentlich wollte ich ja nur ein wenig „rumprobieren“ und das Toolbox-Theme an die neuen WordPress Funktionalitäten anpassen aber mittlerweile haben schon knapp 8000 Leute SemPress heruntergeladen, ich habe Übersetzungen für Russisch und Deutsch bekommen und mein Theme ist auf WordPress.com… GROSSARTIG 🙂

Also:

Meet SemPress, an extremely lightweight, responsive theme designed to show off your posts, quotes, and images. SemPress supports multiple post formats, widgets, and the option to upload a custom header image.

So kann es weiter gehen 🙂

Viel Spaß beim ausprobieren und falls ihr Verbesserungsvorschläge habt… immer her damit!

Feed Icon

…ich hab's ja bisher immer verbummelt oder verpasst:

Aber jetzt, wo Google seinen Reader dicht macht, kann ich's endlich auch mal schreiben: RSS ist tot!

Pfefferles Open Web

Übrigens… Mein Artikel im aktuellen SCREENGUIDE Magazin war ausschlaggebend für den Blog-Post zu Dezentrale “Walled Gardens”, geht aber noch mehr ins Detail:

[…] Spezifikationen haben wir mittlerweile genug! Es ist an der Zeit, die sozialen Netzwerke von der Idee eines dezentralen Webs zu überzeugen, und mit sozialen Netzwerken meine ich Facebook, Google+ oder StudiVZ. Netzwerke mit einer bestehenden Userbase und keine, die künstlich geschaffen wurden, um zu beweisen, dass „dezentrale“ Kommunikation funktioniert. […]

…also ab zum Kiosk und kaufen!

We love icon fonts

Tim Pietrusky hat so ne Art "Google Web Fonts" für Icon-Fonts gebastelt, was alleine natürlich schon einen Blog-Post wert wäre… er hat aber außerdem noch die OpenWeb-Icons eingebaut, was definitiv einen Blog-Post wert ist 😉

Dank Tims "We Love Icon Fonts" lassen sich die Fonts mit folgenden paar Zeilen CSS-Code einbauen:

@import url(http://weloveiconfonts.com/api/?family=openwebicons); /* openwebicons */ [class*="openwebicons-"]:before { font-family: 'OpenWeb Icons', sans-serif; }
Code-Sprache: CSS (css)

Das Projekt ist übrigens Open Source und Tim würde sich sicherlich über jede Hilfe freuen!

Diaspora Logo

Diaspora* wurde kaum für „tot“ erklärt und schon steht das nächste Projekt in den Startlöchern! Tent.io soll ein protocol for distributed social networking and personal data storage werden. Alles neu, alles anders, alles besser als OStatus, DiSo oder Diaspora*. Aber mal ganz ehrlich… was haben die Diasporas & Co. bisher geschaffen? Ziel war es Facebooks „Walled Gardens“ aufzubrechen und was kam wirklich dabei rum? Eine ganze Reihe an dezentralen „Walled Gardens“. Na danke!

Seit Chris Messinas DiSO-Projekt schwärme ich ein wenig für das Thema „Dezentrale Netze“ und wie man die Idee am besten technisch umsetzen könnte. Trotz der „Schwärmerei“ ist mir aber durchaus bewusst dass das Thema noch nicht wirklich populär ist und kein wirkliches User-Bedürfnis deckt. Das hängt aber unter anderem damit zusammen, dass bisherige Bemühungen (und Diaspora ist ein Vorzeigebeispiel hierfür) rein technischer Natur sind! Aber:

  • „Open“ und „Dezentral“ sind keine Argumente um sich bei einer neuen Plattform anzumelden (zumindest nicht für die breite Masse).
  • Es ist idiotisch wenn jede Community ihr eigenes „Dezentralisierungsprotokoll“ entwickelt… das führt nämlich dazu, dass Diaspora und StatusNET zwar beide dezentral sind, aber nur die eigenen Netzwerke unterstützen.
  • Jedes neue Protokoll (mal abgesehen von OStatus) erfindet das Rad neu anstatt auf bisherigen Formaten aufzubauen. Warum muss alles JSON sein? RSS und Atom kann jedes Blog und mit ein bisschen „Zauberei“ reicht das vielleicht schon aus.
  • „Open Source“ und die Möglichkeiten das Projekt selber zu hosten überzeugt nur Geeks!

Wenn die großen Netzwerke wie Facebook, Twitter und Google+ sich nicht auf ein einheitliches Protokoll einigen, wird es wohl nichts mit der „dezentralen“ Idee! Ich möchte mich in Zukunft für eine Community entscheiden die meinen Interessen und Wertvorstellungen entspricht und nicht von der Mehrheit meiner Freunde abhängig sein. Wenn alle meine Freunde aber bei Facebook sind, bleib ich auch auf einem offenen und dezentralen Diaspora alleine!

Wir brauchen eine Art XMPP oder POP3/SMTP für soziale Interaktionen, unabhängig von einer spezifischen Plattform und trotzdem von allen unterstützt! Und dann haben auch kleine und unabhängige Projekte wie Diaspora und StatusNET wieder eine echte Chance! Die Zeit die bisher in Spezifikationen aller Art fließt sollte dazu genutzt werden, zuerst einmal Facebook und Google von dem Problem zu überzeugen und sie mit ins Boot zu holen.

…das ist übrigens das Thema meiner Kolumne im nächsten Screengui-Magazin. Also kaufen!

Ich habe in den letzten Monaten eine Menge über Web Intents gelesen und ich finde immer noch dass der Webmonkey die Thematik bisher am treffendsten beschrieben hat:

In practice Web Intents work a bit like mailto: links, defining an action and then passing it along to the browser, which allows the user to choose how to handle the action. The difference is that instead of opening a desktop app, Web Intents connect to web services.

Der Vergleich ist simple und ich habe mir die Frage gestellt: Wieso nicht einfach wirklich unterschiedliche Schemes für die jeweiligen Anforderungen definieren? Eine App kann beim Browser anmelden dass sie share:// oder subscribe:// unterstützt und bei einem Klick auf einen entsprechenden Link, öffnet sich (statt der E-Mail App) eben die entsprechende Web-App.

…vor kurzem hab ich dann mal ein wenig mit Superfeedrs msgboy herumgespielt und entdeckt dass es bei HTML5 wirklich Custom-Schemes gibt die man frei definieren kann!

Mit folgendem Befehl kann man beim Browser einen eigenen Protocol-Handler setzen:

navigator.registerProtocolHandler('web+share', 'http://spread.ly/?url=%s', 'Spread.ly');
Code-Sprache: JavaScript (javascript)

Alle neuen Schemes sollten mit "web+" beginnen, ausnahmen sind schon bestehende Schemes, wie z.B. "mailto", "mms", "nntp", "rtsp" oder "webcal".

Der passende a-Tag zum oben genannten Beispiel müsste also folgendermaßen aussehen:

<a href="web+share:http://pfefferle.org">Share this Page</a>
Code-Sprache: HTML, XML (xml)

Klickt ein User den Link, wird einfach das %s vom Handler mit dem href ersetzt und aufgerufen:

http://spread.ly/?url=web+share:http://pfefferle.org
Code-Sprache: JavaScript (javascript)

Bisher war ich ja ein großer Web Intents Fan (und bin es auch immer noch), aber für solche simplen Aktionen wie "Share", "Like", "Subscribe" oder "Follow" reicht doch ein simples Custom-Scheme vollkommen aus. Kein unnötiges JavaScript (mal abgesehen vom Registrieren des Handlers), nur ein wenig HTML. Großartig!

Protocol-Handler lassen sich übrigens auch abhängig vom Mime-Type setzen:

navigator.registerContentHandler('application/atom+xml', 'http://www.google.com/ig/add?feedurl=%s', 'Google Reader')
Code-Sprache: JavaScript (javascript)

Bei allen Web-Dokumenten mit dem Mime-Type application/atom+xml sollte der Browser jetzt nachfragen ob er die URL mit dem Google-Reader öffnen soll.