In my ongoing development work, I focused on the response time of FlatPress 1.5 Stringendo with several thousand posts and comments. FlatPress currently has a concrete Fediverse bridge via the Mastodon plugin. Despite its extensive feature set, the FlatPress project does not compromise its core principles for Mastodon integration. From an architectural standpoint, this is a major advantage. FlatPress remains true to its own guiding principle: a simple, easy-to-install blogging engine that works with files rather than a database.
The Mastodon integration is implemented as a plugin rather than as built-in logic in the core. I’m currently still working on the final details. The main challenge lies less in missing features and more in FlatPress’s request-based operating model. In its current form, FlatPress has no true background service and no worker process that runs continuously. The Mastodon plugin’s automatic synchronization depends on regular web requests. It is clear from the plugin’s code: the automatic run is triggered only by regular requests, not by POST requests and not by CLI execution. If no one visits the page after the scheduled time, nothing happens initially; synchronization is postponed until the next appropriate page visit.
For small to medium-sized blogs, this is a pragmatic approach. However, for deeper federation or rapidly increasing communication loads, it presents a significant bottleneck. Every communication with Mastodon, every media upload, every import of a reply thread, and every additional file access consumes time within the same PHP request, which is also supposed to deliver a page at the same time. On fast systems, this may go unnoticed. On shared hosting, slow storage devices, or with unstable external connectivity, however, render and response times can suffer significantly or hit timeout limits.
This is precisely where Stringendo’s focus on performance aligns well with the challenges at hand. As FlatPress interacts more extensively with external services today, fast response times, robust file operations, local caching, and efficient I/O are no longer luxuries but essential requirements. The codebase already shows that I have invested precisely in these areas. Nevertheless, the fundamental limitation remains: as long as background processing is coupled with normal requests, it shares resources with the actual page delivery.
For crawlers, monitoring systems, or AI bots, it likely doesn’t matter whether FlatPress delivers a page in 200 milliseconds or in significantly longer. From FlatPress’s perspective, however, it is precisely such a regular GET request that can trigger the required synchronization process. We already use this in the newsletter plugin to send out the monthly newsletter. As long as complex external communication must take place within normal web requests, there will always be limitations regarding load, response time, and background processing. For personal and medium-sized self-hosted blogs, the current approach is nevertheless very practical. For broader, universal IndieWeb support, additional protocols and background processing decoupled from page requests would be necessary in the long term. However, I fear that FlatPress is not suitable for universal IndieWeb support.
Downloads and further information
This article is an automatic translation of the German article “Das Mastodon-Plugin als Fediverse-BrĂĽcke” written by FlatPress coder Fraenkiman on his personal blog: https://frank-web.dedyn.io/blog/2026/04/19/das-mastodon-plugin-als-fediverse-brucke/