Webmentions are a great thing. They allow us to connect our blogs. The principle is quite simple:

If I mention another site in my blog post, I automatically send a message to a predefined URL of the mentioned blog when I publish that post. In it, I share both my post URL and the post URL of the recipient site. The recipient can continue working with this information.

If the recipient supports Webmentions, they respond to the message by checking whether the post I mentioned actually exists on their blog and then look at the URL of my post to retrieve the information they need to display my mention as a comment under their blog post.

What information they need and whether and how they display my mention is up to them. I've described in detail how this works here.

Depending on what you use to run your website, you may have to build this functionality yourself. And while it's not rocket science in itself, it's unfortunately not trivial, and in some cases, it's not even technically possible.

We, as site operators with integrated Webmentions, can help bloggers without them. It's quite simple, in fact!

Instead of assuming that all sites can automatically send a Webmention, we simply offer them the opportunity to inform us via a form. The principle is similar, except that if Blogger B sends us a URL from their site, they can copy their post URL into an input field and submit it.

We then receive two URLs: Blogger B's and our blog post's.

A simple form is sufficient:

<form method="POST" action="/webmention/ENDPOINT">
<input type="url" name="source" id="source" placeholder="https://your.blog/post" required>
<input type="hidden" name="target" value="<?= $page->url(); ?>">
<input type="submit" value="webmention">
</form>

As you can see, we send the form to the Webmention endpoint we already have. We have two fields: a URL field where Blogger B copies her post URL and a hidden field containing our post URL.

We simply send the form to the same endpoint where automatic Webmentions are sent. And so the regular process can continue.

To be able to read the necessary information accurately, blogs should label their data. This is easy to do with Microformats and works completely independently of Webmentions. This allows us to specify the title, the summary, and the author.

If your Kirby website doesn't yet support Webmentions, check out my IndieConnector, which will do the heavy lifting for you.

In the old days™️, comments could be found on pretty much every blog. Most blog systems included them, or they could be quickly added using plugins. For me, comments belong on every blog.

Today, that's not necessarily the norm anymore. This isn't just for technical reasons. While blogging often involves WordPress, it's no longer standard practice. There are many systems out there, and there are many blogs that no longer have a CMS running in the background. Static pages are generated from text sources.

In such setups, it's not always easy to integrate comments. When I switched my site to Kirby about ten years ago, there was no comment plugin for the CMS. Kirby wasn't centrally designed for blogging, like other systems were.

So I tried Disqus and other comment services for a long time. But they were always a thorn in my side, which is why, now equipped with sufficient knowledge about Kirby, I wrote my own comment plugin.

Comments are also difficult because they naturally require a certain amount of effort. In the past few weeks, my desktop widget has repeatedly shown me new comments, and most of them were spam. Despite the filters. This, of course, diminishes the enjoyment.

For many bloggers, this is also the main reason for not offering comments. Furthermore, we unfortunately now have a culture of hate – "culture" – on the internet that also spreads to the comments on our blogs. From my own experience, I can fortunately say that this type of comment is far less common than on the major platforms, but one shouldn't paint the devil on the wall.

I read a lot of blogs, and I keep coming across new ones that I like, and where I often feel the urge to leave a comment. Because I particularly liked a post, because I received a helpful tip, or because I think I need to add something.

Often, scrolling to the bottom of the page takes you directly to the footer. No comment form? I find that a real shame. Some bloggers then offer an email link or refer to social media for feedback. But I have to be honest: I rarely do that. The email option is actually a no-go for me. I try to avoid emails as much as possible. And I don't even open my email program just to leave a quick comment.

Some blogs support webmentions. In those cases, I like to create a note on my page and send a webmention, which then appears under the blog post. I like that. Sometimes I even respond on Mastodon if I'm really desperate.

I (often) see blog posts as conversation starters. At least, I hope mine are. An opportunity to talk to each other. That's what comments are for me.

For some time now, I've been experimenting with my comments here locally in my development environment. I'd like to design them so that they integrate more naturally into the site, so that they're quickly accessible and almost trigger a reflex to quickly write something.

That's not easy. I've rejected all the ideas so far, but I've been carrying a few new ones around with me for a few days.

I don't want to convert anyone here, but I would appreciate more comment functions on other blogs – or the option to send webmentions. Whether it's worth the effort is something every blogger has to decide for themselves, of course.

In any case, I'm happy about every comment on my blog. Well, I can do without the spam, and I don't need to be harassed either.

I don't usually end here with a YouTube-style "Leave a comment," but it's fitting for this post. So leave a comment and tell me if you've enabled comments on your own blog, and why and how it's been received.

And leave a like and subscribe and click the bell and all that.

Well, first of all, it should be noted that the Blog Weeks are essentially also a kind of blog parade, and the number of participants recently suggests that such activities are still quite popular.

I also keep stumbling across blog memes (“blog sticks”) when browsing through the blogs I subscribe to. Usually, these involve a handful of questions that one person answers and then nominates others to do the same.

Both ideas foster networking: they help discover new blogs and get to know the people behind them a bit better. Of course, people are happy to take part. On the one hand, topics are practically handed to you, and on the other, such activities always promise new readers.

