Rise of the IndieWeb

von Matthias Pfefferle | Screenguide #26, Kreation

Die IndieWeb-Bewegung hat gerade in den letzten Jahren enorm an Popularität gewonnen. Kein Wunder: Posterous wurde von Twitter gekauft und eingestellt, Google Buzz durch Google Plus ersetzt und MySpace hat seine Blogging-Plattform geschlossen. Alleine mit Geocities wurden 2009 knapp 23 Millionen Seiten unwiderruflich vom Netz genommen. Riskieren Sie keinen weiteren Datenverlust, schließen Sie sich dem IndieWeb an, und machen Sie sich unabhängig.

Silhouetten in Form einer Demo/Revolution 

Soziale Netzwerke haben durchaus ihre Vorzüge. Sie bieten ihren Nutzern die Möglichkeit, neue Freundschaften zu knüpfen, mit Freunden in Kontakt zu bleiben und Inhalte mit ihnen zu teilen. Funktionalitäten, mit denen ein Blog in der Regel nicht mithalten kann. Auf der anderen Seite sind Texte und Bilder auf sozialen Netzwerken vergänglich. Das IndieWebCamp-Wiki zeigt eine beachtliche Liste an Plattformen, die im Laufe der Zeit eingestellt wurden. Wer seine Inhalte allein einem dieser Netzwerke anvertraut hat, hat gegebenenfalls all diese Inhalte verloren. Ein Netzwerk muss aber nicht zwingend schließen, um einen Datenverlust zu verursachen. Twitter hat beispielsweise seine Suche auf einen relativ kurzen Zeitraum beschränkt, um der enormen Datenflut Herr zu werden, und Facebook löscht Artikel bzw. Profile, wenn diese gegen die eigenen AGB verstoßen.

Inhalte, die wir selbst generieren, sollten auch uns gehören und nicht ausschließlich über ein Daten-Silo veröffentlicht werden.

Auch kleine und unabhängige Netzwerke bieten hier keine Ausnahme. App.net warb beispielsweise mit seinen offenen Schnittstellen und flexiblen Anwendungsmöglichkeiten. Aber leider hat App.net nicht genug Geld erwirtschaftet und musste die Entwicklung bis auf Weiteres einstellen. Wie sich Ello entwickeln wird, bleibt abzuwarten (siehe Screenguide Nr. 25, Seite 92 f.). Auch Diaspora und Status.NET bieten keinen Ausweg aus der Misere. Die Plattformen sind zwar auch offen und funktionieren sogar dezentral, aber im Prinzip sind sie ebenso nur soziale Netzwerke. Ob Facebook oder einem Betreiber eines Diaspora-Servers das Geld ausgeht, bedeutet für Sie das Gleiche: Verlust Ihrer Daten!

IndieWebCamp

Tantek Çelik (der geistige Vater der Microformats), Amber Case und Aaron Parecki (der Betreiber von OAuth.net) gelten als Gründer der IndieWeb-Bewegung. Sie organisierten im Juni 2011 das erste IndieWebCamp in Portland. Treibende Kraft für das erste Camp war vor allem die Frustration über die Entwicklung des Social Webs. Immer mehr soziale Netzwerke stellen ihren Betrieb ein oder mutieren zu sogenannten Walled Gardens. Google, Microsoft, die Internet Engineering Task Force (IETF) und das W3C sorgen dafür, dass bisherige Standards wie OpenID oder OAuth zu komplexen Enterprise-Lösungen weiterentwickelt werden. Parallel dazu gründet das W3C die „Federated Social Web Incubator Group“, um darüber zu diskutieren, wie ein dezentrales soziales Netzwerk aussehen könnte. Tantek fasst das Problem in einer Präsentation folgendermaßen zusammen: „Mich interessieren keine dezentralen Protokolle, mich interessieren meine Daten und mich interessieren meine Freunde.“

Gruppenfoto des erstes IndieWebCamps
Abb. 1: IndieWebCamp 2011 in Portland

Um nicht immer wieder die gleichen Fehler zu begehen, richtet sich das IndieWebCamp ausschließlich an Entwickler und Designer. Im Fokus stehen keine theoretischen Protokolle, sondern funktionierender Code. Aus den IndieWebCamp-Prinzipien:

  • Entwickeln Sie Programme zuerst für Ihren eigenen Nutzen und versuchen Sie nicht, zu viele Bedürfnisse Ihrer Freunde einfließen zu lassen.
  • „Eat your own dogfood“ – Benutzen Sie Ihre Software selbst, denn wenn Sie sie nicht benutzen, warum sollten sie andere verwenden?
  • Dokumentieren Sie Ihre Erkenntnisse und Fehler für andere.
  • Veröffentlichen Sie Ihre Programme, vielleicht können andere davon profitieren.

Der Ablauf eines IndieWebCamps ähnelt einem klassischen Barcamp. Der einzige wesentliche Unterschied zu einem BarCamp ist der Fokus auf die technischen Aspekte. Der erste Tag gleicht dem einer klassischen Unkonferenz und beinhaltet Vorträge und Diskussionen rund um das Thema IndieWeb. Der zweite Tag gleicht aber eher einem Hackathon, bei dem die zuvor diskutierten Ideen direkt umgesetzt und anschließend präsentiert werden.

POSSE

Die Ziele der IndieWeb-Bewegung lassen sich mit zwei Sätzen kurz zusammenfassen: „Own your data“ und „Publish (on your) Own Site, Syndicate Elsewhere“ (kurz POSSE). Inhalte werden zuerst auf der eigenen Seite verfasst und danach über die sozialen Netzwerke geteilt. Diese Vorgehensweise ist sicherlich nicht neu und klingt auch nicht wirklich spektakulär, ist aber ein durchaus effektives Mittel, um unabhängig zu bleiben und trotzdem die Vorzüge der sozialen Netzwerke auszunutzen. Stellt ein Netzwerk seinen Betrieb ein, reicht es, das Sharing zu kappen oder auf ein neues Netzwerk umzustellen. Die ursprünglichen Daten bleiben aber dauerhaft im eigenen System und können so nicht verloren gehen. POSSE ist die Grundlage für die meisten IndieWeb-Ideen bzw. -Technologien und wird auch auf die verschiedensten Bereiche angewandt. Jeremy Keith speichert beispielsweise seine Bookmarks auf dem eigenen Server und teilt sie anschließend über Delicious, und Tantek Çelik twittert ausschließlich über sein Weblog. Aber auch das Kommentieren findet auf diese Weise statt: Ein Kommentar wird zuerst auf der eigenen Seite verfasst und dann per WebMention verbreitet (siehe „IndieMark – Level 2“).

PESOS

Bietet eine Plattform keine passende API an, funktioniert natürlich auch der umgekehrte Weg. „Publish Elsewhere, Syndicate (to your) Own Site“ (kurz PESOS). Hier werden Inhalte zuerst auf einer Plattform wie z. B. Instagram gepostet und dann die Bilder in die eigene Seite importiert.

Im Prinzip lassen sich alle folgenden Ideen und Technologien auf diesen Grundsatz zurückführen. Dreh- und Angelpunkt bleibt die eigene Website.

IndieMark

IndieMark ist eine Art Index, der das technische Level einer IndieWeb-Anwendung darstellt. Außerdem soll er Ihnen helfen, einen leichteren Einstieg in die Thematik zu bekommen und Ihre Website Schritt für Schritt IndieWeb-kompatibel zu machen. Grundvoraussetzungen sind natürlich eine eigene Domain und eine Website.

IndieMark – Level 1

Level 1 beinhaltet in erster Linie einige vorbereitende Maßnahmen, die Ihnen später die Implementierung weiterer Features erleichtern werden. Zuerst sollten Sie Ihre Website IndieAuth-tauglich machen. IndieAuth ist der Authentifizierungsmechanismus, der von den meisten IndieWeb-Anwendungen benutzt wird, und außerdem die einzige Möglichkeit, sich am IndieWebCamp-Wiki zu registrieren. IndieAuth oder auch RelMeAuth ist ein extrem simpler, aber effektiver Log-in-Mechanismus und basiert auf dem gleichen Prinzip wie OpenIDs „Delegation“-Prozess. Die eigene Website dient als Identifier, und ein soziales Netzwerk übernimmt die eigentliche Authentifizierung (Abb. 2).

