Fedify 1.6
#fedify
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.
🌐 Cloudflare Workers support
Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
New components
WorkersKvStore: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environmentsWorkersMessageQueue: A message queue implementation leveraging Cloudflare Queues for reliable message processing
Key features
- Seamless integration with #Cloudflare's serverless runtime
- Automatic handling of queue message processing through Workers'
queue()method - Support for Node.js compatibility flag required for Fedify's cryptographic operations
- Manual queue processing via
Federation.processQueuedTask()method
For a complete working example, see the Cloudflare Workers example in the Fedify repository.
🏗️ Federation builder pattern
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.
🔐 HTTP Message Signatures (RFC 9421)
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
Double-knocking mechanism
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
- Primary attempt: RFC 9421 (HTTP Message Signatures) for modern implementations
- Fallback: Draft cavage version for legacy compatibility
- 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:
- Mitra 4.4.0: Successfully verified Fedify-generated RFC 9421 signatures
- 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.
#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #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.
Hackers' Pub and hollo.social are the instances currently serving as testbeds for #Fedify. 😂
#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
🎉 #Cloudflare #Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
What's included:
@fedify/fedify/x/cfworkersmodule withWorkersKvStoreandWorkersMessageQueue- Complete documentation covering Workers-specific patterns and constraints
- Working example deployed to production
- Integration with Cloudflare KV and Queues
Try it now: Available in the development release v1.6.1-dev.876+7b07d213:
- JSR: https://jsr.io/@fedify/fedify@1.6.1-dev.876+7b07d213
- npm: https://www.npmjs.com/package/@fedify/fedify/v/1.6.1-dev.876
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!
I deployed my first #Fedify application on Cloudflare Workers and saw it running smoothly. Now all that's left is the documentation!
ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう！』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです！
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!
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, documentationcomponent/for different parts of Fedifyactivitypub/for interop issues with Mastodon, Misskey, etc.
We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
Check out the full proposal: https://github.com/fedify-dev/fedify/issues/238.
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
- Thoroughly discussed within the Fedify community (Discord, Matrix, GitHub Discussions)
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.
For detailed guidance on the contribution process, see the Extending the vocabulary section in Fedify's docs.
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?
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.
For those interested in supporting #Fedify's development, we do have an Open Collective page where community #sponsorship is welcome.
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 @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.
Good news! We've officially added #Cloudflare #Workers support to the #Fedify roadmap. We've created a detailed issue to track our implementation plan: https://github.com/fedify-dev/fedify/issues/233.
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.
Just wrote the Why Fedify? section in the #Fedify docs.
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst