@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.
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
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 excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
Deferred instantiation: Set up dispatchers and listeners before creating the federation object
Better code organization: Avoid circular dependencies and improve project structure
Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
Modular setup: Build complex federations piece by piece before instantiation
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Adaptive caching: The system remembers which version each server supports to optimize future requests
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
Global edge deployment with low latency
Serverless scaling and automatic resource management
Integration with Cloudflare's ecosystem of services
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
#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! 🚀
If you're on the fence about which driver to choose for #Fedify's message queue, here's a benchmark that just came out. In addition to no queue, we compare 5 drivers, for a total of 11 setups:
The effort will be tackled in phases, including compatibility assessment, core adaptations for Workers' environment, KV store and message queue implementations, and finally integration with Cloudflare's ecosystem. This will be a substantial project that we'll break down into several sub-issues.
If you're interested in contributing to any specific aspect of Workers support, please comment on the main issue to coordinate efforts.
🎉 #Cloudflare#Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating 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!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorialCreating 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!
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure! 🏷️
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/ for bug, feature, documentation
component/ for different parts of Fedify
activitypub/ for interop issues with Mastodon, Misskey, etc.
We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
This patch for @vite is blocking #Fedify's Cloudflare Workers support. They say it'll be included in #Vite 7, but I can't wait that long, so I'm not sure what to do… 🤔
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
We've just submitted an #application to the Sovereign Tech Fund for the #Fedify project! Hoping to further develop and enhance the framework for a more robust federated web.
Just received word that @fedifyFedify: an ActivityPub server framework 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.
Even small contributions help sustain development and show there's interest in open source #ActivityPub tools. Thanks to our existing sponsors who've already been helping move the project forward!
The goal remains the same: make building federated applications more accessible to developers so the #fediverse can continue to grow and thrive.
Just received word that @fedifyFedify: an ActivityPub server framework 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.
The effort will be tackled in phases, including compatibility assessment, core adaptations for Workers' environment, KV store and message queue implementations, and finally integration with Cloudflare's ecosystem. This will be a substantial project that we'll break down into several sub-issues.
If you're interested in contributing to any specific aspect of Workers support, please comment on the main issue to coordinate efforts.
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.
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! 🙏
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
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! 🙏
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
We're pleased to announce that #Fedify has been included in the Nivenly Fediverse Security Fund program!
The @nivenlyThe Nivenly Foundation Foundation has launched a security bounty fund to support contributors who identify and help fix #security vulnerabilities in popular #fediverse software. Both Fedify and @holloHollo 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.
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.
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.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
#Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
• Type-safe objects for Activity Vocabulary (including some vendor-specific extensions) • #WebFinger client and server • HTTP Signatures • Middleware for handling webhooks • #NodeInfo protocol • #Node.js, #Deno, and #Bun support • CLI toolchain for testing and debugging
If you're curious, take a look at the Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
This is a significant milestone for our project, and we're deeply grateful to @johnonolanJohn O'Nolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
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 behavior
await 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.
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:
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 Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
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. 😊
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Got an interesting question today about #Fedify's outgoing #queue design!
Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.
In the #fediverse, server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.
By creating individual queue items for each recipient:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.
This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!
What other aspects of Fedify's design would you like to hear about? Let us know!
Coming soon in #Fedify 1.5.0: Smart fan-out for efficient activity delivery!
After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.
As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.
Our solution? A new two-stage “fan-out” approach:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For developers with specific needs, we're adding a fanout option with three settings:
"auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
"skip": Bypasses fanout when you need different payload per recipient
"force": Always uses fanout even with few recipients
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
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.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
@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.
@
@
@
@
@
@
❤️ 
@
