Text

· · zu lesen
The Logo of the AT Protocol

Vor zwei Jahren wollte Twitter in das „Dezentrale Netzwerke“-Business einsteigen und gründete eigens dafür das Projekt Bluesky. In den folgenden zwei Jahren wurde viel evaluiert und diskutiert, was wohl die beste Lösung für Twitter sei und wir alle fieberten mit ob es nun ActivityPub oder doch Matrix werden würde…

Aber das Warten hat ein Ende! Bluesky hat verkündet wie es weiter geht!

Sie entwickeln ein neues Protokoll!

Das AT Protocol, kurz für Authenticated Transfer Protocol!

Ich hab mir die FAQ mal angeschaut und dort steht warum Bluesky sich gegen ActivityPub entschieden hat:

Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user’s previous data.

Das erinnert mich ein bisschen an die Subline von meinem OpenWeb-Icons Font:

Why OpenWeb Icons? Because Font Awesome had no RSS-icon […]

Weil ActivityPub keine perfekte Lösung für „Account portability“ hat, bauen sie ein komplett neues Protokoll?

ActivityPub ist sicherlich nicht „feature complete“, aber ein guter erster Wurf, was das Fediverse erfolgreich bewiesen hat! Warum arbeitet Twitter also lieber an einem eigen Format anstatt mit dem W3C zusammen an ActivityPub v2?

Warum macht sich das W3C überhaupt noch die Mühe „Standards“ zu definieren?

Wegen der Interoperabilität!

Würde Twitter mit HTTP(S), HTML oder CSS ähnlich umgehen, würde der Browser einfach leer bleiben, weil das &$%§& Internet nur mit einheitlichen Standards funktioniert!

Und das gleiche gilt auch für dezentralte Netze, zumindest wenn sie erfolgreich sein wollen! Darüber hab ich tragischerweise schon vor 10 Jahren geschrieben!

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!

Dezentrale „Walled Gardens“

Das fediverse hat (wie schon erwähnt) bisher einen großartigen Job gemacht und verschiedenste Netzwerke mit den verschiedensten Ausprägungen vernetzt! Ich glaube bin der festen Überzeugung, dass sich diesmal wirklich das offene Format (ActivityPub) durchsetzen wird und Blueskys Authenticated Transfer Protocol auch in ein paar Monaten oder Jahren keine Rolle spielen wird!

Ben Werdmuller hat eine gesunde Einstellung zu dem Thema:

I’m so burned out by open source social, but I’m glad to see people throw energy at the problem, even if it’s not how I would have gone about it.

Twitter

Mehr hab ich dazu eigentlich nicht zu sagen, außer dass wir in der aktuellen Folge des neunetzcasts sehr ausgiebig über genau dieses Problem gesprochen haben!

Text

· · zu lesen
Ein Screenshot meines ersten Blogposts im Mai 2002

Heute vor 20 Jahren habe ich mit dem Bloggen angefangen! Das heißt ich schreibe jetzt fast mein halbes Leben lang Dinge in’s Internet!

Von 2002 bis 2005 ging es viel um persönliches und privates. Ich hatte ein Blog mit Freunden, das oft auch einfach als Ersatz zu einem Messenger benutzt wurde.

2005 hab ich dann angefangen hier zu bloggen. Von 2005 bis 2007 waren mein Studium, Web-Technologien und das Web 2.0 die großen Themen auf notiz.Blog. Ich war fasziniert von der Blogosphäre und den sozialen Netzwerken die (damals noch als die Guten) so nach und nach entstanden.

Ab 2007 entwickelten sich die großen „Communities“ immer mehr zu „Walled Gardens“ und ich schrieb und beschäftigte mich bis 2010 viel mit den Themen „Dezentrale Netzwerke“ und „Data Portability„.

Seit 2007 hab ich auch angefangen mich intensiver mit meiner Blogging-Plattform WordPress zu beschäftigen. Dadurch ist wesentlich mehr Code als Text entstanden und wenn ich zum schreiben kam, ging es meistens um die Entwicklung von Plugins und (dem einen) Theme(s).

Die Themen ab 2007 sind im Prinzip auch die Themen um die es bis heute geht. Wenig bis nichts persönliches, viel Technik, WordPress und noch mehr Open Web. Das ist OK für den Moment, muss aber nicht so bleiben 🙂

