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 🙂

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?

A list of all my WordPress Plugins

Mein erstes WordPress Plugin hab ich vor mehr als 14 Jahren veröffentlicht und über die Jahre sind eine ganze Menge, mehr oder weniger erfolgreiche, Plugins dazu gekommen… Zeit für eine Inventur 🙂

Viele der Plugins schreibe ich in erster Linie für mich selbst (eat your own dogfood), weshalb ich in den wenigesten Fällen über die Plugins spreche oder sie bewerbe. Das, in Verbindung mit meinen eher spärlichen Beschreibungen, sorgt oft für eher zweistellige, maximal dreistellige Download-Zahlen. Wo die Zahlen höher sind, habe ich das Plugin meistens von Anderen übernommen (um die Weiterentwicklung zu gewährleisten) oder ich bin einfach „nur“ Contributor.

Aber Schluss mit der falschen Bescheidenheit!

Selbst wenn ich die Plugins für mich baue, ist die Motivation natürlich größer, wenn sie auch von anderen benutzt werden. Also möchte ich euch hier ein paar meiner Plugins vorstellen.

ActivityPub

ActivityPub ist ein, vom W3C veröffentlichtes, offenes, dezentrales Protokoll für soziale Netzwerke.

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

https://www.w3.org/TR/activitypub/
Schaubild welches die Funktionsweise von ActivityPub zeigt

Es ermöglicht das dezentrale kommunizieren über Text, Bild, Video und Audio über ein simples Inbox/Outbox Prinzip.

WebFinger Plugin

WebFinger ist kein fester Bestandteil von ActivityPub, wird aber von allen großen Netzwerken unterstützt und von Mastodon sogar verlangt. WebFinger ist eine Art Meta-Data System für alle möglichen URIs. Der gängige Identifier im Fediverse ist @username@domain.tld, das Plugin erlaubt aber auch die Author URL oder die Instant-Messaging Accounts eines Users, wenn diese unter der gleichen Domain erreichbar sind.

Mein Identifier ist Beispielsweise pfefferle@notiz.blog und die Meta-Daten können über folgenden API-Endpunkt abgerufen werden: https://notiz.blog/.well-known/webfinger?resource=acct%3Apfefferle%40notiz.blog

NodeInfo Plugin

NodeInfo (2) ist auch kein fester Bestandteil von ActivityPub, wird aber auch von den Meisten Netzwerken unterstützt. NodeInfo stellt, wie der Name schon sagt, Infos über einen „Node“ (Server) bereit. Dank NodeInfo gibt es eine ganze Reihe an Statistik-Seiten wie the-federation.info, die bei der Auswahl der richtigen Plattform bzw. des richtigen Servers helfen.

ActivityPub Plugin

Das eigentliche ActivityPub Plugin macht WordPress zu einem (kleinen) Teil des Fediverse. User von Mastodon, Pleroma, Friendi.ca oder Pixelfed können dem Blog „folgen“ und sehen ab dann alle neuen Blog-Posts in ihrer Timeline und können diese kommentieren. Das Plugin ist immernoch in einem frühen Stadium und bekommt sicherlich noch das ein oder andere Feature, im Fokus soll aber das Bloggen stehen. Wer ein vollwertiges, dezentrales, soziales Netzwerk möchte, sollte sich erstmal für eine der oben genannten Plattformen entscheiden.

IndieWeb

Der IndieWeb Wapuu

Das IndieWeb ist eine Grassroots Bewegung mit dem Ziel, die eigene Webseite als zentralen Kommunikations-Hub zu nutzen.

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.

https://indieweb.org/IndieWeb

Mehr zum IndieWeb findet ihr hier oder unter dem Tag „indieweb“ hier im Blog.

IndieWeb Plugin

Das IndieWeb Plugin hat nahezu keine Funktionalität, es ist vielmehr eine Art Installer um die IndieWeb Plugins über eine zentrale Stelle verwalten zu können.

