@fedify@hollo.social · 9 following · 763 followers
Fedify is a TypeScript library for building federated server apps powered by ActivityPub and other standards, so-called fediverse. 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.
@fedify@hollo.social
🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at:
Your support will help us maintain and improve Fedify. Check it out here:
https://opencollective.com/fedify
@fedify@hollo.social
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:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
@samvie@chaos.social
Great demo of @encyclia by @julian
Day 3 of #Fediforum starts strong with a great tool for the academic sphere👏
Making #Orcid available for #activitypub via @fedify
Open science communication is very relevant for the future development of the #Fediverse 🚀
@julian@fietkau.social · Reply to @reiver ⊼ (Charles) :batman:'s post
@reiver @hongminhee I ran an unconference session at @fediforum yesterday about "Implementing ActivityPub in 2025" but we were a pretty small group of people and went off topic a bunch, so the session notes is mostly just me trying to advertise @fedify. 🙃
@reiver@mastodon.social
Julian Fietkay ( @julian ) just said nice things about @fedify at FediForum 2025.
cc: @hongminhee
@fedify@hollo.social
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 first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
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 processingqueue() methodFederation.processQueuedTask() methodFor a complete working example, see the Cloudflare Workers example in the Fedify repository.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
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.
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.
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.
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.
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.
For new deployments, consider leveraging Cloudflare Workers support for:
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
@hongminhee@hackers.pub
Fedify 1.6.1のリリースを発表いたします。本バージョンは1.6.0の取り下げを受けた1.6シリーズの最初のリリースとなります。今回のリリースでは、Fedifyのデプロイメント方法を大幅に拡張し、フェディバース（fediverse）全体でのセキュリティ互換性を向上させる重要な新機能を導入しています。
Fedify 1.6ではCloudflare Workersへの正式対応を実現し、ActivityPubアプリケーションをエッジ環境でサーバーレス実行できるようになりました。
WorkersKvStore: Cloudflare KV APIを使用し、Workers環境で永続ストレージを提供するキーバリューストア実装WorkersMessageQueue: Cloudflare Queuesを活用し、信頼性の高いメッセージ処理を実現するメッセージキュー実装queue()メソッドによる自動的なキューメッセージ処理Federation.processQueuedTask()メソッドによる手動キュー処理完全な動作例については、FedifyリポジトリにあるCloudflare Workersのサンプル実装をご覧ください。
Fedify 1.6ではFederationBuilderクラスとcreateFederationBuilder()関数を導入し、フェデレーションの遅延インスタンス化をサポートします。このパターンには以下のメリットがあります。
このビルダーパターンは、特に大規模なアプリケーションや、設定データが実行時に動的に取得されるCloudflare Workersのような環境で有用です。
Fedify 1.6では、HTTP Signatures仕様の最終版となる公式HTTP Message Signatures標準（RFC 9421）仕様を実装しました。
フェディバース全体での最大互換性を確保するため、Fedify 1.6ではインテリジェントなダブルノック機構を導入しています。
このアプローチにより、最新とレガシー両方のActivityPub実装との円滑な通信を確保できます。同時に、セキュリティ標準の最前線にFedifyを位置づけています。
RFC 9421実装は、RFC 9421署名検証をサポートする既存のActivityPub実装との相互運用性について徹底的にテストされています。
これらのテストにより、他のActivityPub実装がFedifyで生成したRFC 9421署名を正常に検証できることを確認し、エコシステムが徐々に公式仕様を採用していく中で、適切なフェデレーションが保証されます。これらの実装は現在RFC 9421署名の検証をサポートしていますが、まだ自身でRFC 9421署名を生成していません。Fedifyはこのモダンスタンダードの生成と検証の両方をサポートする最初のActivityPub実装の1つとなっています。
新しいContext.lookupWebFinger()メソッドにより、WebFingerデータへの直接アクセスが可能になりました。高レベルなContext.lookupObject()メソッドでは実現できない、アカウント発見とリソース解決のより細かい制御を開発者に提供します。
新しいContext.clone()メソッドにより動的なコンテキストデータの置換が可能になり、リクエスト処理やデータフローの管理において、より高い柔軟性を提供します。特にミドルウェアの実装や複雑なリクエストルーティングを行う際に有用です。
Fedify 1.6は既存のアプリケーションとの完全な後方互換性を維持しています。新しいHTTP Message Signaturesとダブルノック機構は、コード変更なしで透過的に動作します。
重要: Fedify 1.6はNode.js環境においてNode.js 22.0.0以降を必要とします。この変更はDenoやBunランタイムを使用するアプリケーションには影響しません。現在Node.jsをご利用の方は、アップグレード前に環境がこの要件を満たしているかご確認ください。
新規デプロイメントでは、以下の利点からCloudflare Workersサポートの活用をご検討ください。
Fedify 1.6は、フェディバース全体での幅広い互換性を維持するというフレームワークのコミットメントを保ちながら、デプロイメント選択肢の大幅な拡張を表しています。Cloudflare Workersサポートの追加により、フェデレーティッドアプリケーションの新しいアーキテクチャパターンが開かれ、RFC 9421実装により、Fedifyは新たなActivityPubセキュリティ標準に対応し続けています。
詳細な移行ガイド、APIドキュメント、サンプルについては、Fedifyドキュメントをご覧ください。サポートとディスカッションについては、MatrixまたはDiscordのコミュニティにご参加ください。
@AmaseCocoa@s.amase.cc
1.6でサポートされるってことはfedify inboxでRFCテストできるようになるのか
@fedify@hollo.social
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 first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
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 processingqueue() methodFederation.processQueuedTask() methodFor a complete working example, see the Cloudflare Workers example in the Fedify repository.
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
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.
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.
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.
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.
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.
For new deployments, consider leveraging Cloudflare Workers support for:
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
@fedify@hollo.social
Did you know? #Fedify provides #documentation optimized for LLMs through the llms.txt standard.
Available endpoints:
Useful for training #AI assistants on #ActivityPub/#fediverse development, building documentation chatbots, or #LLM-powered dev tools.
@fedify@hollo.social
#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
@fedilug@msky.ospn.jp
#oscnagoya #技術書典18 のご参加ありがとうございました。
のブースや本、ステッカー、セミナーなどは楽しんでいただけましたでしょうか？次のFediLUGイベントは6月22日の第９回勉強会です！！ご興味がある方はぜひご参加ください。
また、OSC名古屋及び技術書典18リアル会場で頒布した『自分だけのフェディバースのマイクロブログを作ろう！』と『Thinking Penguin Magazine Vol.0』は技術書典18のオンライン通販で全国から購入可能です！この際にぜひご検討ください。
同人誌販売： https://techbookfest.org/organization/7JepZT0g3C6qbddiLmkAwp
第9回勉強会: https://fedilug.connpass.com/event/357642/
@fedify@hollo.social
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:
InProcessMessageQueueDenoKvMessageQueueRedisMessageQueuePostgresMessageQueueAmqpMessageQueueInProcessMessageQueue × 4DenoKvMessageQueue × 4RedisMessageQueue × 4PostgresMessageQueue × 4AmqpMessageQueue × 4Curious to see the results? Check out the GitHub repository!
@hongminhee@fosstodon.org · Reply to 洪 民憙 (Hong Minhee)'s post
@thisismissem Here's the benchmark, and while it contains some questionable results, the overall conclusion is as following:
• Response times are much faster with queues than without.
• Overall throughput is better without queues.
• However, some queue setups can achieve throughput close to that of no queue.
This benchmark assumes communication within a single node, so the effect of queues may be greater in real-world networks.
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
🎉 #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/cfworkers module with WorkersKvStore and WorkersMessageQueueTry it now: Available in the development release v1.6.1-dev.876+7b07d213:
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!
@fedilug@msky.ospn.jp
@fedilug@msky.ospn.jp
明日は #技術書典18 📕！！
#FediLUG は 6月1日 (日) 11:00～17:00 に 池袋・サンシャインシティ 展示ホールD（文化会館ビル2F）で開催される #技術書典18 にサークル出展します！
・FediLUG合同誌『Thinking Penguin Magazine Vol.0』
・ホンさん著『自分だけのフェディバースのマイクロブログを作ろう！』
それぞれ500円でご用意してお待ちしております！！
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee)'s post
ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう！』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです！
@hongminhee@hollo.social
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!
@hongminhee@hollo.social
오픈 소스 컨퍼런스 名古屋에서 Fedify 冊 《나만의 聯合宇宙 마이크로블로그 만들기》(自分だけのフェディバースのマイクロブログを作ろう！)가 完販되었다고…!
🍆@Yohei_Zuho@mstdn.y-zu.org
OSC名古屋、Fedify本完売した（6冊）
🍆@Yohei_Zuho@mstdn.y-zu.org
OSC名古屋、Fedify本完売した（6冊）
🍆@Yohei_Zuho@mstdn.y-zu.org
OSCでFedify本5冊売れた
🍆@Yohei_Zuho@mstdn.y-zu.org
無料というのもあってかFedify本がすごい売れる
🍆@Yohei_Zuho@mstdn.y-zu.org
技術書典オンラインが始まったけど、Fedify本みんな買っていってる
@fedilug@msky.ospn.jp
本日はオープンソースカンファレンス名古屋（ #oscnagoya ）当日です！
吹上駅から徒歩5分ほどの中小企業振興会館、第にファッション展示場で #FediLUG はブース出展、セミナーでのLT大会を開催予定です！
ステッカー、同人誌用意してお待ちしています！！
@fedilug@msky.ospn.jp · Reply to Fediverse Linux Users Group's post
今週末開催される、 #oscnagoya では #FediLUG ブースにて、
・有志8人による執筆のThinking Penguin Magazine Vol.0（500円）
・和条門さん（ @naoki_wjm@k.my-sky.blue ）による『さばかんライフ！』（1000円）
・ホンさん（ @hongminhee@hollo.social ）による『自分だけのフェディバースのマイクロブログを作ろう！』（500円）
も頒布いたします！
そのほかにもステッカーや各種チラシも扱っておりますので、ぜひ足をお運びください！！
🍆@Yohei_Zuho@mstdn.y-zu.org
Fedify本届いた〜
@fedify@hollo.social · Reply to just small circles 🕊's post
@smallcircles That's a great point! We definitely want to balance organization benefits with maintainer overhead. The goal is to make our workflow smoother, not more complex. We'll keep the system simple and only add labels that genuinely help contributors find relevant issues. Thanks for the perspective!
@fedify@hollo.social
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.
@hongminhee@hackers.pub
2025 오픈소스 컨트리뷰션 아카데미 참여형 멘티를 오늘부터 6월 22일까지 모집한다고 합니다. 저도 Fedify 프로젝트의 멘토로서 참여하고 있으니, 관심 있는 분들은 많은 참여 부탁드립니다!
RE: https://hollo.social/@hongminhee/0196231c-8256-788e-bba1-0d3a9215524f
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee)'s post
Fedify 프로젝트의 메인테이너로서 2025年 오픈소스 컨트리뷰션 아카데미 參與型 멘토團에 選拔되었습니다!
5月 21日(水)부터 6月 22日(日)까지 멘티도 募集한다고 하니 많은 參與 바랍니다.
@fedify@hollo.social · Reply to Antolius's post
@antolius Great question! For prototyping with custom vocabulary, we're setting up automated PR builds that will solve exactly this use case.
Soon, each pull request will automatically publish versioned builds to JSR and npm. For example, PR #123 would generate releases like:
This means you can install and test vocabulary extensions before they're merged upstream:
npm install @fedify/fedify@1.6.0-pr.123.1
This approach lets you prototype with your custom object types immediately while contributing back to the community when ready. You can develop against the PR build, and once your vocabulary addition is merged, simply update to the stable release.
The build pipeline isn't quite ready yet, but it's coming soon. In the meantime, forking and building locally is still your best bet for custom vocabulary during prototyping.
@fedify@hollo.social · Reply to Antolius's post
@antolius Great question! For prototyping with custom vocabulary, we're setting up automated PR builds that will solve exactly this use case.
Soon, each pull request will automatically publish versioned builds to JSR and npm. For example, PR #123 would generate releases like:
This means you can install and test vocabulary extensions before they're merged upstream:
npm install @fedify/fedify@1.6.0-pr.123.1
This approach lets you prototype with your custom object types immediately while contributing back to the community when ready. You can develop against the PR build, and once your vocabulary addition is merged, simply update to the stable release.
The build pipeline isn't quite ready yet, but it's coming soon. In the meantime, forking and building locally is still your best bet for custom vocabulary during prototyping.
@antolius@mastodon.social · Reply to Fedify: an ActivityPub server framework's post
@fedify this sounds reasonable for extending support for 3rd party vocabulary. How do you envision developing 1st party vocab for servers implemented using fedify?
For example, I'm developing a service that needs to introduce some new object types. But I'm nowhere near ready to codify them in a FEP or share them with broader fedify userbase. What would be the best way to continue using fedify in this prototyping phase? (Perhaps building with a fedify fork and merge uspream once server is done?)