IndieAuth-Log-in
Abb. 2: IndieAuth-Log-in

Für die Implementierung sind lediglich zwei Schritte notwendig. Verlinken Sie auf Ihrer Seite alle Social-Network-Profile (falls Sie Zeit sparen möchten, finden Sie auf indieauth.com eine Liste von Diensten, die direkt unterstützt werden), und zeichnen Sie diese mit rel-me aus. Rel-me soll sicherstellen, dass es sich bei den verlinkten Seiten auch wirklich um Ihre Profile handelt und nicht um willkürliche Links auf x-beliebige Seiten.

IndieWebify.Me ist ein IndieMark-Validator, mit dem Sie Ihre WebMention oder Microformats2-Implementierung testen können.

HTML, Link auf ein Social-Media-Profil
  1. <a href="http://github.com/mustermann" rel="me">Max Mustermann</a>

Melden Sie sich danach auf Ihren sozialen Netzwerken an, und hinterlegen Sie dort die URL zu Ihrer Homepage. Praktischerweise zeichnen unter anderem Twitter, Google+, App.net und Github ihre Links auch mit rel-me aus.

HTML, Link zurück auf Ihre Website
  1. <a href="http://example.com" rel="me">Max Mustermann</a>

Da sich die Seiten jetzt gegenseitig referenzieren, kann man davon ausgehen, dass sie ein und derselben Person gehören oder zumindest von ihr verwaltet werden.

Im Prinzip handelt es sich bei dem folgenden Log-in um den klassischen Single-Sign-on-Prozess von Twitter, Github oder Google+. Mit dem einzigen Unterschied, dass Sie, bevor Sie einen der vielen Log-in-Buttons nutzen, Ihre Webseite angeben müssen. Außerdem wird nach dem Log-in überprüft, ob das Profil, unter dem Sie sich gerade angemeldet haben, auch auf Ihre Webseite verlinkt. Ist das der Fall, hat Ihr Log-in funktioniert.

Warum dieser Umweg über die eigene Webseite und warum nicht direkt mit Twitter anmelden? Im Gegensatz zum reinen Twitter-Log-in sind Sie bei IndieAuth nicht direkt von Twitter abhängig. Die Seite, an der Sie sich anmelden, speichert nicht Ihre Twitter-Daten, sondern Ihre private Webseite. Twitter fungiert in dem Log-in-Prozess nur als eine Art Bürge. Sollte Twitter, aus welchen Gründen auch immer, plötzlich nicht mehr funktionieren, entfernen Sie Ihr Profil aus der rel-me Liste, und benutzen Sie einfach ein anderes.

Als Nächstes sollten Sie Ihre Inhalte mit Microformats2 auszeichnen. Microformats sind Semantiken, die auf den HTML-Attributen „class“ und „rel“ basieren. Eines der bekanntesten Mikroformate ist z. B. rel-nofollow, das mittlerweile von allen großen Suchmaschinen unterstützt wird. Microformats2 ist die logische Weiterentwicklung dieser Semantiken. Im Gegensatz zur ersten Version unterstützen Microformats2 sogenannte Prefixes:

  • h-* für Objekt-Namen, wie z. B. 'h-card'
  • p-* für einfache Attribute, wie z. B. 'p-name'
  • u-* für URL-Attribute, wie z. B. 'u-photo'
  • dt-* um ein Datum zu kennzeichnen, wie z. B. 'dt-bday'
  • e-* für eingebettete Daten (kann auch HTML enthalten), wie z. B. 'e-note'

Durch diese Prefixes ist es möglich, universale Parser zu schreiben, die auch unbekannte Formate interpretieren können, solange sie sich an die Spezifikation halten. Das umschließende h-*Element kennzeichnet ein Objekt und die enthaltenen Elemente, z.B. p-* und u-*, beschreiben die Attribute.