Es gibt immer wieder Kritik am Aufbau des Plugins, bzw. kommt immer wieder die Frage auf, warum das Plugin nicht einfach die komplette Funktionalität der einzelnen Plugins beinhaltet. Meine Antwort darauf: Das IndieWeb ist mehr eine Idee als eine Spezifikation und es gibt verschiedene Möglichkeiten diese Idee mit WordPress umzusetzen. Für einen Usecase gibt es also oft verschiedene Lösungen, die von verschiedenen Personen entwickelt werden. Ein IndieWeb Plugin im Stil von ActivityPub ist in meinen Augen nicht möglich. Ich lasse mich aber gerne eines besseren belehren 😉

Webmention Plugin

Webmentions sind eine moderne Alternative zu Pingbacks und Trackbacks. Im Gegensatz zu der eher unglücklichen Darstellung von Pingbacks ([...] super, wie war nochmal der kontext, oder [...]) versucht das IndieWeb (über Webmentions und Microformats), den Sinn und die Art einer Verlinkung heraus zu bekommen um die Reaktion dann als Like, Bookmark oder vollwertiges Kommentar anzuzeigen.

Das Webmention Plugin implementiert aktuell nur den Kommunikations-Teil, für das Interpretieren der Websemantiken benötigt ihr zusätzlich das „Semantic Linkbacks“ Plugin.

Mehr über Webmentions hier oder unter dem „webmention“ Tag hier im Blog.

Semantic Linkbacks Plugin

Wie oben beschrieben sorgt das Semantic Linkbacks Plugin für die hübsche Darstellung der Webmentions, Pingbacks und Trackbacks. Wir sind gerade dabei, die Funktionalität in das Webmention Plugin zu übertragen, deshalb hat das Plugin aber nur noch temporär Bedeutung.

WebSub Plugin

WebSub (formerly known as: PubSubHubbub) ist ein simples PubSub Protokoll für das Web. Es wurde ursprünglich entwickelt um updates von RSS und Atom Feeds in „echtzeit“ zu konsumieren. Push statt pull. Die Restriktion auf RSS und Atom, wurde mit der aktuellen Version aufgehoben.

WebSub provides a common mechanism for communication between publishers of any kind of Web content and their subscribers, based on HTTP web hooks. Subscription requests are relayed through hubs, which validate and verify the request. Hubs then distribute new and updated content to subscribers when it becomes available. WebSub was previously known as PubSubHubbub.

https://www.w3.org/TR/websub/

Über das WebSub Plugin (ursprünglich entwickelt von Josh Fraser) kann man die Standard-Feeds von WordPress abonnieren. Das Plugin kann aber auch über andere Plugins und Themes erweitert werden.

MF2 Feed Plugin

Das IndieWeb setzt im, Gegensatz zum Fediverse, nicht auf APIs, sondern auf Semantisches HTML:

The idea is rather than publishing something twice (repeating yourself) with (x)HTML for browsers and XML for aggregators – you simply publish once using (x)HTML and allow the tools to take care of the rest.

http://microformats.org/wiki/dry
Das Microformats Logo

In einer Welt in der jeder WordPress Theme Developer Wert auf Microformats, Schema.org oder Ähnliches achtet, funktioniert das Konzept super. Die Erfahrung zeigt aber, dass nur wenige Themes (seit fast 9 Jahren eigentlich sogar nur ein Theme) im WordPress.org Repo Microformats2 unterstützt.

Ich habe viel herum experimentiert um Themes über ein Plugin mit den nötigen Semantiken zu erweitern, was aber, durch Output Escaping, zu komischen Nebeneffekten geführt hat (das alles aber nur der Vollständigkeit halber, das Thema ist eigentlich einen ganzen Artikel wert).

Letztendlich haben wir für WordPress ein Plugin gebaut, das einen Feed bereit stellt, der genau dem JSON Format entspricht, welches auch die Microformats Parser ausspucken. Das Webmention Plugin sucht also erst den pre-parsed Feed und versucht erst im zweiten Schritt, die Seite selbst zu parsen.