Auf die nächsten 20 Jahre! 🎉

Text

· · zu lesen

Auf dem CloudFest Hackathon im März, hab‘ ich mich ein wenig mit Alain Schlesser über WordPress und Plugin-Entwicklung unterhalten. Alain meinte, dass er, wenn es das Plugin hergibt und es zeitlich möglich ist, immer zuerst eine generische Library bauen und diese dann über ein WordPress-Plugin implementieren würde.

Vor ein paar Tagen hab ich mich an unser Gespräch erinnert, weil ich mich (aus Gründen) wieder intensiver mit dem ActivityPub-Plugin beschäftigt habe. Wir hatten schon vor einem Jahr den Plan, eine ActivityPub-Bibliothek zu verwenden, um uns nicht mit dem Protokoll beschäftigen zu müssen, und uns so voll und ganz auf die WordPress Integration konzentrieren könn(t)en. Wir haben die Idee aber erstmal nicht weiter verfolgt, da die Bibliothek eine Reihe von schwergewichtigen Third-Party-Libs wie Guzzle (HTTP-Client), Monolog (Logger) oder Symfony Cache (Caching) mit sich bringt. Für all diese Funktionen hat WordPress eigene Lösungen und wegen der Interoperabilität mit anderen Plugins, sollte man diese auch nutzen.

Bei der erneuten Evaluierung der ActivityPub-Bibliothek ist mir aufgefallen, dass sich Monolog, durch einen beliebigen PSR-3 kompatiblen Logger ersetzen lässt.

Kurze Erklärung zu PSR:

Eine PHP Standard Recommendation (PSR) ist eine PHP-Spezifikation, welche durch die PHP Framework Interop Group veröffentlicht wird. Ähnlich einem Java Specification Request in Java dient sie der Standardisierung von Programmierkonzepten. Ziel ist es die Interoperabilität von Komponenten zu ermöglichen und eine gemeinsame technische Basis zu schaffen oder bewährte Konzepte für einen guten Programmierstil sowie eine gute Testbarkeit von Komponenten umzusetzen. Verschiedene Frameworks wie z. B. die der TYPO3-Community, Symfony oder Zend implementieren hierbei PSR-Spezifikationen in einem selbst gewählten Umfang.

https://de.wikipedia.org/wiki/PHP_Standard_Recommendation

PSR-3 definiert ein standardisiertes Logger-Interface, welches (in unserem Beispiel) durch Monolog implementiert wird. Beim initialisieren des ActivityPub-Servers, lässt sich Monolog, durch einen alternativen Logger ersetzen, solange dieser auch PSR-3 konform ist.

use ActivityPhp\Server;

// Create a server instance with no log output
$server = new Server([
    'logger'   => [
        'driver' => '\Psr\Log\NullLogger'
    ],
]);Code-Sprache: PHP (php)

Also hab ich mir überlegt, wie so ein Logger für WordPress aussehen könnte und einen PSR-3 kompatiblen Wrapper gebaut:

namespace WPPSR\Log;

use Psr\Log\AbstractLogger;

class ErrorLogLogger extends AbstractLogger {
    public function log( $level, $message, $context = array() ) {
        if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
            if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) {
                error_log(
                    sprintf(
                        '%s: %s. Details: %s',
                        $level,
                        trim( $message, '.' ),
                        json_encode( $context )
                    )
                );
            }
        }
    }
}Code-Sprache: PHP (php)

PSR definiert passenderweise auch Interfaces für HTTP-Clients, Request-/Response-Objekte und Caching. Für die Request-Library die in WordPress benutzt wird, gibt es sogar schon ein passendes Issue: https://github.com/WordPress/Requests/issues/320

Leider sind Caching und der HTTP-Client in der ActivityPub-Implementierung noch nicht austauschbar, obwohl beide benutzten Libraries PSR kompatibel sind. Das heißt ich muss zuerst evaluieren, wie viel Arbeit es ist, die ActivityPub-Lib anzupassen, um dann diverse Wrapper für das WordPress Caching und die Request-/Response-Classes zu schreiben…