I consider the networking of blogs important and a good counterbalance to the big platforms. Trackbacks once played a major role but are not as relevant today. They’ve mostly been replaced and now only exist as a fallback when the more modern Webmentions don’t work.

I’m a developer myself of a plugin for Webmentions, so I still consider them relevant. They’re a simple way for blogs to talk to each other and exchange ideas without going through social media.

Tradition or Renaissance?

To this either-or question, my answer is a very clear yes and no! They never really disappeared, but the blogosphere was small and not very active for a long time compared to back in the day™️ and now. As a result, you simply noticed them less.

Today, there’s a more active scene again and therefore more attention for such activities.

In my opinion, the question itself is unnecessary. It doesn’t matter why these activities exist today, as long as people enjoy them and we all get to discover a few new bloggers.

I always like keeping an eye out for such activities. I must admit I rarely participate, and the Blog Weeks are a big exception here. Most topics don’t fit for me or are a bit too meta. I’ve never been tagged with a blog stick myself, so I can’t really speak from experience, but I do enjoy reading them when others publish one.

In any case, I think it’s a good thing that “the scene” is becoming more active again and that there are many different initiatives. It’s especially interesting to see how differently people approach the same topic—surely with this one too. I’m curious.

Don’t worry. Webmentions aren’t that complicated!

The Setting

Let’s imagine there are two bloggers in the world. Of course, they read each other’s blogs.

One day, Blogger A writes a post about quantum mechanics. Blogger B reads the post and wants to add something. Too much for just a comment, she thinks, and instead writes her own blog post. In that post, she links to Blogger A’s article.

Both blogs support Webmentions, so Blogger B’s follow-up post is automatically linked under Blogger A’s post once it’s published. Magic ✨

The Basic Principle

Sorry to burst your bubble, but there’s no magic here. Nor are there entangled quantum particles involved—just three URL requests.

As soon as Blogger B publishes her post, her Content Management System (CMS) scans the text. It collects all URLs from the post and finds the one pointing to Blogger A’s article.

The CMS takes that URL and requests it. It looks for a specific piece of information hidden in the page’s header—not visible on the site itself. Inside the header, there’s another URL: the so-called Webmention endpoint.

This endpoint is like a communication interface for Webmentions. You can send certain data there, and the endpoint processes it. It might look like this:

<link rel="webmention" href="https://maurice-renck.de/indieconnector/webmention">

That’s the endpoint on my website. If you check the source code, you’ll find it there.

With this HTML tag, I declare where Webmentions should be sent if someone wants to send me one.

So, Blogger B’s CMS calls Blogger A’s page, finds this information, and retrieves the Webmention endpoint URL. Then it calls that endpoint.

This request contains two pieces of information the endpoint needs in order to work:

1. A source URL (the blog post from Blogger B)
2. A target URL (the blog post from Blogger A)

With the source URL, Blogger B says: “I published something at this URL, and I mentioned you there.”

With the target URL, Blogger B says: “Here’s the post of yours that I mentioned.”

Blogger A now has all the necessary information, and her CMS can do whatever it wants with it—for example, simply show under her post that the source URL mentioned it.

A Bit More Context

Of course, it would be nicer if not just a link showed up, but some additional information: Blogger A might want to display the post’s title, the author, or even a short excerpt.

For that, a third URL request is needed.

Let’s recap: Blogger B just called Blogger A’s Webmention endpoint and sent info about her post.

Now Blogger A’s CMS takes that source URL and requests it. It scans the blog post for useful details—like the title, author, and other metadata—just as if we were loading the page in a browser.

Once found, these details are stored alongside the source URL and can then be displayed under Blogger A’s article.

In Short

That completes the communication. Let’s summarize the three requests:

1. Blog B asks Blog A: “Where should I send my Webmention?”
2. Blog B sends Blog A two URLs: the source and the target
3. Blog A visits the source and fetches the information it wants to show

Not so complicated, right?
When I first started looking into this, this simple sequence was what tripped me up: “It can’t really be that easy?” But essentially, it is.

A Bit More Complicated?

Of course, things aren’t always that simple. There are edge cases, which is why it’s usually a good idea to use an existing plugin rather than building everything from scratch.

For example, a site might send an update. Maybe something in the text or title changed. Blogger B’s CMS would then notify Blogger A of these changes—again by sending both URLs. Blogger A’s CMS has to detect that this is an update and decide how to handle it.

Or Blogger B might decide to delete the post altogether. The CMS deletes the page and, as a final action, sends another Webmention to Blogger A. Ideally, Blogger A’s CMS then checks the source URL, finds that the page is gone, and removes the reference from her own site.

Providing Information

Fetching the title of a blog post might still be straightforward. But what about the author’s name, the publication date, or even an excerpt of the text?

Every website is structured differently. The HTML varies, and the needed information won’t always be in the same place. Blogger B’s CMS wouldn’t know what’s what. If it relied on a fixed pattern, it might work on Blogger A’s site but not on Blogger C’s.

That’s why we should use microformats on our sites. These are specific class names that follow a structure. By assigning one of these classes, we can, for example, make it clear: “This is the author of the post.”

We can even go further and add classes to describe the type of Webmention: is it a mention, a like, a bookmark? There are special class names for all of that.