Ihr versteht die Ironie? Microformats(2) sind geschaffen worden um XML/JSON APIs abzulösen und weil das bei WordPress nicht wirklich dolle funktioniert bieten wir die Infos als JSON API an! 😀

Decisions, not Options

Ich bin ein Freund von kleinen Plugins die nur einen spezifischen Anwendungsfall abdecken und im besten Fall auch vollkommen ohne Settings aus kommen. Frei nach dem Motto von WordPress:

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration.

https://wordpress.org/about/philosophy/#decisions

(Ironischerweise führt aber gerade das Fehlen von Settings oft für Verwirrung 😉 )

OpenGraph Plugin

Das Open Graph Protokoll wurde von Facebook entwickelt und hat einen ähnlichen Nutzen wie oEmbed:

The Open Graph protocol enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to allow any web page to have the same functionality as any other object on Facebook.

https://ogp.me

Es wird aktuell von fast jedem großen Netzwerk oder fast jeder Messaging App benutzt und sorgt dafür, dass ihr die kleinen hübschen Vorschausnippets seht, wenn ihr einen Link mit euren Freunden teilt.

Das OpenGraph Plugin wurde ursprünglich von Will Norris geschrieben und generiert alle notwendigen Meta-Tag Header. Keine Settings, keine Entscheidungen, aber mit wohl definierten Filtern zum erweitern.

Hum Plugin

Hum generiert schöne, semantische Short-URLs für WordPress Posts und Pages. Das Plugin ist ursprünglich auch von Will Norris, integriert sich in die WordPress Core-Funktionen und kommt auch komplett ohne Settings aus.

Hum basiert auf Whistle

Whistle is an open source, algorithmically reversible, personal URL shortener.

http://tantek.pbworks.com/w/page/21743973/Whistle

…und New Base 60

A base 60 numbering system using only ASCII numbers and letters.
or
a side effect of building a personal URL shortener

http://tantek.pbworks.com/w/page/19402946/NewBase60

…zwei Specs von Tantek Çelik.

Open Search Document Plugin

Die OpenSearch Spezifikation bietet Möglichkeiten um die lokale Blog-Suche für Browser oder Suchmaschinen zugänglich zu machen.

OpenSearch is a collection of simple formats for the sharing of search results.

https://github.com/dewitt/opensearch

Es gibt Integrationen für alle bekannten Browser wie z.B. Chrome, Safari, Firefox und Microsoft Edge.

Das Plugin wurde ursprünglich von johnnoone Entwickelt, es stellt eine XML Beschreibung der Suche und einen Endpunkt für Such-Vorschläge basierend auf Tags bereit.

Das wars auch schon 🙂

Mehr?

Natürlich gibt es noch mehr, das würde aber den Rahmen sprengen. Ich nutze WordPress gerne um neue Specs und Ideen auszuprobieren und daraus entstehen meist kleine Plugins, die es oft nicht wert sind, auf WordPress.org veröffentlichen zu werden.

Ihr könnt aber gerne:

Ihr könnt fast alle Plugins auch bequem über Composer installieren und updaten.

Ich freue mich IMMER über Hilfe, also feel free to contribute!

Torsten Landsiedel hatte 2019 die Idee zum #Projekt26:

  • Alle zwei Wochenmuss“ ein Blogartikel geschrieben werden.
  • Alle zwei Wochen „muss“ ein anderer Blogartikel kommentiert werden – das ist neu, aber wichtig, damit wir den Blog wieder als zentralen Ort für den Austausch nutzen und das nicht auf den Social Media Plattformen diverser Konzerne machen.
  • Das Thema sollte WordPress sein, angrenzende Themengebiete, wie CSS, JavaScript, etc. gehen natürlich auch. Bonuspunkte gibt es für Artikel zum Thema Gutenberg.
  • Der Hashtag lautet #projekt26 und sollte selbstredend bei der Bewerbung der Artikel genutzt werden.
  • Am liebsten sind mir echte, originäre Artikel, keine Zweiverwertungen, Listen, Linktipps, etc. – Faustformel könnte die Mindestlänge der VG Wort sein (1800 Zeichen).

