My FOSDEM 2024 Talk: Migrating the WordPress Community from Slack to Matrix

When I submitted my application for a talk at FOSDEM 2024, we were still on for migrating the WordPress community to Matrix.

Alas, there were many factors that led us to pause the transition indefinitely, announced by Matt at the Q&A of State of the Word 2023. The most important factors were accessibility problems, some important feature-imparity compared with Slack, and the license changes at Element (to AGPL, with the requirement to sign a CLA when contributing).

The WordPress community has collected their issues in a Github repository. We tried hard to overcome the issues, through documentation, education (some things just work differently in a federated environment), and upstream patches (for example to address some of the accessibility problems).

In the end, I did not cancel but held my talk on February 4 at FOSDEM 2024 in Brussels, explaining all the things we did to lower the barrier of entry:

As well as bots and integration we created to fulfill the specific needs, such as these Maubot plugins:

  • Post to room: post messages via webhook
  • Relay: an integration can react to room messages via webhook
  • Group mentions: upon command a bot mentions many people
  • Watchdog: alert about community created rooms

Also, we held weekly meetings in the WordPress meta chat throughout the year, and published meeting notes afterwards.

There is a lot more in my presentation, I hope that my presentation slides can be helpful to other communities (or companies) trying to migrate from Slack to Matrix. Maybe some things that were a blocker for the WordPress community are not so important for other communities.

Finally, here is the video of the ~30 minutes presentation:

FOSDEM 2024 talk by Alex Kirk: Embracing Matrix for Enhanced Communication: Migrating the WordPress Community from Slack to Matrix

Kudos to my colleagues Paulo Pinto and Ashish Kumar who did a lot of the heavy lifting in the effort. Together we submitted around 40 upstream pull requests (on Synapse (pre-license change), Element-Web, Slack bridge, and more).

Mastodon API Tester

tldr: Use the Mastodon API Tester to play with the Client API of Mastodon.

I’ve created the WordPress plugin called Enable Mastodon Apps which does a seemingly small but powerful thing: it enables you to access your WordPress blog using Mastodon apps like Tusky or Ivory. This can be used to browse your own blog and post to it. If you also have the Friends plugin and the ActivityPub plugin installed, this will actually make your WordPress blog behave like a Mastodon instance.

It does this be re-implementing the Mastodon API (unfortunately, Mastodon didn’t opt to implement the ActivityPub client-server API so this is not based on a standard) which can be tricky: it uses REST API endpoints in the (virtual) directories /oauth and /api which are so generic that they are prone to conflicts.

Additionally, although the API is well documented, many apps were created based on assumptions that are true for Mastodon itself (which caused a lot–sometimes hard to reproduce–of issues for the plugin). For example, the id of a post or a user is defined as a string but many apps crash when you put a non-number there. Or that a boosted toot needs to have a different id than the virtual “wrapping” toot (Ivory!). In such cases, apps would crash but work fine with Mastodon itself.

Even more complicated are interactions with other WordPress plugins. It can be hard to understand if the plugin is working correctly, if another plugin is interfering, the hosting provider acts quirky, or if the Mastodon app has an incompatibilty with my implementation.

Thus I have created a simple one-page JS app called Mastodon API Tester hosted on Github pages (source on Github):

I hope that this tool will help identify issues better in future, it can also be used with GotoSocial or a “real” Mastodon instance. Feel free to report issues you might encounter.

PS: the Enable Mastodon Apps plugin will be worked on at the Cloudfest Hackathon, thanks Matthias Pfefferle for taking the lead on this! (Unfortunately, I cannot make it there because I’ll be speaking at WordCamp Asia in Taipei just the weekend before that.)

PPS: Happy Birthday, Matt!

Prototype: Create a Website from a Screenshot and Refine It, All in the Browser

I’ve been working on this experiment, combining OpenAI’s gpt-4-vision-preview with WordPress Playground to create a website based on a screenshot.

This follows on the heels of Matt Mullenweg’s announcement at the 2023 State of the Word that in 2024, the WordPress project wants to work on Data Liberation.

While the typical approach to migrating data is to build importers for specific services, a truely universal migration could happen through screenshots. With AI vision this might now be in reach.