Microformats spielen bei den meisten IndieWeb-Anwendungen eine zentrale Rolle. Die IndieWeb-Bewegung forciert keine speziellen Tools und muss sich somit auf den kleinsten gemeinsamen Nenner einer Webseite einigen: HTML.

Microformat / HTML
  1. <article class="h-entry">
  2.   <h1 class="p-name">Überschrift</h1>
  3.   <p class="p-summary">Zusammenfassung.</p>
  4.   <div class="e-content">
  5.     <p>Eigentlicher Text des Blog-Posts.</p>
  6.   </div>
  7. </article>

Das hat zum einen den Vorteil, dass Ihre Website auch gleichzeitig Ihre API ist und Sie Daten nicht doppelt zugänglich machen müssen (beispielsweise über einen zusätzlichen RSS-Feed). Zum anderen ist es auch möglich, statische Webseiten auf Basis von z. B. Jekyll zu unterstützen. Im Prinzip reicht es, wenn Sie sich zuerst auf die zwei wichtigsten Microformats konzentrieren. Benutzen Sie h-entry für Ihre Artikel und h-card für die Autoreninformationen.

IndieMark – Level 2

Level 2 empfiehlt die Implementierung von POSSE. Da POSSE aber sehr stark von der Plattform abhängt, ist es schwer, Ihnen hier Code-Beispiele zu präsentieren. Sie finden im IndieWeb-Camp-Wiki diverse Ansatzpunkte bzw. Libraries oder Plug-ins, die das Posten nach Facebook und Twitter erleichtern.

Bridgy ist außerdem ein Webservice, der Ihnen einen Großteil der Implementierung abnimmt. Bridgy unterstützt POSSE und PESOS, d. h., er hilft Ihnen beim Teilen Ihrer Blog-Posts auf Facebook und Twitter und „sammelt“ die Reaktionen der sozialen Netzwerke, um sie dann wieder zurück an Ihren Blog zu schicken (Abb. 3).

Bridgy-Twitter-Profil
Abb. 3: Bridgy-Twitter-Profil

Bridgy ist eine Art WebMention Proxy (WebMentions sind eine moderne Form des Pingbacks, eine ausführlichere Erklärung finden Sie im nächsten Kapitel). Nachdem Sie sich bei Bridgy mit Ihren verschiedenen Profilen angemeldet haben, durchsucht der Webservice Ihre Einträge bei Twitter, Facebook und Google+ nach passenden Links und schickt die Kommentare, Shares, Likes und Re-Tweets als WebMention an Ihre Webseite. Dadurch könnten Sie bei einem Blogpost also auch Kommentare anzeigen, die eigentlich auf Facebook zu einem Artikel geschrieben wurden. Wenn Sie einen neuen Artikel veröffentlichen, müssen Sie umgekehrt eine WebMention an Bridgy schicken, der diese dann auf den von Ihnen autorisierten sozialen Netzwerken veröffentlicht.

Da WebMentions einen zentralen Building-Block des IndieWebs darstellen, unterstützen die meisten IndieWeb-Libraries und Tools den Ping-Dienst von Haus aus. Falls es für Ihre Blogging-Plattform dennoch keinen Support gibt, müssen Sie immerhin nur einen Standard implementieren, um eine Vielzahl von Services und APIs nutzen zu können.

Dennoch sollten Sie Bridgy gerade in Deutschland mit Vorsicht genießen. Der Webservice greift Daten ab, ohne sich um ihren Kontext zu kümmern. Es kann also passieren, dass Reaktionen aus privaten und nicht öffentlichen Diskussionen plötzlich öffentlich auf Ihrem Blog zu sehen sind. Streng genommen haben Sie keinerlei Rechte an den Kommentaren und können diese deshalb auch nicht ohne Weiteres übernehmen. Wenn Sie auf Nummer sicher gehen wollen, sollten Sie sich zuerst nur auf den POSSEService von Bridgy konzentrieren.