Ich mag den Fokus auf WordPress, auch wenn das ja hier eher nicht mein Haupt-Thema ist. Das gibt meinem Blog aber ein wenig Abwechslung und ich schaffe es vielleicht mal über die ganzen Plugins zu schreiben, die ich in den letzten Jahren so verbrochen habe… und da wären wir ja wieder beim Thema 😉

Neben dem regelmäßigen Bloggen, mag ich aber auch den Punkt mit dem Kommentieren. Was uns in den letzten Jahren immer mehr verloren gegangen ist, woran ironischerweise die SOZIALEN Netzwerke nicht ganz unschuldig sind, ist der Diskurs direkt im Blog. (Das ist übrigens mit einer der Gründe warum ich das Webmention und ActivityPub Plugin geschrieben habe.)

Da ich in den letzten Jahren hier eher weniger aktiv war, motiviert mich die Idee der selbstauferlegte Druck hoffentlich, in diesem Jahr regelmäßiger zu schreiben.

…und dass ich diesen Artikel statt in Kalenderwoche 1 oder 2, erst jetzt schreibe, bestärkt mich nur noch mehr in dieser Ansicht!

(zum Glück kann man Artikel zurück datieren 😀 )

Ich hatte es im Januar 2019 schon einmal erwähnt: Ich arbeite gerade an einem ActivityPub Plugin für WordPress. Da ich das ganze in meiner Freizeit mache, hat das auch seine Zeit gedauert, aber gerade ist es in einem ganz stabilen Zustand… immerhin funktioniert es mit den meisten bekannten Plattformen:

Es gibt zwar immer noch ’ne Menge zu tun, aber immerhin kann man:

  • dem eigenen Blog-Profil (Author-URL) auf Mastodon & Co. folgen
  • Blog-Posts werden mit den Followern geteilt
  • Kommentare auf Mastodon & Co. landen wieder im Blog

Ihr könnt das Plugin über WordPress.org oder GitHub installieren.

Wer Ideen hat oder Hilfe braucht, findet mich (immer mal wieder) im SocialHub von ActivitPub.rocks.

Ich bin gespannt auf euer Feedback!

Meine letzten beiden Blogposts wurden glaube ich etwas falsch verstanden, deshalb hier eine kleine Richtigstellung.

Ich hatte mich sehr gefreut (als ich fälschlicherweise dachte hoffte), dass WordPress vielleicht Matrix kompatibel wird und ich hatte mich etwas geärgert, als sich dann herausstellte, dass es nie darum ging WordPress in die Matrix zu bringen.

Frank hat mir dann auf Twitter geschrieben, dass es ja auch andere Wege gibt um ans gleiche Ziel zu kommen.

Ich ne, vielleicht per Trac in den core bringen.

…und Stefan hat es dann in den Kommentaren noch etwas konkretisiert.

Genau! WordPress ist OpenSource. Was hindert uns dem Wunsch zur Vaterschaft zu verhelfen?!

Macht Sinn! WordPress ist OpenSource Software und hat eine ziemlich umfassende Plugin API…

Warum also nicht einfach selber machen?

…und genau das ist die entscheidende Frage!

Mir ging es nie darum, dass speziell Matrix in WordPress integriert wird und ich war auch nie wirklich traurig, dass es nur ein Missverständnis war. Ich bin nicht mal ein großer Fan von Matrix und es gibt eine ganze Reihe an Protokollen die ich viel liebe integriert sehen würde.