So I built this prototype that combines a OpenAI-powered chat interface with WordPress Playground. First a screenshot, a screen recording further down.

So this is only a start. The website somewhat resembles the screenshot but it’s far from being pixel perfect.

My idea is that you’ll work together with the assistant in refining the site. It can help you update, you can ask it questions. An import is rarely perfect from the start but you can see and test the result right away in the browser and refine it.

I imagine that when done, you can then transfer the site to a web hoster who from then on can host your website for everyone.

You can try this yourself here, you “just” need an OpenAI API key that will be stored in your local storage: https://akirk.github.io/website-liberator/

Source (very unpolished) at https://github.com/akirk/website-liberator/

Some notes on this first implementation:

  • Every message is a new conversation. Modifying a website can be token intense, so for now it cannot refer to previous messages.
  • It’s using function calling to allow OpenAI to gather more information to fulfil the request.
  • Chosing the right functions to provide can be tricky.
  • It uses different models depending on the task. gpt4-vision-preview for the screenshot, gpt-3.5-turbo for the rest. I need to experiment more with gpt-4 for the latter tasks.

Finally, a screen recording of an early iteration, I have since moved the chat to the right side.

As I’ve been working on the prototype, it has shown to be interesting to have the bot be there just for customizing sites, it can create and modify pages, update settings of the website. Maybe install plugins.

So starting with a basis from screenshots and imported data, it might just be able to assist you to arrive at a comparable WordPress website, and all with the ease and effortless setup of WordPress Playground. I wonder where we can take this!

Bonus

Some screenshots from a recent version:

Keeping Family History with WordPress

One thing that I like very much about my family is the anecdotes and stories. One thing that I am bad at, is reciting them.

So I had this idea to create something like a private Wikipedia for my family, where each person has their own page and family members can contribute to the stories, biographical data, and media.

Initially, I set up a MediaWiki, i.e. the same software that Wikipedia uses. It turns out, it’s not that easy to configure. The new Wiki editor is much better than directly editing wiki syntax but the complexity is high for a small project like that. Also, uploading media is quite a pain because of the importance of licensing metadata. In a private wiki, you’ll want the UI to get out of the way.

So, since I work with WordPress a lot, I had the idea to use WordPress for it. There are a number of wiki plugins for WordPress but they all seemed overly complex and not really geared towards a use case of users collaborating on creating a site.

Thus, I created my own WordPress plugin called Family Wiki, available for now at https://github.com/akirk/family-wiki/

WordPress has the advantage that you can set it up very quickly and got many options for setting it up. Plus, when you have already multiple blogs (e.g. for family members) on your domain, it’s easy to just add another blog to your WordPress multisite. The plugin works on a standalone blog, too.

Here are some screenshots that I made as a demo:

A homepage showing a missing wiki page.
A person page with a missing wiki page
Gutenberg view of a person page with the shortcodes
A 404 page exposing the “Create Page” link in the header
A person page with external links
A calendar page
Inserting a birthday calendar block

Old News but still true as ever: Facebook and Instagram are harming the Open Web

A big motivation for building the Friends Plugin is to be able to follow what my friends and family are up to. Probably the most important “follow technology” is good old RSS.

While mostly used for public posts, there are many examples of how it can deliver posts not meant for the public: the solution are individual RSS feeds per subscriber, for example paid podcasts, or like the Friends plugin gives specific feeds to friends that can contain private posts.

Now reality is that (no longer) every platform has RSS feeds. It’d be easier if they just provided themt but alas. There are plugins for the Friends plugin itself that make use of projects that have built custom parsers for specific services: Fraidyscrape and RSS Bridge.

Now unfortunately, a lot of friends and family post to Facebook or Instagram. It’s just impossible to follow these friends outside of the platforms.

  • They don’t provide (authenticated) RSS feeds. That would solve all of this.
  • They rate limit and quickly block IPs (especially Instagram) that try to read a few posts unauthenticated.
  • It’s unintuitive, developer centric and needs approval to get an API key, so it’s not something every user of the plugin can be asked.
  • Their HTML is scrambled with random class names, preventing any classic scraping.