Bzw. muss ich das wahrscheinlich nicht einmal selbst implementieren, da ich bei weitem nicht der Erste war, der diese Idee hatte:

WordPress tut sich immernoch schwer mit modernem PHP-Dependency-/Plugin-Management. Ersteres ist praktisch nicht vorhanden (wird aber zumindest nicht verhindert) und letzteres basiert immer noch auf einem Prozess in dem SVN eine tragende Rolle spielt. Aber mit PSR(-Wrappern) kann man das Problem schon ganz gut kompensieren 🙂

Text

· · zu lesen
Ein Code-Beispiel wie Kommentare als Custom Post Type registriert werden können.

Eine Leseempfehlung vorweg: „Yes, Comments Are Still Relevant, But We Need a Better System“ von Justin Tadlock auf WPTavern!

Soziale Netzwerke haben die Art wie wir kommunizieren drastisch verändert. Wir reagieren selten mit Text, statt dessen liken, re-tweeten, sharen und faven wir was das Zeug hält. Und wenn wir mit Text reagieren, hat dieser spätestens seit Twitter, einen anderen Stellenwert. Ein Kommentar ist nicht länger ein Stück Text unter einem Artikel, ein Kommentar steht für sich alleine und wird durch die Plattform in den richtigen Kontext gesetzt, abhängig vom Einstiegspunkt des lesenden.

Mein Tweet, über meine Timeline, mit Depones Antwort
Daniels Antwort über seine Timeline, mit meinem Tweet als „Reply-Context“.

Die IndieWeb Community nennt das einen Reply-Context.

Diese Art der Darstellung und Handhabung von Reaktionen ist auch in dezentralen Netzwerken sehr populär. Mastodon ähnelt sehr, dem von Twitter gekauften Tweetdeck und imitiert auch dessen Darstellung. Die IndieWeb Bewegung geht sogar noch einen Schritt weiter und schafft mit Webmentions eine Möglichkeit über Blog-Posts dezentral zu kommentieren.

Die Kommentar-Funktion von WordPress ist dagegen bald 20 Jahre alt und dementsprechend antiquiert.

Zeit das zu ändern!?!

Custom Post Type

Ich arbeite seit knapp 15 Jahren daran, WordPress im IndieWeb und Fediverse zu verankern. Das große Problem ist dabei immer wieder die Persistenz und die Darstellung von Reaktionen. Ich habe mir viele Gedanken gemacht, wie man das Problem beheben und WordPress‘ Kommentar System modernisieren könnte, und ende immer an dem Punkt, wo ich versuche die Custom Post Type – Funktionalität für Kommentare nachzubauen.

Aber warum? Wenn ich eh alles nachbauen müsste, wäre es doch viel sinnvoller direkt Post-Types zu benutzen.

register_post_type( 'comment' );Code-Sprache: JavaScript (javascript)

Aktuell bildet WordPress Posts, Pages, Attachments, Revisions, Navigation Menus, Custom CSS und Changesets über Custom Post Types ab… Warum also nicht auch Kommentare und andere Reaktionen?

Durch die Gleichsetzung der Datenstruktur von Posts und Comments, lassen sich diese einheitlich und dadurch einfacher verarbeiten und über z.B. APIs ausgeben. Gerade ActivityPub macht, wie Twitter, keinen Unterschied zwischen Kommentar, Antwort, Like, Boost oder initialem Text.

Die (Custom-)Post Tabelle bietet über post_parent schon jetzt die Möglichkeit komplexe Zusammenhänge wie z.B. auch Threaded-Comments abzubilden. Über den post_status ließen sich außerdem Kommentar-Status sowie eine Spam-Behandlung realisieren und commentmeta kann komplett in postmeta aufgehen.

Neben den klassichen Kommentaren lassen sich aber auch andere Reaktionen umsetzen.

Like, Share, …

Mit Post-Formats hat WordPress ein interessantes Konstrukt um Posts (über eine Taxonomy) weiter zu klassifizieren. Was für Posts das aside, gallery, link oder video Format ist, könnte für Comments das Like, Share oder Bookmark Format sein.

Themes könnten ihren Support wie folgt definieren:

add_theme_support( 'comment-formats', array( 'like', 'share', 'bookmark' ) );Code-Sprache: PHP (php)