Unbedenklicher und wesentlich einfacher zu implementieren sind dagegen Web-Actions. Web-Actions sind Universal-Elemente, ähnlich dem „Tweet“-Button oder Facebooks „Like“-Button, die zwar auch Aktionen wie „Like“, „Share“ oder „Bookmark“ definieren, aber nicht vorschreiben, wie oder von wem sie ausgeführt werden sollen. Eine Web-Action ist ein simples HTML5-Custom-Element mit einem do-Attribut (beschreibt die Aktion) und einem with-Attribut (definiert die URL, unter der die Aktion ausgeführt werden soll).

„Post“ Web-Action
  1. <indie-action do="post" with="http://example.com/post/1">
  2. <!-- Twitter, Facebook oder Google+ Buttons als Fallback -->
  3. </indie-action>

Web-Actions sind rein beschreibend und werden vom Browser erst einmal ignoriert. Um die Aktionen dennoch ausführen zu können, sind Plug-ins wie etwa der „Web Action Hero Toolbelt“ nötig. Über das Plug-in können Sie definieren, welcher Service welche Aktion ausführen soll (Abb. 4). Im Sinne der IndieWeb-Idee sollte dieser Service von Ihnen selbst betrieben und der „Like“ oder „Share“ danach möglichst noch per POSSE an Twitter oder Facebook weitergeleitet werden.

„Web Action Hero Toolbelt“-Einstellungen
Abb. 4: „Web Action Hero Toolbelt“-Einstellungen

Der Toolbelt zeigt dann an der Stelle der Web-Action einen individuellen Share-Button an, der Sie nach dem Klick auf die von Ihnen hinterlegte Seite weiterleitet. Am besten kombinieren Sie die WebAction mit den klassischen Buttons von Google und Facebook. Dazu „umschließen“ Sie die Buttons der sozialen Netzwerke einfach mit dem Web-Action-Element (siehe Code-Beispiel). So bekommt jeder Ihrer Seitenbesucher die Chance, Ihre Seite weiterzuverbreiten, sei es über die sozialen Netzwerke oder über den eigenen IndieWeb-Service.

IndieMark – Level 3

Implementieren Sie WebMentions. WebMentions sind eine sehr vereinfachte Version von Pingbacks bzw. Trackbacks und funktionieren nach dem gleichen Prinzip. Alle Links eines Artikels werden angepingt, um Ihnen mitzuteilen, dass Sie gerade erwähnt wurden. Im Gegensatz zu XML-RPC (Pingback) oder embedded RDF (Trackback) basiert eine WebMention auf einem simplen HTTP-Post.

Zuerst benötigen Sie einen Endpoint, um WebMentions auf Ihrer Seite entgegennehmen zu können. Eine simple Anleitung für einen PHP Endpoint finden Sie auf dem Blog von Jeremy Keith. Als Nächstes müssen Sie Ihren Endpoint über HTML-Meta-Tags für andere Seiten sichtbar machen.

WebMention Discovery
  1. <link rel="webmention" href="http://example.com/?webmention=endpoint">

Beim Veröffentlichen eines neuen Blogposts passiert Folgendes: Ihr Artikel wird in einem neuen Blogpost verlinkt. Die Blog-Software des verlinkenden Blogs bemerkt die externe URL Ihres Artikels und prüft zuerst Ihre Meta-Tags auf einen WebMention Endpoint. Danach schickt sie einen HTTP-Post an die gefundene URL. Inhalt des Posts sind lediglich die Source-URL (die verlinkende Seite) und die Target-URL (Ihre verlinkte Seite). Ihr Endpoint sollte jetzt noch überprüfen, ob der Artikel auf Ihrer Seite (Target-URL) wirklich existiert und ob die andere Seite (Source-URL) auch wirklich auf Sie verlinkt. Der einfache Aufbau der WebMentions hat diverse Vorteile. Im Gegensatz zu Pingbacks lassen sich WebMentions beispielsweise auch über die Kommandozeile verschicken. Diese Eigenschaft ist vor allem für statische „Source-URLs“ interessant.

Kommandozeile
  1. curl -i -d "source=$source_url&target=$target_url" $targets_webmention_endpoint