So in the end, the content of my friends and family is locked in. It would be a solution for them to create their own blog (IndieWeb style) and share their content that way. But I am realistic enough to understand that the hurdles are great. They are already connected to their friends inside Facebook or Instagram. They get lots of likes and responses there. They are used to the UI and the apps. It’s just not good for anyone who doesn’t want to join the Facebook ecosystem and be exposed to their ads.

We’re all using RSS Readers all the time…

… we just don’t realize it. If you think about it, most of the social network services are specialized RSS Readers that combine consuming with creating. (Just to be clear, these social networks don’t provide RSS feeds, what I’m saying is that what they do could be done with RSS feeds.)

Take Facebook, for example:

  • If you follow someone, you’re subscribing to their RSS feed.
  • If you like a page, you’re subscribing to their RSS feed.
  • If you become friends someone, you’re subscribing to their RSS feed and vice versa.
  • If you view your timeline, you’re looking at all posts by your subscriptions (usually modified/filtered by Facebook).
  • If you post something, it’s added to your RSS feed and the people who are subscribed to you (via follow or friendship) get your post in their feed.

Twitter is similar, they just limit the post format to “status”. Instagram limits the post format to “image”. Tiktok to “video”.

The problem that I see with this is that this happens in a centralized manner. With RSS readers, we already have the decentralized version of this technology. The benefit of social networks is that they solve a few problems well:

  • Easily reachable and searchable user base (= audience).
  • Easy account creation (just sign up here).
  • They combine consuming with creation.

I see a possible solution in WordPress. There are many options to get WordPress hosting with your own domain. With the Friends Plugin you can then combine consuming and creating. The Friends plugin allows you to consume the web your way, WordPress is a well established way of creating content.

By using post formats, you can also create different types of content and consume the same kind of incoming content combined. See the screenshots above, showing the main, combined feed, an image feed and a status feed.

Also, commenting on posts is built in to WordPress. With a friendship based approach you can even open up comments just to friends, which can reduce the usual “spam problem.”

What’s still missing for is the convenience of single-purpose apps. The cool thing is that these apps would talk to your own server which handles retrieving of followed content vs. this being relayed to a third party (who then knows the follow patterns of everyone on their platform). With Sunlit, micro.blog has implemented something like this for photo sharing inside their micro.blog platform but I believe this could be done for “RSS” as well.

The Indieweb movement follows very similar ideas to what I described above. The concept of webmentions allows you to respond to a post by posting to your own server, sending a ping to the original article. While the WordPress + Friends approach might be a bit more integrated, I see webmentions as a reasonable bridge between the worlds.

All in all, I believe having a personal blog is good for the health of internet. It’s unfortunate that in their history, personal blogs have this huge focus on “being public.” I believe it is equally well suited to be a place for more private communication, and especially a place where you can consume the web the way you like.

Using Jetpack Blocks without a connection to WordPress.com

Recently I wanted to use a Jetpack block for the WordPress Gutenberg editor, specifically the Slideshow Block, which I think is very slim and elegant compared to other Slideshow blocks on the WordPress.org plugin directory.

The one thing I didn’t want to do, though, is to connect my site to WordPress.com. For the most part because I didn’t intend to use any of the functionality that requires the WordPress.com connection.

The difficulty in this: normally, you can’t actually use Jetpack until you connect the site to your WordPress.com account. This behavior is in place so you can enjoy a friction-less experience after the connection is established (i.e. you can activate any of its features whether or not it needs the connection).

In my case, the connection is not needed for using the Slideshow block since it works with the local media library.

So, I present not a hack but an official way to use Jetpack without a WordPress.com connection: it’s called Offline Mode.

You activate it by adding a constant or filter to your wp-config.php, for example:

define( 'JETPACK_DEV_DEBUG', true );

While it is intended for local installs and actually development, it is useful if you just want to use a single feature of Jetpack that doesn’t require the connection.

Many people say that Jetpack is slow because it’s so big. It is indeed huge from a file size and feature perspective, but also it’s very optimized, so that it will only load the PHP or JS code it needs. The other files lay dormant in your file system and don’t contribute to the loading or rendering time of your site.