Ich hatte statt dessen gehofft, dass sich eine Firma wie Automattic für das Thema dezentrale Netze, Fediverse, IndieWeb, oder wie auch immer man es nennen will, interessieren könnte und sogar Geld in die Hand nehmen würde um WordPress zu einem Teil dieser Bewegung zu machen.

„Selber machen“ probiere ich jetzt seit DataPortability.org (also seit ungefähr 2007/2008) mit nur mäßigem Erfolg. Für ein Side-Project ist das Thema einfach zu groß und investieren will leider auch niemand so wirklich.

Naja… vielleicht zieht ja irgendwann mein geheimer Masterplan 😉

WordPress und Matrix „heiraten“ wohl doch nicht, wie ich im vorherigen Post gehofft hatte 🙁

Caspar hat mich in den Kommentaren auf einen Tweet von Matt Mullenweg hingewiesen, in dem er das nochmal klar stellt.

The same way that WP folks mix up New Vector, Modular, Riot, and Matrix, people outside our community sometimes mix up .org and .com, Automattic and WordPress. I think the intention there was to mean .com, as it would be difficult for most shared hosts to run Matrix.

Matt Mullenweg auf Twitter

Jetzt wo ich den Matrix Blogpost noch einmal lese, hätte man es auch wirklich so verstehen können, wie es Matt noch einmal betont.

[…] turns out that Automattic already runs a XMPP bridge for wordpress.com over at im.wordpress.com![…]. Imagine there was an excellent Matrix client available as a WordPress plugin for embedding realtime chat into your site?

Welcoming Automattic to Matrix!

Da war wohl der Wunsch der Vater des Gedankens.

Statt einem dezentralen WordPress bekommen wir also ein WordPress.com mit einer weiteren Chat Integration.

Woohooo!

Zumindest werden dadurch mein WordPress ActivityPub und meine IndieWeb Plugins nicht überflüssig.

Kombination von WordPress und Matrix Logo

Automattic, die Firma des WordPress Gründers Matt Mullenweg und Betreiber von WordPress.com, hat gerade indirekt das Matrix Protokoll mit 5 Millionen Dollar finanziert.

Das Matrix Protokoll wird oft in einem Atemzug mit ActivityPub genannt und scheint auch dem Fediverse zugeordnet zu werden.

Matrix is an open standard for interoperable, decentralised, real-time communication over IP. It can be used to power Instant Messaging, VoIP/WebRTC signalling, Internet of Things communication – or anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history.

https://matrix.org/faq/

Ich kenne Matrix hauptsächlich aus dem Instant Messaging Bereich, aber es gibt auch eine Server-To-Server/Federation API also gehe ich davon aus, dass sich auch dezentrale soziale Netzwerke realisieren lassen.

Das wirklich spannende ist aber nicht die Investition sondern Automattics Plan, WordPress mit Matrix zu verheiraten.

More importantly, Matt Mullenweg (co-founder of WordPress and founder of Automattic) and the Automattic gang are committing to make the most of Matrix in their work going forwards!

This is huge news, not least because WordPress literally runs over 36% of the websites on today’s web – and the potential of bringing Matrix to all those users is incredible. Imagine if every WP site automatically came with its own Matrix room or community? Imagine if all content in WP automatically was published into Matrix as well as the Web?

Welcoming Automattic to Matrix! (matrix.org)

Automattic scheint es wirklich ernst zu meinen und hat gleich auch noch eine passende Stelle ausgeschrieben:

We’re looking for a developer to bridge the two software worlds – the one of WordPress and of Matrix.org.

Sollte WordPress wirklich Matrix kompatibel werden, wäre das wegweisend und würde das Thema dezentrale Netzwerke wirklich voran bringen, bzw. es könnte der finale Durchbruch sein.

Ich bin wirklich ein bisschen aufgeregt, auch wenn ich mit ActivityPub dann wohl aufs falsche Pferd gesetzt zu haben… In diesem Fall wäre mir das aber echt egal!

(Ich schreib dann mal meine Bewerbung 😉 )