But here’s the catch: just because we provide this information doesn’t mean the recipient will actually read it.

Microformats are a big topic on their own, and I’ve written about them here.

Implementation

I hope it’s clear by now that Webmentions aren’t all that complicated. If you want to implement them yourself, you just need to make sure those three requests work smoothly, that the received data is stored somewhere, and that it’s displayed.

Because of possible tricky edge cases, I recommend using a plugin if your CMS has one available. I wrote one for Kirby, the IndieConnector.

If you’d like, you can test your Webmention by linking to this very post.

The IndieWeb is a people-focused alternative to the “corporate web”.

The principles:

Your content is yours

When you post something on the web, it should belong to you, not a corporation. Too many companies have gone out of business and lost all of their users’ data. By joining the IndieWeb, your content stays yours and in your control.

You are better connected

Your articles and status messages can be distributed to any platform, not just one, allowing you to engage with everyone. Replies and likes on other services can come back to your site so they’re all in one place.

You are in control

You can post anything you want, in any format you want, with no one monitoring you. In addition, you share simple readable links such as example.com/ideas. These links are permanent and will always work.

(Quelle: https://indieweb.org/)

The content of this page is available under a CC0 public domain dedication unless otherwise noted.

Anyone who uses Webmentions and wants to display them under their own posts relies on such data. Certain automations can also be refined by marking information that they otherwise wouldn’t be able to access.

Enriching Data

There are different ways to enrich our websites with data or make existing data more readable. For example, JSON-LD is hidden in the source code of a page and is often used by search engines.

Microformats are another, and particularly simple, method to make data more machine-readable.

These microformats appear as class names in HTML code and are therefore especially easy to integrate into existing pages. To mark a piece of information as a summary, we can add the following class to the HTML tag:

<p class="p-summary">This is a summary</p>

Structure and Hierarchy

In practice, things aren’t quite as simple as described above, since different class names can be used in different contexts. By themselves, they are not always unambiguous.

Let’s take the class p-name, which can be used in two different contexts:

<p class="h-card">
  <span class="p-name">Anna Blogs</span>
</p>

<article class="h-entry">
  <h1 class="p-name">The title of my blog post</h1>
</article>

In the first example, p-name indicates the name of the author. In the second, the same class indicates the name, or better, the title of the page.

So the context we define with h-card and h-entry is important, and hopefully makes clear why we need some structure to ensure that data can be read correctly.

Class Types

The previous examples already show that there are different types of class names. Class names for the name and summary start with p-, while the other two start with h-.

The term p-summary has nothing to do with the fact that it’s inside a <p> tag. Rather, these prefixes help us see (and parse) more quickly what type of information is being described.

There are five types in total:

1. h- types are at the top of the hierarchy and define what all subordinate class names belong to.
2. p- types mark plain text. Everything in the designated tag can be taken as text.
3. u- types mark a URL.
4. dt- types mark a date or time (date time).
5. e- types mark elements that themselves contain a hierarchy, where the entire hierarchy represents the content.

Some HTML tags can also contain a combination of these types. Let’s take the author’s name from the previous example and make it a link:

<a class="p-name u-url" href="https://example.org">Anna Blogs</a>

Here we’re saying that the tag contains both plain text (the name) and a URL.

Most parsers are clever enough to handle all possible combinations. For example, we could also declare the URL property like this:

<p class="u-url">https://example.org</p>

That’s syntactically questionable, but it’s possible in microformats.

Listing all possible classes here would go too far, but you can find them here:

microformats2 - Microformats Wiki

Examples

Instead, let’s look at some examples that most of us could directly integrate into our own websites.

Author Information

In the first example, we’ll mark ourselves as the author. We’ll start small and add more information step by step.

The smallest version contains only the author’s name:

<span class="h-card">Anna Blogs</span>

As you can see, this example contains only the type h-card, which can be used for people or organizations. Parsers are instructed to interpret the given information as plain text. So it corresponds to:

<div class="h-card">
    <p class="p-name">Anna Blogs</p>
</div>

In both cases, a program reading the page would interpret the following structure:

{
  "type": ["h-card"],
  "properties": {
    "name": ["Anna Blogs"]
  }
}

In the detailed version, we marked this explicitly. In the short version, the interpreter knows from h-card that the information refers to a person or organization and assumes that at least the name is included.

Interpreters should even be smart enough to handle this correctly:

<a class="h-card" href="http://example.com">Anna Blogs</a>

Here again it’s clear that this is a person or organization, and at least the name will be available. Since it’s also an anchor tag, a URL is included as well:

{
  "type": ["h-card"],
  "properties": {
    "name": ["Anna Blogs"],
    "url": ["http://example.com"]
  }
}

If we want to make this explicit, it would look like this:

<div class="h-card">
    <a class="p-name u-url" href="http://example.com">Anna Blogs</a>
</div>

The result is the same, but there’s no room for misinterpretation. If you want to be sure everything is read correctly, it’s best to be as detailed as possible.

Now let’s add the author’s photo and a way to contact her:

<div class="h-card">
    <a class="p-name u-url" href="https://example.org">Anna Blogs</a>
    <img class="u-photo" src="https://example.org/photo.png" alt="Anna’s Avatar" />
    <a class="u-email" href="mailto:anna.blogs@example.com">anna.blogs@example.com</a>,
</div>

We enriched our h-card with four different data points:

1. The author’s name with p-name
2. A link to her with u-url
3. Her avatar with u-photo
4. Her email with u-email

This again shows the different property types. The name, prefixed with p-, is plain text, while the others, prefixed with u-, are URLs.

We could add many more, such as birthday, gender, or job title. You can find all of these options here.

Blog Posts

In the next example, we want to mark up a blog post so that other sites can find all the key information. This is especially useful when we send Webmentions.

<article class="h-entry">
    <h1 class="p-name">Hello World</h1>
    <p class="p-summary">This is my first post.</p>
    <p class="e-content">This is the <strong>full</strong> text of my blog post.</p>
    <a class="u-url" href="https://example.org/hello-world">Permalink</a>
    <time class="dt-published" datetime="2025-08-22 09:00:00">08/22/2025</time>
</article>

Our main type here is h-entry, which is used for blog posts, notes, and similar content.

Within h-entry, we see already known properties:

• p-name marks the title of the post
• p-summary marks the summary
• e-content means everything inside is the full content
• u-url marks the post’s URL
• dt-published marks the publication date

Of course, we could structure it differently. The permalink could be part of the title:

<h1 class="p-name"><a class="u-url" href="https://example.org/hello-world">Hello World</a></h1>

We’re not tied to a fixed HTML structure. As long as the information is clearly marked and the hierarchy is correct, everything works.

One more word about e-content: in the example it only contains one sentence, but that’s not required. We should never use multiple p tags each with e-content. Instead, e-content assumes that everything inside the tag belongs to the content:

<div class="e-content">
    <p>This is the <strong>full</strong> text of my blog post</p>
    <p>It can have multiple paragraphs</p>
</div>

Webmentions

Before wrapping up, let’s briefly look at how to refine our Webmentions.

We can categorize Webmentions into different types, which is especially useful for short notes.

Suppose Anna has a “Notes” section where she posts different types of short entries:

• Short texts
• Replies to blog posts by other authors
• Bookmarks
• Likes

If Anna sends a Webmention without further specifying it, all of these posts are interpreted as replies to the linked post. But she can refine this with microformats.

Let’s say Anna reacts to various posts by Maria. These reactions are sent as Webmentions, since both sites support them.

To define the type of Webmention, she can add a microformat class to the link.

For a short reply to a blog post, Anna adds u-in-reply-to:

<a class="u-in-reply-to" href="https://marias.blog/post">https://marias.blog/post</a>

Now it’s clear that Anna replied to Maria’s post. Maria could then display this reply as a comment under her post.

If Anna only posted the URL as a bookmark, without a comment, she can use u-bookmark-of:

<a class="u-bookmark-of" href="https://marias.blog/post">https://marias.blog/post</a>

So the distinctions are clear. The possibilities include:

• u-like-of for a like
• u-bookmark-of for a bookmark
• u-in-reply-to for a reply
• u-repost-of to share a link

In all cases, however, it’s up to Maria whether she interprets this information correctly and displays it differently.

If you’re using a CMS and a suitable plugin, chances are good it will handle these distinctions automatically. My IndieConnector plugin does this, for example.

Combining

Finally, it’s worth mentioning that all of this information can be combined. A blog post will not only contain the information within h-entry, but likely also an h-card with author details. Blogs linked in the post could also be marked as likes or bookmarks.

There are many more types for events, products, invitations, geo data, reviews, and more. You can find all of them here:

microformats2 - Microformats Wiki

Of course, the topic isn’t entirely trivial, but it’s not as complicated as it might seem at first glance. Hopefully this has given you a good overview.

I consider marking up this kind of information important if we want to better interconnect our blogs and websites and free ourselves from large platforms.

Good luck implementing it!

A problem we repeatedly face at Sociabli is user handles on different platforms.

If you offer a service that allows you to post something on Mastodon and then mirror that post on another network, you inevitably run into the problem of user handles.

If I mention a user on Mastodon, the mention no longer works when mirroring on Bluesky. Even if the user has an account on both networks, the format of the user handles is different.

We've spent a long time thinking about how to solve this, and we always end up with some kind of user handle mapping.

The idea is to offer a service where you can log in with your social media accounts and link them together. We only store the respective handles. So we know that the user @mauricerenck@mastodon.online belongs to bsky.social/@mauricerenck.

When we crosspost with Sociabli, we can exchange these user handles. So, if I post something on Mastodon and mention @markschmeiser@mastodon.social, we convert this mention on Bluesky to @mark-schmeiser.bsky.social. This way, the user is mentioned on both networks.

Of course, this assumes that we have this data and that as many people as possible link their handles. Therefore, we believe that we shouldn't integrate this feature directly into Sociabli, but rather offer it as a separate service. Similar to Gravatar, which was originally very closely tied to WordPress but is now used everywhere. In addition to the ability to link your own accounts, we could also offer an API that allows you to read these linked accounts.

This way, with Sociabli, we're not the only ones who benefit from this data; everyone can access it. The big challenge here will likely be keeping the API stable and somehow restricting access so it doesn't result in a major DDoS attack. So, there have to be limits, and they also have to be affordable.

Before we start development, we need to double-check whether we might have simply overlooked such a service. There are so many services out there. So if anyone knows of something that meets these requirements, I would appreciate a comment. Otherwise, we'll probably get started on it soon, and I'll certainly report on the development here from time to time.

Update

After I wrote this blog post, this one came in via email: https://blog.anew.social/bridging-identity-with-account-links/ There are already efforts to create a standard. That's a great idea. I'm not sure yet if it's intuitive enough for users, but I'll keep an eye on it and see what we can do with it.

Features

• It is now possible to configure a tag field whose content is appended to the Mastodon/Bluesky post in the form of hashtags.
• It is now possible to define a field for alt tags, whose content is then specified as the alt tag in Mastodon/Bluesky.

Fixes

• Tags are now correctly recognized and displayed as such on Bluesky.
• Mastodon post texts are no longer cut off too early

Release v2.11.0 · mauricerenck/indieConnector

2.11.0 (2025-08-11) Bug Fixes bluesky detect hashtags #28 (90625bb) mastodon text length option not considered (c6d8e9f) Features include alt text when posting images (63e6510), closes #29 use ...

So if you're interested in tips and tricks for Mastodon and Bluesky, check it out. It's still very minimalistic; this is the first time I've implemented a blog with 11ty, and we're slowly getting to grips with it. Unfortunately, there's no RSS feed or anything like that yet, but that's coming. Of course, you can follow us on Mastodon and Bluesky to be informed about new posts, and I'll certainly link to some of them.

Today we're going live with a general post explaining why we started Sociabli in the first place. Next week, we'll continue with the first Mastodon tips.

Why we started Sociabli

Sociabli was created to solve a simple problem: easily sharing content across social media. Starting with a single Mastodon post, we’re building a seamless workflow for creators like you.

Response-Collector

Under certain circumstances, the Response Collector was unable to store which responses it had already processed. This was due to Mastodon IDs being set as unique in the database. However, identical IDs could occur across different instances.

This release includes a corresponding database adjustment.

Kirby 5

Darkmode

The panel view is now better adapted to the new Dark Mode. Contrast has been increased and everything should therefore be more readable.

POSSE

In addition to automatic posting to Mastodon and Bluesky, there is also a panel button that can be added. This button opens a dialog for manual posting, where settings can be made and selected where to post. If the configured source field for the Mastodon text has already been filled in on the page, this text will be used as a template here.

If a post has already been sent, this service is no longer available. Instead, you can directly open the corresponding post from the panel.

IndieConnector continues to post automatically when publishing a page. This will detect if you already posted to a service manually. To disable automatic posting altogether, you can deactivate this configuration:

'mauricerenck.indieConnector.post.automatically' => false

The panel button can be added to a page blueprint like this:

buttons:
    icShare: true

With setting the button, the standard buttons must also be added, more about this here: https://getkirby.com/releases/5/view-buttons

Sending Webmentions

Sending Webmentions still happens automatically with page updates, but it can now also be triggered via a panel button. In addition, there now is the option to no longer send them automatically, but only by clicking:

'mauricerenck.indieConnector.send.automatically' => false

The panel button can be added to a page blueprint like this:

buttons:
    icWebmentions: true

Plans for the upcoming release.

New Features:

1. Response-Collector
2. Multi-Image-Posts
3. Skip URLs

Response-Collector

This feature has been on my list for a long time and gained a sense of urgency due to difficulties with the brid.gy integration.

The Response-Collector collects responses to linked Mastodon and Bluesky posts and treats them as Webmentions. This way, you can show responses to your Mastodon and Bluesky posts as comments, likes, etc., on your pages.

The Response-Collector requires a SQLite database.

You can collect responses in two ways:

1. Cronjob
2. Panel

Cronjob

Two new webhook URLs are available that can be called to, firstly, write new responses to the queue and then process that queue. You can configure how frequently URLs should be checked and how many URLs and responses should be processed at once.

Panel

In the panel the queue view has been extended to offer the same functionality. You can also check responses and process the queue there, instead of or in addition to the webhooks.

You can see how this looks in the following video. To clarify, I have also activated the Webmention queue and set all limits to 1, so you can better see the process:

Collecting answers only works on pages where IndieConnector hasn't yet created automatic posts, or where a Mastodon/Bluesky URL is specified in the panel.

Multi-Image-Posts

Previously, it was only possible to add one image per post to Mastodon and Bluesky. However, both allow up to four images, and this is also possible with the IndieConnector.

Starting now, the first four images from the configured image field will be automatically uploaded and posted.

Posts without URL

When creating a post on Mastodon and Bluesky, a link to the Kirby page was always automatically added. This is not desired in certain cases.

With two new options, this can now be prevented.

To never add a URL to any post, you can set this option in your config.php:

'mauricerenck.indieConnector.post.skipUrl' => true

To not add a URL to certain templates, you can use this option:

'mauricerenck.indieConnector.post.skipUrlTemplates' => ['template-1', 'template-2']

You can also control this individually on each page in the panel.

Roadmap for the upcoming release

Thomas has launched a nice new service, he calls it Bloggerrolle, and I just had to write a Kirby plugin for it.

Maybe you already know uberblogr.de, one of, if not the most well-known German web rings. It now hosts over two hundred German blogs, which is really great!

At some point, uberblogr offered the option to send a ping to inform the web ring about new updates on your own site. This led to the idea of implementing something like that as an independent service.

Thomas recently did this, and it’s called Bloggerrolle. The name already includes "blogroll," and it’s not about displaying the latest posts, but rather a list of blogs that have just reported an update.

Essentially, it’s a dynamic blogroll where you can register and then notify it when there’s something new, so you can stay at the top of the list until the next blogs report in.

It’s a great way to discover new blogs and stay updated.

Thomas describes how to ping the site here. The two most common methods are:

• XML-RPC, which can be configured directly in WordPress and likely covers a large number of blogs
• Webhook, which should work in pretty much any other CMS without additional XML libraries or much code

I immediately got to work on integrating the ping into my blog. Since I generally do this as a plugin, simply because the code is better structured that way, I decided to make my code available as a plugin.

So if you use Kirby for blogging, you can install the plugin through the usual methods, and it will automatically ping Bloggerrolle and/or uberblogr when you publish a new page.

Of course, you can also fine-tune it so that not all pages send a ping, for example, your imprint.

Bloggerrolle - Maurice Renck

Dieses Kirby-Plugin sendet einen Ping an bloggerrolle.de und/oder uberblogr.de, sobald du eine neue Seite veröffentlichst.

This Kirby plugin will ping bloggerrolle.de and/or uberblogr.de whenever you publish a page.

Installation

Use one of these methods to install the plugin:

• composer (recommended): composer require mauricerenck/bloggerrolle
• zip file: unzip main.zip as folder site/plugins/bloggerrolle

Usage

After installing the plugin, it will ping bloggerrolle.de and/or uberblogr.de whenever you publish a page.

If you are not a member of the uberblogr webring, you first have to register your site at bloggerrolle.de. If you are a member of the uberblogr webring, you don't have to register your site at bloggerrolle.de again. Read more about this here

In both cases you at least have to set the URL your registered with in your config.php file:

<?php

return [
    "mauricerenck.bloggerrolle" => [
        'url' => 'https://YOUR-BLOG-URL',
    ],
];

Use the full URL. So if you registered with https://example.com/en/blog you also need to use that URL in your config.php file.

Uberblogger members

In case your blog is a member of uberblogr you don't need to register at bloggerrolle.de again. This plugin will automatically ping both sites. In this case go to your config and set:

<?php
"mauricerenck.bloggerrolle" => [
    'url' => 'https://YOUR-BLOG-URL',
    'uberblogr' => true,
],

Restricting templates

You may not want to ping the pages with every page you publish. For example a new legal page should not result in a ping, but a new blog post should.

You have two options:

• Allow specific templates to ping
• Block specific templates from pinging

Setting templates.allowed will allow only the templates listed in the array to ping, no other template will send a ping.

<?php
'mauricerenck.bloggerrolle.templates.allowed' => ['post', 'note'],

Setting templates.blocked will allow all templates except the ones listed in the array to ping.

<?php
'mauricerenck.bloggerrolle.templates.blocked' => ['legal'],

Leave both options away if you don't want any restrictions.

Options

Please make sure to prefix all options with mauricerenck.bloggerrolle or use the array notation.

Maurice (@mauricerenck@mastodon.online)

There seems to be something up with the #indieConnector in combination with brid.gy. All webmentions fall back to the type „mention-of" instead of, for example, „like-of". I am pretty sure the webmention source (generated by brid.gy) previo…

There I mentioned that I have long been planning to fetch external replies, likes, and reposts myself. However, this is not as trivial as it seems at first glance.

Unfortunately, I haven't figured out why collecting replies via brid.gy is no longer working as it used to. I can't view the current logs because they end with error messages before a Webmention is sent.

So it is indeed time to tackle this feature and remove it from the upcoming-features list on GitHub. And that's exactly what I am doing.

When posting automatically to Mastodon or Bluesky, the IndieConnector plugin (IC) already saves the URLs to the posts. In the case of Mastodon, you can also manually provide a URL (this will also be available for Bluesky).

These are already good prerequisites for the feature, as IC knows where to look to collect reactions. Mastodon provides three endpoints to access likes, reposts, and replies – wonderful.

There are already a few solutions and descriptions of how to solve this with JavaScript. They work well, but for the plugins, I need (and want) to take the PHP route.

The IC goes through all the URLs, fetches the replies, and then sends a Webmention to itself. Each response has a virtual page with corresponding Microformats. From here, the usual Webmention process takes place. One reason I chose this approach is that this way, I only need to build the fetching mechanism and not open another path to store data, etc.

Unlike the JavaScript solution, I need to remember which reactions I have already processed so that I don't keep sending the same Webmentions and create unnecessary load on the systems. So, I store the last known response ID for each Mastodon endpoint and end the process once that ID is reached.

So far, this is working great.

However, for the past few hours, I've been sitting here wondering why these Webmentions don't want to get through. They are being sent. And as cool as I find this whole technology, debugging asynchronous processes is and remains tricky. I try to cover individual steps with unit tests, but sometimes – like right now – I still find myself staring at the screen confused.

I hope to resolve the issue quickly. Then I would have the complete process for Mastodon ready and only need to build the fetching mechanism for Bluesky (because after fetching, it continues just like it now does with Mastodon).

Update
I used an incorrect (old) URL for my Webmention endpoint and sent all Webmentions into oblivion, which is why they didn't show up in the panel 🤦🏼‍♂️

Hold on a moment! Just checked my calendar; yes, we are in the year 2025, not 2005. Nevertheless, this appointment was in my calendar today: Blogtastisch! 2. Blogs and the Fediverse.

They are back again, the blogrolls¹, the webrings², the personal websites, the new blogs and blogging events! And as if that weren't reason enough to clap your hands in delight, you also get to know many wonderful new people.

Today was the second virtual Blogtastisch meeting. Part of the German blogging community met online to network a bit and then listen to Matthias Pfefferle explaining what the Fediverse is and how his WordPress plugin³ contributes significantly to its growth.

A wonderful format with many sympathetic participants, two of whom I got to know in a short conversation (Maria and Michael). Because before the actual topic started, we were all randomly divided into groups of three and had seven minutes to talk to each other. Nice idea.

Unfortunately, I couldn't stay until the end, my lunch break was over and work called. The next meetup is in the evening, that should fit better time-wise, and I'm already looking forward to it.

Those who also want to participate can find more information here (German only):

Blogtastisch! Meetup für die Bloggosphäre

Kurz zusammengefasst: Am 11. März startet ein neues Eventformat für Blogger:innen. In 10 abwechslungsreichen Ausgaben könnt ihr euch zu spannenden Themen rund um Blogs und das neue Netz informieren…

With Sociabli we want to connect various services. We start with Mastodon and Bluesky.

With Sociabli, Mark and I want to connect platforms, services, and the IndieWeb. We create flows that distribute your own content. Users can choose which services they wish to link.

We are currently live with a beta and our focus has been on the flow between Mastodon and Bluesky. Users can activate the flow and thereby mirror their Mastodon posts to Bluesky. We take care of all the details:

• Share long Mastodon posts so that they are posted as 300-character threads on Bluesky
• Scale images so they are not too large for Bluesky
• Mirror these images, of course
• Convert URLs and hashtags so that Bluesky recognizes them
• Filter replies that would lead to nowhere on Bluesky

Our second flow leads from your own blog to medium.com. If you publish a blog post, it is also published on Medium. We create an introduction, can set a title image and tags, and take care of the correct Canonical URL so that search engines don't have any trouble with it.

A list of people talking about and working on or with the Kirby CMS, Kirby plugins or themes.

Starterpacks help new users in the Fediverse find people with shared interests. This starterpack is a list of people who are into Kirby.

You can follow individual users or all of them.

If you know other people who should be on this list, write me a comment or message me on Mastodon.

With Sociabli we want to connect various services. We start with Mastodon and Bluesky.

It wasn't that long ago that Mastodon was in the spotlight as a possible Twitter replacement. That didn't last long. Meta's Thread.net caused a stir for a while. During the last eXits, many users migrated to Bluesky.

This is understandable because coming from Twitter, the Bluesky interface feels familiar and intuitive. So-called starter packs that help find users to follow also added momentum.

You can argue about Bluesky – rightfully so – but many users are simply there. So it could be interesting to become active there too. Often this involves switching from one network to another – but it doesn't have to.

With Sociabli, Mark and I want to connect platforms, services, and the IndieWeb. We create flows that distribute your own content. Users can choose which services they want to link.

We are currently live with a beta and our focus has been on the flow between Mastodon and Bluesky. Users can activate the flow and thereby mirror their Mastodon posts to Bluesky. We take care of all the details:

• Share long Mastodon posts so that they are posted as 300-character threads on Bluesky
• Scale images so they are not too large for Bluesky
• Mirror these images, of course
• Convert URLs and hashtags so that Bluesky recognizes them
• Filter replies that would lead to nowhere on Bluesky

Our second flow leads from your own blog to medium.com. If you publish a blog post, it is also published on Medium. We create an introduction, can set a title image and tags, and take care of the correct Canonical URL so that search engines don't have any trouble with it.

While Mastodon and Bluesky flows are controlled via RSS feeds, we have provided a webhook for content from your own blog. Using this, we will not only cross-post to Medium in the future, but also connect to other services.

Users can either call up the webhook themselves or use our Kirby plugin. A WordPress plugin is also on its way.

We are still in the early beta phase, so it may not be entirely smooth sailing yet and we need to see how our systems perform under load when more active users use the system. Currently, our service can be used for free, but there will also be a fair paid plan in the future; at the latest when more services are connected and we reach the point where we need to scale further, that doesn't come for free.

If you feel comfortable on Mastodon but have the urge to be active on Bluesky too, we invite you to take a look at Sociabli.

For years I used Feedly as my feed reader and was always satisfied with it. When I started to slowly leave Twitter (back then), I upgraded my subscription to be able to create Twitter lists in Feedly and follow certain accounts without having to access Twitter directly.

Twitter no longer exists, the APIs are turned off – let's not mention the new new owner.

A few basic rss reader functions remain for me that I don't want to go without:

• Sync: I want to be able to access the feeds from anywhere (Desktop / Mobile) and have them synchronized accordingly.
• Read-Later: I need some kind of function to bookmark posts. Because often I only go through my feeds once and mark everything I want to read later.
• Newsletters: It would still be great to be able to subscribe to newsletters and have them displayed as feed items.
• Interfaces: The icing on the cake would be interfaces outwards so that I can do things from the feed reader.

Goodbye Feedly

Feedly does many things very well. Lately, they also managed to get on my nerves very well – with their AI stuff. I was constantly reminded of what new AI service I could now book.

Visually, nothing has really changed at Feedly in recent years. Reading posts was okay, but not more than that. Newsletters I had subscribed to also often looked a bit broken.

Therefore, I was rarely directly on Feedly, but read my feeds through the Reeder app. Which made the price for Feedly even more absurd.

I could also subscribe to feeds directly in Reeder without an instance in between. If not for my wishes. So an alternative had to be found. I had already asked around in 2023, but then missed canceling my subscription on time. Not this time.

Hello Feedbin

My choice fell on Feedbin. Thanks to the trial phase, I could test Feedbin extensively and was very satisfied after a short time.

I was able to import my feeds thanks to OPML. And Feedbin even helped me find orphaned feeds and correct their URLs. Very pleasant.

For my newsletters I had to do a little more work and subscribe to them again. But here I wouldn't know how it could work technically differently. One thing immediately stood out positively: With Feedbin, after subscribing, I get a list of all newsletters displayed. At Feedly, I always searched for this and never found such a list.

What stands out immediately in contrast to Feedly is the design. Simple, yet modern and functional. The folders that I created at Feedly appear as tags in Feedbin's menu, so I have a good structure. Posts can be read well – including newsletters.

I can mark posts with an star and I can click a magic button, which I already know from Reeder. This button fetches the complete text of a post from the website, even if the text is shortened in the feed. Perfect!

Despite the possibility of staring posts, I decided on a different Read-Later service and chose the good old Instapaper. Just as minimal and beautifully designed as Feedbin and directly connected.

Speaking of connection: Feedbin allows you to create social plugins. You can then forward content through these and use them for sharing. Instapaper is there, along with numerous others. It is also possible to enter your own URLs, which I naturally tried out immediately.

In Kirby, I built an endpoint that receives the URL, title and source. Shared posts then end up directly in my notes on my page. Either directly public or as a draft to be further edited.

It gets even better: Feedbin can be operated with keyboard shortcuts! So I have three shortcuts at hand to share posts directly:

Ha! That's something you just have to love!
I press 1, 2 or 3 and accordingly the current post goes its way.

Conclusion

As you can probably tell: I am quite enthusiastic with Feedbin and will be happy to continue using it. Since I've been on Feedbin, I haven't used the Reeder app anymore because everything works directly and looks great.

Anyone who is still looking for a reader with the mentioned functions should definitely consider Feedbin.

Feedbin

A fast, simple RSS feed reader that delivers a great reading experience.

Previously, it was possible to automatically post new pages to Mastodon, but this happened every time you published a page if enabled. Now, you can define templates specifying when this should or should not happen. For example, you can configure the plugin so it doesn't send a post to Mastodon when you publish your privacy page, but it does when you publish a new blog post. Additionally, you can now disable posting at the page level within the panel.

Furthermore, you can now post not only text status updates but also images.

I'm looking forward to releasing this major update. I think it's a good one!

What should a good social media platform look like? I've written about it before: It must primarily be decentralized and open source. Every person should be able to set it up and use it quickly. Of course, we all immediately think of one thing: twtxt.

Twtxt works like this: Every website owner makes the endpoint /twtxt.txt available under their own domain. It's probably quite obvious that this file is a simple text file, formatted in a specific way:

2024-01-19T18:11:32+01:00    Hamburg remains stable, 130,000 people against #fuckAfD, that was great!
2024-01-19T11:22:16+01:00    Bought a low-profile microphone arm. Why didn't I do this earlier?! So much more stable! So nicely organized

As you can see, the (UTF-8) file contains one status per line, divided into the date and the 140-character text, separated by a TAB character. That's it! Done!

If you want to mention other users, you can use the usual @ syntax, for example: @<source.nick source.url>

You can create such a file yourself, have it generated automatically, or fill it with your own CMS. There are hardly any limits to your imagination. I convert my Mastodon Feed using a Kirby route.

Reading

Now creating such a file is pretty pointless if no one can read it. For this, there is a client that you can install. With the Quickstart command, you can create your own "account":

twtxt quickstart

Yes, it's a terminal client!

Once everything is set up, you can start following other users. For example, follow me:

twtxt follow maurice https://maurice-renck.de/twtxt.txt

You can view your personal timeline with the following command:

twtxt timeline

Of course, you can also unfollow others, see who you are following, and post a status if it doesn't work through the CMS. You can find all commands here.

I must admit that I fear using the terminal might be off-putting. Honestly, I only discovered this feature on my site a few days ago, and I find it somehow charmingly nerdy, so I wanted to write about it. Maybe you do too.

And for those who don't want to use the terminal, you can still use Mastodon…