Facebook kauft WhatsApp und ich hab nur wenig Möglichkeiten meine Konsequenzen daraus zu ziehen. Leider sind alle aktuell populären "Chat" Systeme direkt an die App gekoppelt und ich "muss" zwangsläufig die App benutzen die mein Freundeskreis bevorzugt.

WhatsApp benutzt intern das XMPP-Protokoll und arbeitet dadurch ja theoretisch dezentral und auch Telegram hat beispielsweise eine Art offenes Protokoll gebaut… Das Problem: Woher wissen auf welchem Server der Andere angemeldet ist.

Seit WhatsApp die Identifizierung über die Telefonnummer (statt einer z.B. E-Mail Adresse) eingeführt hat, sind viele anderen diesem Beispiel gefolgt und es gibt nichts Verwerfliches daran. Jeder der eine solche App nutzt hat zwangsläufig ein Telefon, was bedeutet dass er auch eine Telefonnummer hat und die Wahrscheinlichkeit dass in seinem (Telefon-)Adressbuch mehr Telefonnummern als E-Mail Adressen stehen ist auch sehr hoch. Prinzipiell also eine gute Idee! Leider kann man aber anhand einer Telefonnummer nicht auf einen Server (mal abgesehen vom Telekommunikations-unternehmen) schließen und das bedeutet, dass das Verfahren leider auch nur zentral funktionieren kann. Nutze ich WhatsApp, kann man mich nur über die WhatsApp-Server erreichen, für Telegram läuft die Kommunikation nur über die Telegram-Server usw.

Um mit XMPP oder anderen Protokollen wirklich dezentral arbeiten zu können, müsste man über die Telefonnummer erfahren können welchen Chat-Server der Andere benutzt. Vielleicht über so eine Art Tel to Id – Service oder über andere Protokolle wie z.B. SMS. Damit könnte sich jeder selbst den Client seines Vertrauens aussuchen und alles wäre gut besser 😉

Ausgabe 20 vom SCREENGUIDE Magazin ist draußen und das bedeutet, dass auch meine Kolumne "20" wird!

(Naja… In Ausgabe 1 war es streng genommen "nur" ein Artikel über Microformats (Semantic Surfing), aber thematisch ist da ja kein großer Unterschied 😉 )

In der aktuellen Kolumne geht es jedenfalls um HTML5 und DRM:

Mit der Entwicklung eines Digital-Rights-Management-Systems für HTML5 hat das W3C in den letzten Wochen für viel Aufmerksamkeit gesorgt. Warum arbeitet gerade die Organisation, die sich „Open Standards“ und „Web for All“ zu Grundsätzen gemacht hat, an einem System, um genau diese einzuschränken?

Viel Spaß beim lesen und auf die nächsten 20 Ausgaben 🙂

App.net hat endlich alles nachgereicht was Dalton Caldwell vor fast genau einem Jahr versprochen hat. Die Liste kann sich echt sehen lassen:

Mal schauen was sich damit alles basteln lässt, immerhin hab ich im SCREENGUIDE-Magazin (Ausgabe 18) noch groß getönt:

Mit ein paar wenigen Änderungen und dem Support von z. B. Microformats, RSS/Pubsubhubbub, AtomPub oder Pingbacks, wäre App.net kompatibel zu fast allen Blogs oder IndieWeb-Systemen. Das hätte zum Vorteil, dass sich App.net ohne weitere Anpassungen über RSS-Reader konsumieren und über Blogging-Tools befüllen ließe. Außerdem könnten Posts und Kommentare zwischen App.net und z.B. WordPress ausgetauscht werden, ohne auf komplizierte, dezentrale Protokolle im Sinne von Diaspora oder Tent.io zurückgreifen zu müssen.

😉

via Carsten Pötter

Gmail unterstützt seit ein paar Tagen auch Embedded JSON-LD… So ne Art „JSON Version von RDF“ für HTML-Dokumente:

<script type="application/ld+json">
{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

Embedded JSON? Wirklich? Und warum? Weil’s geht?

Neben Microformats, Microdata, RDFa, eRDF, OpenGraph Protocol und Twitter Cards jetzt also auch noch JSON? Super Idee!

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>

…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"

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>

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" />

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!