Scheduling the same ai-generated post across X, Mastodon, and Bluesky. AImitatio Team | October 7, 2026 Posting the same update to X, Mastodon, and Bluesky used to mean three different copy-paste jobs. AImitatio's scheduler now treats all three as one job: you write a prompt once, set a schedule, and the content goes out to whichever networks you've connected - text and, where supported, video. How the scheduling actually works. Each content job has two timing settings: an interval (how often to post) and an optional randomness window added on top of it. That second part matters more than it sounds - a feed that posts at the exact same minute every day reads as a bot immediately. A few minutes of jitter on top of your interval is enough to make scheduled content look like it was actually posted by someone, without you doing anything by hand. One prompt, three different platforms. Under the hood, AImitatio has a separate posting integration for X (Twitter), Mastodon, and Bluesky - each network has its own API, its own character limits, and its own quirks, so the platform adapts the same generated content to fit each one rather than blasting out one identical blob of text everywhere. Bluesky in particular needed its own path: it's built on the AT Protocol, which identifies accounts by a DID rather than just a handle, and video works completely differently from a normal image upload. A video has to be uploaded to Bluesky's own separate video-processing service, authorized with a short-lived token scoped to just that upload, and then the platform waits - polling Bluesky's own job-status endpoint - until Bluesky confirms the video has finished processing before the post is considered published. AImitatio handles that whole handshake for you; from your side it's still just "this job posts to Bluesky too." Where the content comes from. None of this changes how you set up a job in the first place: you still write a prompt that gives the AI the context and tone you want, and AImitatio generates the text (and, if the job uses one, an image) from it. What changed is only the distribution side - the same generated post can now reach X, Mastodon, and Bluesky from a single schedule instead of needing a separate setup per network. Try it. If you're already using AImitatio for one network, connecting a second or third costs you nothing extra in setup time - the prompt and schedule stay the same, you're just adding another destination. New to AImitatio? See how the whole platform works or create a free account to set up your first job.

Mastodon integration, best time to post and more. You can now schedule your content for Mastodon. PostFlow also helps you find the best time to post, keep your calendar tidy with compact mode, and pause publishing in a crisis. Mastodon scheduler. PostFlow now integrates with Mastodon. Connect your account from any server, then schedule and publish posts directly to Mastodon. Best time to post insights. Analytics just got better. The new Best times section shows heatmaps of when your posts get the most engagement. Go as deep as you need. See insights for the whole organization, a group, or a single account, and narrow them down by post type. You can also compare them with general trends across PostFlow, based on posts from all accounts in PostFlow. Optimal publish time. Not sure when to schedule your post? Just pick one of the suggested times, based on the engagement of your published posts. Suggestions also adapt to your post. They change depending on whether you selected one network or several, and they take the post type into account, so a Reel gets different times than an image post. Optimal publish times are also available in the API and MCP. Calendar compact mode. Planning a lot of posts? Compact mode shrinks post previews and keeps your calendar tidy. It can be enabled only for published posts or for all posts. Pause publishing (crisis mode). Built for crisis management. Instantly stop all outgoing posts with a single click, across all social accounts in your organization or in individual groups. Other improvements. * Copy media anywhere and paste it into the post composer with Ctrl+V * What's new tab: read the latest changelog directly in the app * Option to keep unpublished posts as drafts when disconnecting a social account

Building shared infrastructure for the Fediverse. Published 03 Sep 2026 Bonfire is happy to share that Bonfire is working with Mastodon and a couple of other free software projects on two pieces of shared fediverse infrastructure: remote media storage and automated content detection. This work is part of a Mastodon grant from the Sovereign Tech Agency. Both projects will build on the open Fediverse Auxiliary Service Provider (FASP) API specifications. FASPs give fediverse servers a standardised way to connect to independent external services, so every platform does not have to build and operate the same capabilities on its own. This approach could support a wide range of services that improve the scalability, safety, accessibility, sustainability, and user experience of the fediverse. Its collaboration will initially focus on two areas: Remote media storage #. Shared services for processing, storing, and hosting media from remote posts can reduce the need for every server to keep its own copies or requiring users' browsers to fetch media directly from external servers (which can otherwise reveal the reader's IP address to those servers). Automated content detection #. Open interfaces for content detection will make it easier for server operators and moderators to connect services that flag potential spam, illegal material, and other abuse for review. Operators will be able to choose services that fit their communities' needs and policies instead of depending on a closed, platform-specific system. Whatever shape these services take, communities should always know what is being scanned and by whom; automated detection should flag things for human review rather than acting on its own; and any such service must be easy to audit and to swap out. Building infrastructure together #. Its role is to help shape the specifications and implement them in Bonfire so that any Bonfire server can plug in to compatible services. Implementing the same open specifications across different platforms will help ensure that FASPs become genuinely shared infrastructure rather than something controlled by a single project or provider. For Bonfire this follows directly from how Bonfire is built: composable building blocks from the bottom up, with modularity and extensibility at every level. FASPs extend the same principle to the whole ecosystem, turning common capabilities into shared infrastructure that any platform can benefit from and any community can enable or swap out. On a closed platform, capabilities like these are usually built in-house and imposed on everyone, or negotiated behind closed doors with a chosen vendor, and either way would answer to data harvesting and profiteering instead of the people who rely on them. Thanks to the Mastodon team for taking the open path and inviting Bonfire to build this together. Bonfire is excited to collaborate with all the teams involved, and Bonfire'll share updates as the project progresses. Going forward #. The FASP approach already reaches beyond these two areas: the Fediscovery project has been designing pluggable search and discovery providers, which Bonfire'd like to bring to Bonfire as well, so communities can choose which services index and surface their public content and how they can search and discover content beyond their server's bubble. More widely, this can lead to an ecosystem of mutualised services a community can easily plug into. Today, anyone setting up an instance often implies separately choosing and setting up external services for domain name and DNS, hosting, email delivery, file storage and CDN, spam protection and more, usually from big commercial providers. Imagine instead enabling each of those with a one-click toggle in your Bonfire settings, provided by co-ops in a cooperative hosting network, governed democratically and transparently, and shaped through co-design the way everything in Bonfire Mosaic is: what one community needs and builds becomes a service every community can benefit from. Bonfire'd also love to hear from you: what would you want from media storage or content detection services, and who would you like to see providing them (e.g. IFTAS)? What other services could this approach make possible? How should this infrastructure be run and governed? And how might it be funded sustainably? Get in touch and share your ideas. The Telling Continue the conversation. Questions, reflections, and additions are welcome. This thread is federated, so the conversation can travel beyond this page.