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!

Anfang der Woche hat Martin Weigert schon über Twitters Pläne, die eigenen Tweets mit noch mehr Medieninhalten zu erweitern, geschrieben:

Immer mehr Partnerseiten können zusätzliche multimediale Inhalte im Kontext von Tweets darstellen. Ganz eindeutig ist bisher nicht, wohin diese Reise für Twitter geht.

Aber ich habe mir nichts weiter dabei gedacht… Immerhin macht das Twitter ja schon seit einer ganzen Weile und ich meine mich zu erinnern, irgendwo gelesen zu haben, dass sie dazu oEmbed einsetzen… Also alles in bester “OpenWeb”-Ordnung :)

Aber, Geek der ich bin, hab ich mir gestern zufällig einen Quelltext angeschaut in dem ich auf folgendes entdeckt habe:

<meta name="twitter:card" value="summary">
<meta name="twitter:url" value="...">
<meta name="twitter:title" value="...">

…und nach kurzem googlen bin ich auf die Twitter Cards gestoßen, Twitters eigenes, kleines Open Graph Protocol. Mit den Twitter Cards bekommen Seitenbetreiber ein Set an Meta-Tags an die Hand, und Twitter kann diese Informationen nutzen um die tweets mit den oben erwähnten Mediendaten anzureichern.

Example Twitter Card

…und ich wollte mich gerade darüber aufregen, warum Twitter dazu eine eigene Meta-Sprache erfindet, da bin ich in der Doku ironischerweise auf folgendes gestoßen:

You’ll notice that Twitter card tags look similar to OpenGraph tags, and that’s because they are based on the same conventions as the Open Graph protocol. If you’re already using OpenGraph to describe data on your page, it’s easy to generate a Twitter card without duplicating your tags and data. When the Twitter card processor looks for tags on your page, it first checks for the Twitter property, and if not present, falls back to the supported Open Graph property. This allows for both to be defined on the page independently, and minimizes the amount of duplicate markup required to describe your content and experience.

“Ok”, dachte ich… vielleicht reichen die Open Graph Properties ja nicht aus um alle Informationen, die Twitter braucht, abzubilden. Also hab ich mir mal die Mühe gemacht sie zu vergleichen:

Twitter Cards Open Graph Protocol
twitter:card og:type
twitter:site og:site_name
twitter:url og:url
twitter:description og:description
twitter:title og:title
twitter:image og:image
twitter:image:width og:image:width
twitter:image:height og:image:height
twitter:player oder twitter:player:stream og:video oder og:audio
twitter:player:width og:video:width
twitter:player:height og:video:height

Es lässt sich also prinzipiell alles mit dem Open Graph Protocol abbilden, es fehlen lediglich die Felder twitter:site:id und twitter:creator:id. Aber wegen diesen zwei Feldern muss man doch nicht das ganze Format “kopieren”. Es reicht doch ein kleiner Absatz, wie man den Open Graph mit den proprietären Werten erweitert… So wie das auch Facebook praktiziert:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:og="http://ogp.me/ns#"
      xmlns:fb="https://www.facebook.com/2008/fbml">
      xmlns:twitter="https://dev.twitter.com/docs/cards">
  <head>
    <title>The Rock (1996)</title>
    <meta property="og:title" content="The Rock"/>
    <meta property="fb:admins" content="USER_ID"/>
    <meta property="twitter:site:id" content="@USER_ID"/>
    ...
  </head>
  ...
</html>

Hoffentlich überlegt sich das Twitter noch einmal… Wenn nicht, wird dank dieser (und folgender) Redundanzen der <head /> einer Webseite in ein paar Jahren mehr Informationen beinhalten wie der <body />.

…welch ein Over-<head> :)

Neben all den negativen Meldungen endlich mal wieder ein Highlight für OpenID: Seit dieser Woche ist PayPal offizieller OpenID-Provider mit allen Schikanen (OpenID 2.0, OpenID Simple Registration, OpenID attribute exchange, OpenID user interface, PAPE specification).

Die Meldung ist nicht nur erfreulich, sondern vielleicht auch die Rettung des etwas angeschlagenen offenen Standards. Trotz des eher hinkenden Vergleichs, wurde OpenID immer mit dem Erfolg von Facebook Connect gemessen. Die OIDF hat es durchweg versäumt den Standard als reines “Werkzeug” sehen und die Produkte basierend auf OpenID zu promoten. Wie ich schon im Webstandards-Magazin (Ausgabe 9: Pfefferles OpenWeb) schrieb:

Facebook Connect ist nicht wegen seinem proprietären System so erfolgreich und der Misserfolg von MySpaceID hat nichts mit den benutzten offenen Standards zu tun. Promote the utility not the technologie. To reach the majority of users who aren’t familiar with OpenID as a technology, promote the ability to log in using an existing account, not “OpenID” itself. Ich würde sagen das Problem liegt nicht am Protokoll sondern an den fehlenden sinnvollen Anwendungsfällen. OpenID funktioniert überall da, wo der User einen Nutzen hat ohne zu wissen was unter der Oberfläche passiert, beispielsweise „Sign in with Google“ oder „Sign in with Yahoo!“. Wo bleiben also die Killerapplikationen wie z.B. Paypals angekündigtes Express Checkout auf Basis von OpenID?

Reines Single-Sign-On ist ein Geek-Thema und scheint wohl kein generelles Bedürfnis zu befriedigen. Ein “Mit einem Klick-Bezahlen” ist dagegen eine enorme Chance für Einkäufer und kleine Verkäufer. Wo man bisher, oft durch die langwierige Anmeldung und das hinterlegen der Kontodaten, trotz günstigerer Angebote doch wieder bei Amazon bestellt hat, bietet PayPal in Zukunft vielleicht die Lösung: Schnelles, unkompliziertes und sicheres Einkaufen mit einem “Klick”.

Hoch lebe OpenID :)

Eran Hammer-Lahav hat einen sehr schönen Artikel über das “verschwendete” Potential der Facebook-Entwickler veröffentlicht:

[...] In fact, the problem is just how unbelievable the Facebook team is (in a good way). The sheer strength of their talent is almost unmatched in our industry, past and present. The problem is, all that talent is building something I just don’t care about, and no one is left for anything else.
[...] There are many reasons why engineers want to work for Facebook, from the potential windfall to learning just how they are able to ship so much technology so fast. It is an engineering dreamland. But there is one great reason why they shouldn’t: because Facebook will be great without them, but the web might not.

Irgendwie spricht er mir damit aus der Seele! Technologisch gesehen ist Facebook ein Traum (Open Graph Protocol, OAuth 2, Microformats, OpenID (schon bald auch OpenID Connect), uvm.), mit dem Social Network kann ich aber leider nur wenig anfangen…

How to implement OStatus?

Evan Prodromou (der Gründer von StatusNet) hat eine Schritt-für-Schritt-Anleitung veröffentlicht, wie man die eigene Seite verOStatust!

Making your application a full-fledged participant in the federated social web is not easy, but gradual and incremental improvements can make your users’ activities visible to others.

» How to OStatus-enable Your Application

Is your Site OStatus-Ready?

…und jede neue Implementierung will auch überprüft werden!

» Are you ready for Ostatus .. or not ?

pubsubhubbub + json

Facebooks Real-time-API ist eine Art Mischung aus pubsubhubbub+json+OAuth2.

» pubsubhubbub
» Real-time Updates

Das (OpenWeb-) Thema, welches die letzten Tage die meisten Netizens beschäftigt hat war wohl die Veröffentlichung des Diaspora-Codes. Irgendwie kam das Tool dabei nicht ganz so gut weg. Hier ein paar Meinungen aus deutschen Quellen:

Lange hat es nicht gedauert, bis die ersten sicherheitsrelevanten Lücken aufgedeckt wurden. Wie The Register meldet, haben Experten bereits Möglichkeiten entdeckt fremde Accounts zu übernehmen, ohne Erlaubnis neue Kontakte aufzubauen oder Fotos zu löschen.

Entwickler haben sich den Code bereits genauer angesehen und sind enttäuscht: Diaspora ist eine einfache Rails App, mit der man Fotos hochladen kann“, zitiert Mashable den Entwickler J. Chris Anderson. Daraus könne man schließen, dass die Codebasis keinesfalls ausreicht, um daraus in den nächsten Monaten einen echten Konkurrenten für Facebook zu machen.

» t3nWelche Chancen hat die dezentrale Facebook-Alternative?

Nun wurde Diaspora mit Ruby on Rails geschrieben zusätzlich braucht es eine Mongo Database – zwei dinge die jetzt nicht jeder installiert hat – oder ums spezifizieren – so gut wie niemand installiert hat. Das sind schonmal zwei Hürden die so gleich vorneweg mal 80% aller Hostingoptionen ausschliessen. Man braucht dafür dann schon ein Hostingprovider der einen Kram installieren lässt was bei den meisten Shared Massen Hostern(tm) nicht funktioniert – oder man hat nen eigenen Server irgendwo stehen.

» Blog RebellenDiaspora – Ein erster Eindruck

