A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! 
#fedidev
fedify
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
Turns out Mastodon implements the FEP-8fcf specification (Followers collection synchronization across servers), but it expected all followers to be in a single page collection. When followers were split across multiple pages, it would only see the first page and incorrectly remove all followers from subsequent pages!
This explains so much about the strange behavior I've been seeing with #Hollo and other #Fedify-based servers over the past few months. Some people would follow me from large instances, then mysteriously unfollow later without any action on their part.
Thankfully this fix has been marked for backporting, so it should appear in an upcoming patch release rather than waiting for the next major version. Great news for all of us building on #ActivityPub!
This is why I love open source—we can identify, understand, and fix these kinds of interoperability issues together. 😊
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Check out the proposal: https://github.com/fedify-dev/fedify/issues/206.
Key considerations:
Should this be part of Fedify's scope?
Quick API extension vs complete worker architecture redesign
Integration with existing task queue systems
We'd love to hear your thoughts! Do you need this feature? How would you use it? Share your feedback in the issue thread.
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Build your own #fediverse server with #Fedify!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
✨ Key features
Complete protocol support including WebFinger, HTTP Signatures, and NodeInfo
Enhanced interoperability with Object Integrity Proofs and Linked Data Signatures
Type-safe Activity Vocabulary API to prevent development mistakes
Reliable delivery with automatic retries and message queues
Full observability through OpenTelemetry integration
Multiple backend support: Redis, PostgreSQL, AMQP
Seamless integration with popular web frameworks: Express, Hono, Fresh, SvelteKit
Comprehensive logging and tracing
Debug ActivityPub in real-time with ephemeral inbox server
Inspect ActivityPub objects and actors with lookup tool
Tunnel your local server for development
🚀 Runtime support
📚 Easy to learn
Extensive docs
Step-by-step tutorials
Community support via Matrix & Discord
Available under the #MIT license—free and open source!
Is the world in need of a federated Craigslist/Kleinanzeigen platform? I am currently thinking about a project to dig into #fediverse development and learning #golang or stay with #deno and using #fedify.
EDIT: There is already something like that on the fediverse! It's called Flohmarkt. Thanks for the comments mentioning that!
https://codeberg.org/flohmarkt/flohmarkt
Edited 109d ago
이番(번)에 @lqez 님의 《우리의 코드를 찾아서》에 出演(출연)하여 #페디버스, #ActivityPub, #Fedify, #Hollo에 關(관)해 이야기를 나눴습니다. Fedify와 Hollo의 開發(개발) 祕話(비화) 같은 게 궁금하시다면 한 番(번) 보셔도 재밌을지도 모르겠습니다. ㅎㅎㅎ
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behaviorawait ctx.sendActivity( { identifier: "alice" }, recipients, activity, { fanout: "auto" } // Default: automatic based on recipient count // Other options: "skip" (never use fan-out) or "force" (always use fan-out));
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({ // Use example.com for handles but ap.example.com for ActivityPub URIs origin: { handleHost: "example.com", webOrigin: "https://ap.example.com", }, // Other options...});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
await ctx.sendActivity( { identifier: sender }, "followers", activity, { preferSharedInbox: true, syncCollection: true, // Explicitly enable collection synchronization });
Enhanced Key Format Compatibility
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
@fedify/redis 0.4.0
@fedify/postgres 0.3.0
@fedify/amqp 0.2.0
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Denodeno add jsr:@fedify/fedify@1.5.0# For npmnpm add @fedify/fedify@1.5.0# For Bunbun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're pleased to announce that #Fedify has been included in the Nivenly Fediverse Security Fund program!
The @nivenly Foundation has launched a security bounty fund to support contributors who identify and help fix #security vulnerabilities in popular #fediverse software. Both Fedify and @hollo are among the selected projects that meet their responsible security disclosure requirements.
This program will run from April–September 2025, with bounties of $250–$500 USD for high and critical security vulnerabilities.
We're honored to be recognized alongside other established fediverse projects like Mastodon, Misskey, and Lemmy. This further encourages our commitment to maintaining strong security practices.
If you're interested in contributing to Fedify's security, please follow our responsible disclosure process outlined in our SECURITY.md file.
Learn more about the program:
https://nivenly.org/blog/2025/04/01/nivenly-fediverse-security-fund/
What to learn more about the #fediverse and #ActivityPub? This tutorial (https://fedify.dev/tutorial/microblog) from @fedify is a really good starter. It explains how to implement a really simple #federated server and see how communication exchange are done with AP.
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
In case you weren't aware, #Fedify has both #Discord and #Matrix communities where you can get help, discuss features, or just chat about #ActivityPub and federated social networks.
Matrix space: #fedify:matrix.org
Discord server: https://discord.gg/bhtwpzURwd
Feel free to join either community based on your preference. Both channels have active discussions about Fedify and federation topics.
Looking for #ActivityPub implementations with #RFC9421 support! 🔍
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
has implemented RFC 9421 (even in a development branch)
is currently implementing it
has plans to implement it soon
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated! 🙏
As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
Edited 55d ago
Hey folks! We're excited to share a preview of a new API coming in #Fedify 1.6 that should make structuring larger federated apps much cleaner: FederationBuilder.
As your Fedify applications grow, you might encounter circular dependency issues when registering dispatchers and listeners across multiple files. The new FederationBuilder pattern helps solve this by separating the configuration phase from instantiation.
Instead of this:
// federation.tsimport { createFederation } from "@fedify/fedify";export const federation = createFederation<AppContext>({ kv: new DbKvStore(), queue: new RedisMessageQueue(), // Other options...});// Now we need to import this federation instance in other files// to register dispatchers and listeners...
You can now do this:
// builder.tsimport { createFederationBuilder } from "@fedify/fedify";export const builder = createFederationBuilder<AppContext>();// other files can import and configure this builder...
// actors.tsimport { builder } from "./builder.ts";import { Person } from "@fedify/fedify";builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => { // Actor implementation});
// inbox.tsimport { builder } from "./builder.ts";import { Follow } from "@fedify/fedify";builder.setInboxListeners("/users/{handle}/inbox", "/inbox") .on(Follow, async (ctx, follow) => { // Follow handling });
// main.ts — Only create the Federation instance at startupimport { builder } from "./builder.ts";// Build the Federation object with actual dependenciesexport const federation = await builder.build({ kv: new DbKvStore(), queue: new RedisMessageQueue(), // Other options...});
This pattern helps avoid circular dependencies and makes your code more modular. Each part of your app can configure the builder without needing the actual Federation instance.
The full documentation will be available when 1.6 is released, but we wanted to share this early with our community. Looking forward to your feedback when it lands!
Want to try it right now? You can install the development version from JSR or npm:
# Denodeno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01# Node.jsnpm add @fedify/fedify@1.6.0-dev.777# Bunbun add @fedify/fedify@1.6.0-dev.777
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
Just received word that @fedify wasn't selected for @nlnet's Open Call this round. While disappointing, I understand the competition was fierce with many worthy projects seeking limited funding.
The journey continues though—#Fedify development will move forward at its own pace. Thanks to everyone who's shown interest and support for this project so far. Building tools for the #fediverse remains important work, and I'm committed to seeing it through.
If you know of other funding opportunities that might be a good fit for open source #ActivityPub tools, I'm all ears.
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare #Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀
#ActivityPub #fedidev #fediverse #RFC9421 #CloudflareWorkers
Did you know? #Fedify provides #documentation optimized for LLMs through the llms.txt standard.
Available endpoints:
https://fedify.dev/llms.txt — Core documentation overview
https://fedify.dev/llms-full.txt — Complete documentation dump
Useful for training #AI assistants on #ActivityPub/#fediverse development, building documentation chatbots, or #LLM-powered dev tools.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue — utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue — leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue — can now be configured to use AMQP broker's native retry mechanisms
The InProcessMessageQueue continues to use Fedify's internal retry mechanism, while ParallelMessageQueue inherits the retry behavior from its wrapped queue.
AMQP message queue improvements
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We're pleased to share that Encyclia has joined our success stories.
@encyclia bridges academic research to the #fediverse by making #ORCID researcher profiles and publications discoverable through #ActivityPub—built with #Fedify for seamless interoperability across Mastodon and other fediverse platforms.
This demonstrates Fedify's versatility beyond traditional social networking, helping specialized domains connect to the federated web.
We're also grateful for #Encyclia's sponsorship support, which helps make Fedify's development possible.
Learn more about Encyclia at https://encyclia.pub/. 📚
Excited to share that I've joined #OSSCA (Open Source Software Contribution Academy) as a mentor for the @fedify project!
OSSCA is a national program run by South Korea's NIPA (National IT Industry Promotion Agency) through their Open Source Software Support Center, aimed at fostering the next generation of open source contributors.
We're currently in the process of selecting around 20 mentees who will start contributing to #Fedify once the selection is complete. I've been busy preparing good first issues to help them get started on their open source journey.
Looking forward to working with these new contributors and seeing what amazing things we can build together!
#Fedify has moved to a monorepo structure with unified versioning across all packages (@fedify/fedify, @fedify/cli, database adapters & framework integrations).
All packages now release together, making dependency management much simpler!