Und Plugins, wie Webmention oder ActicityPub, könnten neue Formate wie folgt registrieren:

register_comment_format( string $comment_format, array|string $args = array() )Code-Sprache: PHP (php)

Fazit

Technisch spricht also nichts dagegen, Custom Post Types auch für Kommentare zu benutzen, man muss eigentlich nur noch alle Kommentar-Funktionen und -Klassen anpassen und fertig!

…und direkt über wpdb wird sicherlich eh niemand auf die Kommentar-Tabelle zugreifen! 😉

Spaß beiseite… Ich mag die Idee wirklich, hab aber bisher noch keinen ähnlichen Vorschlag im Trac gefunden… Ob das ein Zeichen ist?

Text

· · zu lesen

Im modernen Sprachgebrauch wird der Begriff [Posse] in übertragenem Sinn […] genutzt, um als grotesk empfundene Vorgänge in Gesellschaft und Politik zu beschreiben.

https://de.wikipedia.org/wiki/Posse

Wer sich (aus gegebenem Anlass) sorgen um Twitter macht, sollte sich mal mit der etwas anderen POSSE befassen.

POSSE is an abbreviation for Publish (on your) Own Site, Syndicate Elsewhere, the practice of posting content on your own site first, then publishing copies or sharing links to third parties (like social media silos) with original post links to provide viewers a path to directly interacting with your content.

https://indieweb.org/POSSE

Installiert euch WordPress! Veröffentlicht Texte, Bilder, Videos und Ideen nicht auf Twitter sondern auf eurer eigenen Seite! Teilt eure Inhalte über Twitter!

Und sollte Twitter „verschwinden“, teilt es über Mastodon! usw, usw…

Schaut euch dazu gerne auch mal Brid.gy an!

Text

· · zu lesen

Vor ein paar Tagen bin ich über einen Post von Tantek Çelik gestolpert, in dem er metaformats vorstellt.