Die eigenen Server stehen übrigens auch einer großen Verbreitung von Diaspora entgegen. Denn wie viele an Social Networking interessierte Nutzer gibt es, die einen eigenen Server betreiben? Selbst wenn es Hoster in der Art von WordPress.com geben sollte, dürfte die Nutzerzahl begrenzt bleiben.

Nur mal so: Jeder kann einen Mail Server betreiben, jeder kann OpenID Provider werden. Frage: Wie viele Leute betreiben einen eigenen Mail Server und wie viele Leute sind ihr eigener OpenID Provider? Genau.

» NeunetzCarsten Pötter in den Kommentaren

Neben den Sicherheitsmängeln und den anspruchsvollen “Server Requirements” gibt es aber vor allem ein Problem: Diaspora basiert auf den gleichen Ideen wie z.B. auch Noserub oder StatusNET und übernimmt auch all deren Probleme. Um einen Kontakt einer anderen Diaspora-Node hinzufügen zu können muss man seinen Identifier kennen (z.B. pfefferle@diaspora.t3n-magazin.de)… ein Problem mit dem beispielsweise die OpenID-Community schon seit Jahren kämpft. Des Weiteren spricht Diaspora eine eigene Sprache und kann nicht mit funktionierenden, etablierten und dezentralen Systemen (basierend auf offenen Standards) wie StatusNET, verbunden werden!

Technische Mittel ein dezentrales Netzwerk zu erstellen gibt es genug: OStatus, Salmon Protocol, Pubsubhubbub, OpenID uvm. (von denen Diaspora übrigens keine einzige nutzt) und wir brauchen wirklich nicht noch eine neue offene Plattform… viel wichtiger wäre doch die bestehenden Netzwerke untereinander zu verbinden oder einen Weg zu finden, dem normalen Surfer das Thema Identifier näher zu bringen…

Ich will keine Software installieren müssen um dann nur User der gleichen Software folgen zu können, ich will Google-User mit meinem Twitter-Account verbinden! Ich will meine Bilder bei Flickr hoch laden und bei MySpace referenzieren. Ein dezentrales “federated social web” bedeutet für mich, das verbinden von verschiedenen Diensten, anstatt einer offenen Kopie von Facebook!

So! Urlaub ist ‘rum und die OpenWeb-Worker kommen auch langsam wieder aus der Sommerpause…

Diaspora: Developer Release
Seit gestern gibt’s ein erstes Developer Release vom dezentralen, open-source “Facebook-Killer” Diaspora:

Today, we are releasing the source code for Diaspora. This is now a community project and development is open to anyone with the technical expertise who shares the vision of a social network that puts users in control. From now on, we will be working closely with the community on improving and solidifying Diaspora.

» Developer Release
» Quellcode auf Github

OAuth 2.0 (without Signatures) is Bad for the Web
Eran Hammer-Lahav macht seinem Frust Luft und fasst zusammen was ihm am neuen OAuth 2 Standard nicht passt.

Without signatures, OAuth 2.0 cannot safely support discovery. It is a waste of time and a risky business. Clearly, the OAuth community today does not care enough about discovery and interoperable services to do something about it. The cryptographic solutions proposed so far are focused on self-encoded tokens and other distributed systems, based on narrow use cases promoted by the likes of Google, Microsoft, and a few other enterprise-focused companies.

» OAuth 2.0 (without Signatures) is Bad for the Web

Cliqset Salmon demonstration
Blogposts werden bei Twitter kommentiert oder bei Facebook ge-”liked”, nur das Blog bekommt relativ wenig davon mit und sein Autor darf deshalb auf die Suche nach den diversen Reaktionen gehen. Mit dem Salmon-Protocol soll damit Schluss sein. Kommentare auf Facebook könnten dank Salmon zusätzlich an den Ursprungs-Artikel zurück “geführt” werden und somit die Kommunikation von den verteilten Netzen wieder an einer Stelle vereinen. Cliqset zeigt in einem Screencast, wie Salmon in Kombination mir Webfinger und Pubsubhubbub sogar dezentrales microbloggen zulassen.

» Cliqset Salmon demonstration
» Salmon-Protocol

OpenStack oder OpenStack?
Der OpenStack hat sich als Begriff für die offene Alternative zu Facebook-Connect durchgesetzt: OpenID + OAuth + Portable Contacts + Open Social + XRDS/XRDS-Simple/XRD/Webfinger. Bisher! Leider entfremdet Rackspace OpenStack jetzt für das eigene Open Source Server-Cloud-System.

Innovative, open source cloud computing software for building reliable cloud infrastructure.

…es wäre schade wenn man in Zukunft aus jedem Buzzword gleich ein Trademark machen müsste um seine Bedeutung längerfristig zu sichern.

» OpenStack Open Source Cloud Computing Software