Jeremy Keith bietet seinen Seitenbesuchern im Kommentar-Bereich außerdem ein Web-Formular an (Abb. 5), über das sie ihre Webseiten manuell einreichen können.

Einfaches Formular für WebMention
  1. <form method="post" action="$targets_webmention_endpoint">
  2.   <input type="url" name="source" />
  3.   <input type="hidden" name="target" value="$target_url" />
  4.   <input type="submit" value="Ping!" />
  5. </form>
Jeremy Keith’ WebMention-Formular
Abb. 5: Jeremy Keith’ WebMention-Formular

Da eine WebMention über einen normalen POST abgesetzt wird, kann das Formular die Daten direkt an den WebMention Endpoint schicken. Als Form-Action müssen Sie lediglich Ihren WebMention Endpoint angeben und, als Hidden-Field, die URL Ihres Artikels. Das Feld, das Ihre Besucher ausfüllen müssen, wird dann als Source-URL mit Ihrer versteckten Target-URL an Ihren WebMention Endpoint geschickt. Es ist, abgesehen von dem Formular, kein weiterer Entwicklungsaufwand nötig, da der Endpoint ja bereits existiert.

Um den WebMentions etwas mehr Sinn zu verleihen, kommen die in Level 1 implementierten Microformats zum Zuge. Über den hentry lassen sich der genaue Inhalt des Kommentars, ein Titel und der Autor bestimmen. Statt der kryptischen Zusammenfassung die jeder WordPress-Nutzer von Pingbacks gewöhnt ist, können Sie mit WebMentions und Microformats ein echtes dezentrales Kommentar-System abbilden (Abb. 6).

Kryptisches Pingback-Beispiel (WordPress)
  1. […] 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 […]
Dezentrale Kommentare und Likes
Abb. 6: Dezentrale Kommentare und Likes

Unter Verwendung von verschiedenen rel-values können Sie die Reaktion sogar noch näher spezifizieren.

Erweitertes Microformat
  1. <div class="h-entry">
  2.   <a href="..." rel="in-reply-to">...</a>
  3. </div>

Über rel="in-reply-to" können Sie der verlinkten Seite beispielsweise klarmachen, dass es sich bei der WebMention um eine vollwertige Antwort und nicht nur um eine Erwähnung handelt. Diese Art der Klassifizierung eröffnet eine Vielzahl an weiteren Möglichkeiten. Mit der richtigen Formatierung unterscheiden Sie etwa problemlos zwischen einem Kommentar, einem „Like“, einer simplen Erwähnung oder sogar einer Abstimmung. Mit etwas mehr Aufwand lassen sich aber auch komplexere Aktionen lösen, wie beispielsweise die Zusage zu einem Event.

Microformat für die Zusage zu einem Event
  1. <data class="p-rsvp" value="yes">I'm totally there, dude.</data>

Dieses Vorgehen ist zwar kein fester Bestandteil der WebMention-Spezifikation, aber sehr eng mit ihr verknüpft [goo.gl/o8KUWp]. Die Spezifikation lässt den Teil der Texterkennung sogar bewusst aus, um Entwicklern hier freie Hand zu lassen. Die IndieWeb-Community hat sich zwar auf Microformats2 geeinigt, aber im Prinzip wären auch andere Websemantiken wie z. B. RDFa oder Microdata denkbar.

IndieMark – Level > 3

IndieMark 1–3 beinhalten die zentralen Building Blocks der IndieWeb-Bewegung: Identity (IndieAuth), Maschinenlesbarkeit (Microformats) und POSSE (WebMentions und POSSE). In Level 4 und 5 werden diese Kerntechnologien nur noch weiter spezifiziert. Vorgeschlagen werden beispielsweise weitere Microformats und alternative Einsatzmöglichkeiten von WebMentions.