Introducing (https://microformats.org/wiki/metaformats), an extension to for parsing invisible data published in HTML meta tags, for backward compatibility with existing vocabularies consumed by multiple testable interoperable implementations.

https://tantek.com/2022/091/t1/metaformats

Der Vorschlag ist vom 01. April und war wohl ursprünglich als April-Scherz gedacht.

metaformats started as an April Fools joke concept to describe how to both publish using microformats class names and openly parse meta tags as a fallback for what should be in-the-body visible data, including backcompat with OGP, Twitter Cards, and meta author, description, and anything else real sites (like search engines) appear to consume.

https://indieweb.org/metaformats

Eine Art Fallback-Spezifikation für Microformats-Parser finde ich in der Tat etwas sperrig, aber ich mag die Idee eines Fallbacks an sich.

Microformats sind ein Building-Block des IndieWebs und werden unter anderem auch von Webmentions genutzt. Es sind Markup-Formate zur semantischen Auszeichnung von HTML. In der Version 2, werden Microformats aber fast ausschließlich von der IndieWeb Community benutzt und sind darüber hinaus wenig bekannt.

Aber gerade für WordPress ist es extrem schwer, bestehende Themes nachträglich mit Microformats zu „veredeln“. Wir haben es mit diversen Plugins versucht, mit nur mäßigem Erfolg. Andere Formate wie das Open Graph Protocol oder Schema.org (JSON-LD) sind da wesentlich einfacher zu integrieren, da sie nicht bestehendes HTML erweitern und durch den Support der großen Suchmaschinen und sozialen Netzwerke, auch viel attraktiver sind.

Ich bin kein großer Fan von embedded JSON-LD, aber wenn es nicht anders funktioniert und seine Reichweite hat, warum sollte man es dann ignorieren?

Das IndieWeb hat eigentlich eine großartige Philosophie um mit solchen „Problemen“ umzugehen.

bridge all the things is a nascent IndieWeb philosophy that prioritizes interoperability over ideology, NIH, historical disagreements, etc. ecosystems are valuable and powerful, and one easy way to extend an ecosystem is to bridge it with other existing ecosystems.

https://indieweb.org/bridge_all_the_things

Für das Webmention Plugin haben David und ich schon vor Monaten einen ganz ähnlichen Ansatz gewählt. Neben Microformats unterstützen wir auch OGP, Twitter-Cards, Schema.org, Meta-Header und die WordPress API, um eventuell fehlende Microformats v2 zu kompensieren.

Selbst wenn „metaformats“ nur als April Scherz gedacht waren, hat die Idee Potential um speziell Webmentions voran zu treiben, da sie eine direkte Abhängikeit zu einer speziellen Websemantik verhindert.

Bridge all the things!

Text

· · zu lesen
Das IndieWeb Team auf dem Cloudfest Hackathon

Vom 19. bis 21. März fand der CloudFest Hackathon in Rust statt und ich hatte die Chance ein Projekt einzureichen und zu leiten:

WordPress and the IndieWeb

The IndieWeb is a community of individual personal websites, connected by simple standards, based on the principles of owning your domain, using it as your primary identity, to publish on your own site (optionally syndicate elsewhere), and own your data.

There are a variety of WordPress-plugins implementing these standards and principles, to help people to stay independent. Most of these plugins are very basic, have no or only little documentation with a poor user experience. Help the movement to mature and gain a broader audience.

Ich hatte mir im Vorfeld nicht viel Gedanken zum Hackathon gemacht, hab aber insgeheim gehofft, der Version 5.0 vom Webmention Plugin (einer nahezu kompletten Überarbeitung an der David Shanske und ich schon eine halbe Ewigkeit arbeiten) ein wesentliches Stück näher zu kommen… Das Wochenende lief dann aber doch etwas anders… auch großartig, aber anders 🙂

1. Tag

Wir waren eine wild zusammengewürfelte Truppe von 8 Leuten mit den verschiedensten Lebensläufen und ich hab mir den ersten Tag viel Mühe gegeben, das IndieWeb und Webmentions zu erklären. Die Diskussionen waren spannend und hitzig und gingen sogar so weit, dass ich zwischendurch den generellen Sinn und Zweck des Webmention Plugins verteidigen musste.

Hackathon Gruppe

Letztendlich haben aber nicht meine Argumente die Gruppe überzeugt, sondern eine Präsentation des Plugins mit all seinen aktuellen Features. Wer diesen Erkenntnisprozess nachvollziehen möchte, kann gerne Hagen Grafs „Webmention Journey“ auf Twitter verfolgen 🙂 (Nachtrag: Hagen hat seine Journey mittlerweile auch „verbloggt“)!

Meine Fazit des ersten Tages?

Man muss nicht die Geschichte des IndieWebs verstehen und auch nicht den Webmention Standard gelesen haben um von der Funktionalität begeistert zu werden, vor allem in der Kombination mit Brid.gy (Brid.gy schlägt eine Brücke zwischen dem Webmention Standard und den proprietären APIs der bekannten Social Networks. So landen dann auch Likes auf Facebook und Kommentare auf Twitter, im eigenen Blog).

Ich werde Versuchen mich zukünftig weniger auf Geschichte und Technologie zu konzentrieren und auf Vorträgen und Hackathons mehr Fokus auf die Funktionalität zu legen.

Ich hab die Plugins in erster Linie erstmal für mich Gebaut. Frei nach dem Motto „eat your own dogfood„. Das hat für die IndieWeb Community ganz gut funktioniert, aber um eine breitere Masse anzusprechen, muss das Plugin verständlicher werden.

Für den Hackathon haben wir uns deshalb dazu entschieden, die Usability und die User Experience des Plugin zu beleuchten und (im besten Fall) zu verbessern.

Webmention-Settings

Die Einstellungen setzen relativ viel Kenntnisse über die Funktionsweise von Webmentions voraus. Ein Teil der Gruppe hat sich daran gemacht, die Seite zu überarbeiten und zu vereinfachen.

Das Resultat ist eine Art Wizard, der beim ersten Aufruf gestartet wird und den User Schritt für Schritt durch die Einstellungen führt und sie ausführlich erklärt. Der Wizard soll nur beim ersten Laden starten und die klassischen Einstellungen nicht ersetzen.

(Der Pull Request dazu: #328)

Die zweite Idee war Brid.gy tiefer in das Webmentions Plugin zu integrieren. Die aktuelle Diskussion dazu findet auf GitHub statt.

Response-Types

Im Gegensatz zu Trackbacks und Pingbacks, müssen Webementions nicht immer „nur“ ein simpler ping sein. Es ist auch möglich dezentrale Likes, Bookmarks, RSVPs oder Reposts zu verschicken.

Aktuell muss man dazu im Block-Editor auf die HTML Ansicht wechseln und dem Link eine CSS-Klasse hinzufügen:

<a class="u-like-of" href="http://example.com/">Example</a>Code-Sprache: HTML, XML (xml)

Das ist nicht praktikabel und in keiner Weise anwenderfreundlich. Aus diesem Grund hat eine zweite Gruppe, an einem User Interface für den Response-Type gearbeitet.

Response-Types für Links im Block Editor

Am Ende des Hackathons gab es auch einen ersten Draft, mit der man Links als Likes auszeichnen konnte. Den PR gibt es leider noch nicht, aber ich werde ihn nachreichen wenn es soweit ist.

Webmaininnat suomeksi

…ja Carolinan ansiosta Webmaininnat-laajennus on nyt saatavilla myös suomeksi! Kiitos paljon 🙂

Fazit

Es war extrem spannend mit Leuten, außerhalb der IndieWeb und (teilweise) auch außerhalb der WordPress-Community, über das IndieWeb im Allgemeinen und das Webmention Plugin im Speziellen zu sprechen.

Vielen Dank an Moritz Bappert, Stefan Euchenhofer, Marko Feldmann, Hagen Graf, Carolina Lindqvist, Jason Rouet und Jan Vogt für eure tolle Arbeit! Danke für die neue Perspektive und für euer Feedback!

Danke auch an Robert Windisch und Alain Schlesser, mit denen ich viel über das Potential von Webmentions im WordPress Core geredet habe.

Die 5.0er Version des Webmention Plugins wird großartig!

Text

· · zu lesen
Screenshot der notizBlog Seite von 2005

notiz.blog wird 16 und zur Feier des Tages habe ich meiner Blog-Beschreibung das kleine Wort „mainly“ spendiert!

a weblog mainly about the open, portable, interoperable, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social web

Kontext?

Christian Fischer hat einen sehr schönen Text, über „Tanker“ geschrieben:

An dem Tag als ich beschloss alles zuzumachen, war das jawl knappe 17 Jahre alt. In diesen 17 Jahren hatte ich befunden, diese Blogs wären vielleicht interessant, war von den ersten 50 Bloggern freundlich und allerschärftens willkommen geheißen worden, hatte so vor mich hingeschrieben, hatte plötzlich viele Leserinnen, sah die Blogosphäre wachsen, war nicht auf der Blogmich, hatte weniger Leserinnen. Schrieb allerlei wofür wir später Twitter oder Facebook bekamen, schrieb dadaistisches Zeug, über Popstars, über die Blogosphäre, Kurzgeschichten und meinen ersten Rant, und bloggte lange so vor mich hin. Davon abgesehen, dass ich natürlich keine Ahnung mehr habe, was ich da wirklich so alles getrieben habe, hatte ich vor allem das Gefühl, dass ich dabei immer ernsthafter wurde, immer wichtiger schreiben wollte – und deswegen immer seltener und seltener schrieb.

Und seit ichs hier Tagebuchbloggen nenne, darf ich so gehaltlos sein, wie ich will. Ist ja nur Alltag.

Und das ist sehr befreiend.

Judith Holofernes hat zum Ende von Wir sind Helden mal sinngemäß gesagt: Das Ding war wie ein Tanker, zu groß, zu schwer, zu unbeweglich.

Ich kann das exakt so auch sagen.

11.6.2020 – das alte und das neue Blog

Etwas Ähnliches ist leider auch hier/mir passiert!

Eigentlich war das notiz.Blog nie monothematisch geplant. Es begann mit Posts über Web2.0, X-Box, das Web, Bud Spencer, Mr. T, das Web und das A-Team und es endete mit dem „open, portable, interoperable, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social web„.

Ähnlich wie bei Christian, stelle ich mir heute viel zu oft die Frage ob eine Text-Idee thematisch zum Blog passt. Aber eigentlich gibt es so viel Themen über die ich gerne schreiben würde… über WordPress, Open Source, Haus-Automatisierung, Selbstorganisation und Action-Figuren.

Depone hat die Tage fast sein privates Blog geschlossen.

Auch interessant, dass ich seit Juli keinen Blogpost mehr in meinem privaten Blog veröffentlich habe.

Die Tage darüber nachgedacht es zu löschen.

twitter

Ich mach mir statt dessen Gedanken ob ich ein Neues brauche!?!

Mal schauen wie es hier weiter geht, jetzt wird aber erstmal gefeiert 🎉!

…vielleicht reicht ja der psychologische Effekt des kleinen Wortes „mainly“ und dicht gemacht wird auf keinen Fall 😉

Text

· · zu lesen
Screenshot von amp.dev

Google hat aktuell eine Klage am Hals. Der Konzern soll AMP genutzt haben, um sein eigenes Werbenetzwerk gegenüber der Konkurrenz zu bevorzugen.

Google soll sein Format AMP (Accelerated Mobile Pages) zur Webseiten-Beschleunigung nur eingeführt haben, um die Verleger dazu zu bewegen, letztlich mehr Geld im Google-internen Werbenetzwerk auszugeben. Das ist einer der Vorwürfe von zwölf US-Bundesstaaten, die kürzlich Klage gegen den US-Konzern eingereicht haben.

Kartellklage: Google soll AMP für Wettbewerbsvorteile eingeführt haben (heise online)

Leider ist das nur einer von vielen Kritikpunkten an AMP, toppt in meinen Augen aber alle Bisherigen um längen!

Ich möchte aber gar nicht zu sehr auf die Fälle eingehen, weil sie schon zu Genüge thematisiert wurden. Was mich dagegen triggert, ist die ständige Erwähnung von „Open Web“ im Kontext von AMP, speziell auch im WordPress Umfeld!

Screenshot von amp.dev

Sarah Gooding hat auf WP Tavern einen sehr lesenswerten Artikel zu dem AMP Skandal veröffentlicht, in dem sie auch auf die Rolle von WordPress bzw. Automattic eingeht: AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives.

In dem Abschnitt „Automattic Denies Prior Knowledge of Google Throttling Non-Amp Ads“ schreibt sie:

In 2016, Automattic, one of the most influential companies in the WordPress ecosystem, partnered with Google to promote AMP as an early adopter. WordPress.com added AMP support and Automattic built the first versions of the AMP plugin for self-hosted WordPress sites. The company has played a significant role in driving AMP adoption forward, giving it an entrance into the WordPress ecosystem.

Auf eine Nachfrage bei Automattic, bekommt sie folgende Antwort:

As part of our mission to make the web a better place, we are always testing new technologies including AMP

Auf die konkrete Frage, ob sie von der Wettbewerbsverzerrung wussten, antwortet Automattic mit:

We chose to partner with Google because we believed that we had a shared vision of advancing the open web. Additionally, we wanted to offer the benefit of the latest technology to WordPress users and publishers including AMP.

Da steht tatsächlich „we believed that we had a shared vision of advancing the open web„!

Selbst nach all der Kritik an einem proprietäres Format, einem subset von HTML5, welches die Nutzung von JavaScript limitiert, Webseiten-Betreibern aufgezwungen wurde, damit sie ihren Page-Rank behalten/verbessern, um ihnen dann die Besucher durch ein heftiges Caching der AMP Seiten abzugraben, um sich dann wohl auch noch einen Wettbewerbsvorteil im Bereich der Werbung zu sichern, sprechen Automattic und Google von „Open Web„?!?!

Warum mich das triggert?

Ich investiere jetzt knapp 15 Jahre meiner Freizeit in wirkliche „Open Web“ Plugins für WordPress, welche seit Jahren unbeachtet oder als „maybe later“ gekennzeichnet im Trac vor sich hin siechen, aber insgeheim hatte ich trotzdem die Hoffnung, dass vielleicht Google oder Automattic irgendwann Interesse zeigen könnten, wenn ihnen das Thema „Open Web“ (und WordPress) anscheinend doch so wichtig ist…

Wenn jetzt aber AMP der Maßstab für „Open Web“ ist, dann sehe ich schwarz für Webmentions oder ActivityPub.