Eine letzte interessante, aber auch umstrittene Idee ist der Reply-Context. Da Sie nach der IndieWeb-Idee alles auf Ihrer eigenen Seite verfassen und nur Kopien ins Netz senden, bekommen Sie vor allem bei Kommentaren ein Problem: Es fehlt der Zusammenhang zwischen einem Kommentar auf Ihrer Seite und dem eigentlichen Artikel auf einer anderen. Außerdem wird der Informations- bzw. Lesefluss enorm gestört, wenn Ihre Seitenbesucher zuerst auf einer anderen Seite einen Artikel lesen müssen, um dann den Kommentar auf Ihrer Seite verstehen zu können. Ähnlich wie bei PESOS wird für den Reply-Context einfach der Original-Artikel kopiert (im besten Fall automatisiert) und über dem eigenen Kommentar angezeigt (Abb. 7). Im Prinzip eine einfache und schnelle Lösung, aber leider auch genauso problematisch wie der PESOS-Ansatz. In der Regel werden die Rechte des Original-Artikels nicht überprüft, bevor sie auf die eigene Seite kopiert werden, vor allem nicht, wenn der Prozess automatisiert abläuft. Das hat zur Folge, dass man einerseits fremde Daten nutzt, für die man in der Regel keine Nutzungsrechte besitzt, und gleichzeitig auch noch doppelten Content generiert, der von vielen Suchmaschinen abgestraft wird.

Reply-Context
Abb. 7: Reply-Context

Fazit

Nicht alle Ideen sind gleich gut oder, dank der unterschiedlichen Rechtslage, für alle Länder gleich umsetzbar. Aber das ist auch nicht schlimm, immerhin handelt es sich um das IndieWeb. Im Vordergrund steht Ihre individuelle Website, auf der Sie implementieren können, was Sie wollen und was Sie für sinnvoll erachten. Klar gibt es einige Techniken, die sich durchgesetzt haben, wie z.B. Microformats oder WebMentions, aber in der Regel ist das IndieWeb offen für neue Ideen. Wichtigste Voraussetzung ist aber immer: „Eat your own dogfood.“

Das IndieWebCamp-Wiki ist ein großer Spielplatz für Geeks. Die Bewegung spricht ausschließlich Entwickler und Designer an und hat nicht den Anspruch, Produkte für die breite Masse zu bauen. Dementsprechend technisch fallen die Diskussionen aus. Nichtsdestotrotz steckt in vielen Überlegungen jahrelange Erfahrung und viel Liebe zum Detail. IndieAuth ist das, was OpenID Connect hätte werden sollen, und WebMentions sind die lange überfällige Weiterentwicklung von Pingbacks. Es macht Spaß, mit den Technologien zu experimentieren, weil sie pures Web sind. Ein wenig HTTP, ein wenig HTML, mehr nicht. Jeder WordPress-Nutzer ist beispielsweise in der Lage, echte Kommentare, Likes oder Check-ins über Pingbacks zu verschicken, ohne ein einziges Plug-in installieren zu müssen.

Selbst wenn die IndieWeb-Bewegung ein reines Nischen-Phänomen bleiben sollte, sorgen einzelne Produkte wie WordPress-Plug-ins oder Known immer wieder für Gesprächsstoff. Außerdem beeinflussen Microformats oder WebMentions mittlerweile auch die Entwicklung zukünftiger W3C-Formate wie z. B. Activity Streams 2.0.

Die hier aufgeführten Aspekte sind generell nur ein kleiner Teil der gesamten IndieWeb-Idee. Bei Interesse sollten Sie sich unbedingt noch einmal intensiv mit IndieMark beschäftigen. Wer an der IndieWeb-Diskussion teilnehmen will, sollte sich einen IndieWebCamp-Wiki-Account erstellen und/oder im #indieweb IRC Channel vorbeischauen.

Übrigens: Am 9. und 10. Mai findet ein IndieWebCamp in Düsseldorf statt.

12. Januar 2016 | Kleine Ergänzung: Am 16. und 17. April findet das IndieWebCamp Nürnberg 2016 statt.

Matthias Pfefferle 

Matthias Pfefferle

ist Webentwickler, beschäftigt sich seit vielen Jahren mit offenen Standards wie OpenID, OStatus oder Microformats und versucht, mit seiner Kolumne und seinem Weblog das Thema speziell in Deutschland voranzutreiben.

Twitter: @pfefferle

Neuen Kommentar schreiben