Fedify: ActivityPub server framework's avatar

Fedify: ActivityPub server framework

@fedify@hollo.social

9 following1,131 followers

:fedify: 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.

Pinned

🎉 Excited to announce that is now on Open Collective! Support the project's development starting at:

  • Backer (from $5/mo)
  • Supporter (from $25/mo)
  • Sponsor (from $100/mo)
  • Corporate Sponsor (from $500/mo)
  • Custom donations welcome

Your support will help us maintain and improve Fedify. Check it out here:

https://opencollective.com/fedify

:fedify:

Fedify's Open Collective page showing the project logo, description as “A TypeScript library for building federated server apps powered by ActivityPub and other standards”, and five contribution tiers starting from $5/month Backer to $500/month Corporate Sponsor, with custom contribution options available.
ALT text

Fedify's Open Collective page showing the project logo, description as “A TypeScript library for building federated server apps powered by ActivityPub and other standards”, and five contribution tiers starting from $5/month Backer to $500/month Corporate Sponsor, with custom contribution options available.

Pinned

Fedify is an server framework in & . 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 website! There's comprehensive docs, a demo, a tutorial, example code, and more:

https://fedify.dev/

We're excited to announce the release of 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 .

🌐 Cloudflare Workers support

Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling deployment of applications at the edge.

New components

Key features

  • Seamless integration with '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 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:

  1. Primary attempt: RFC 9421 (HTTP Message Signatures) for modern implementations
  2. Fallback: Draft cavage version for legacy compatibility
  3. 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.

discord.com

Join the Fedify/Hollo Discord Server!

Check out the Fedify/Hollo community on Discord - hang out with 95 other members and enjoy free voice and text chat.

@hongminhee@hackers.pub

Fedify 1.6.1のリリースを発表いたします。本バージョンは1.6.0の取り下げを受けた1.6シリーズの最初のリリースとなります。今回のリリースでは、Fedifyのデプロイメント方法を大幅に拡張し、フェディバース(fediverse)全体でのセキュリティ互換性を向上させる重要な新機能を導入しています。

🌐 Cloudflare Workers対応

Fedify 1.6ではCloudflare Workersへの正式対応を実現し、ActivityPubアプリケーションをエッジ環境でサーバーレス実行できるようになりました。

新しいコンポーネント

主要機能

  • Cloudflareのサーバーレスランタイムとのシームレスな統合
  • Workersのqueue()メソッドによる自動的なキューメッセージ処理
  • Fedifyの暗号化処理に必要なNode.js compatibility flagのサポート
  • Federation.processQueuedTask()メソッドによる手動キュー処理

完全な動作例については、FedifyリポジトリにあるCloudflare Workersのサンプル実装をご覧ください。

🏗️ フェデレーションビルダーパターン

Fedify 1.6ではFederationBuilderクラスとcreateFederationBuilder()関数を導入し、フェデレーションの遅延インスタンス化をサポートします。このパターンには以下のメリットがあります。

  • 遅延インスタンス化: フェデレーションオブジェクトの作成前にディスパッチャーとリスナーを設定可能
  • コード構成の改善: 循環依存を回避し、プロジェクト構造を改善
  • Cloudflare Workers 互換性: リソースを引数として渡すバインディングベースアーキテクチャへの対応
  • モジュラーセットアップ: 複雑なフェデレーションをインスタンス化前に段階的に構築可能

このビルダーパターンは、特に大規模なアプリケーションや、設定データが実行時に動的に取得されるCloudflare Workersのような環境で有用です。

🔐 HTTP Message Signatures(RFC 9421)

Fedify 1.6では、HTTP Signatures仕様の最終版となる公式HTTP Message Signatures標準(RFC 9421)仕様を実装しました。

ダブルノック機構

フェディバース全体での最大互換性を確保するため、Fedify 1.6ではインテリジェントなダブルノック機構を導入しています。

  1. 第一段階: 最新実装向けのRFC 9421(HTTP Message Signatures)
  2. フォールバック: レガシー互換性向けのDraft cavage版
  3. 適応キャッシング: 各サーバーがサポートするバージョンを記憶し、今後のリクエストを最適化

このアプローチにより、最新とレガシー両方のActivityPub実装との円滑な通信を確保できます。同時に、セキュリティ標準の最前線にFedifyを位置づけています。

相互運用性テスト

RFC 9421実装は、RFC 9421署名検証をサポートする既存のActivityPub実装との相互運用性について徹底的にテストされています。

  • Mitra 4.4.0: Fedifyで生成したRFC 9421署名の検証に成功
  • Mastodon 4.4.0開発版: FedifyのRFC 9421署名検証実装をテスト(Mastodon PR #34814をご参照ください。ただし、Mastodon 4.4.0はまだリリースされていません)

これらのテストにより、他のActivityPub実装がFedifyで生成したRFC 9421署名を正常に検証できることを確認し、エコシステムが徐々に公式仕様を採用していく中で、適切なフェデレーションが保証されます。これらの実装は現在RFC 9421署名の検証をサポートしていますが、まだ自身でRFC 9421署名を生成していません。Fedifyはこのモダンスタンダードの生成と検証の両方をサポートする最初のActivityPub実装の1つとなっています。

🔍 WebFinger機能強化

専用WebFingerルックアップ

新しいContext.lookupWebFinger()メソッドにより、WebFingerデータへの直接アクセスが可能になりました。高レベルなContext.lookupObject()メソッドでは実現できない、アカウント発見とリソース解決のより細かい制御を開発者に提供します。

🛠 Context API改善

コンテキストデータの置換

新しいContext.clone()メソッドにより動的なコンテキストデータの置換が可能になり、リクエスト処理やデータフローの管理において、より高い柔軟性を提供します。特にミドルウェアの実装や複雑なリクエストルーティングを行う際に有用です。

🚀 移行時の考慮事項

後方互換性

Fedify 1.6は既存のアプリケーションとの完全な後方互換性を維持しています。新しいHTTP Message Signaturesとダブルノック機構は、コード変更なしで透過的に動作します。

Node.jsバージョン要件

重要: Fedify 1.6はNode.js環境においてNode.js 22.0.0以降を必要とします。この変更はDenoやBunランタイムを使用するアプリケーションには影響しません。現在Node.jsをご利用の方は、アップグレード前に環境がこの要件を満たしているかご確認ください。

新しいデプロイメント選択肢

新規デプロイメントでは、以下の利点からCloudflare Workersサポートの活用をご検討ください。

  • 低レイテンシのグローバルエッジデプロイメント
  • サーバーレススケーリングと自動リソース管理
  • Cloudflareサービスエコシステムとの統合

🎯 今後の展望

Fedify 1.6は、フェディバース全体での幅広い互換性を維持するというフレームワークのコミットメントを保ちながら、デプロイメント選択肢の大幅な拡張を表しています。Cloudflare Workersサポートの追加により、フェデレーティッドアプリケーションの新しいアーキテクチャパターンが開かれ、RFC 9421実装により、Fedifyは新たなActivityPubセキュリティ標準に対応し続けています。


詳細な移行ガイド、APIドキュメント、サンプルについては、Fedifyドキュメントをご覧ください。サポートとディスカッションについては、MatrixまたはDiscordのコミュニティにご参加ください。

discord.com

Join the Fedify/Hollo Discord Server!

Check out the Fedify/Hollo community on Discord - hang out with 95 other members and enjoy free voice and text chat.

@AmaseCocoa@s.amase.cc

1.6でサポートされるってことはfedify inboxでRFCテストできるようになるのか​:ablobcatpnd_oooo:

We're excited to announce the release of 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 .

🌐 Cloudflare Workers support

Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling deployment of applications at the edge.

New components

Key features

  • Seamless integration with '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 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:

  1. Primary attempt: RFC 9421 (HTTP Message Signatures) for modern implementations
  2. Fallback: Draft cavage version for legacy compatibility
  3. 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.

discord.com

Join the Fedify/Hollo Discord Server!

Check out the Fedify/Hollo community on Discord - hang out with 95 other members and enjoy free voice and text chat.

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 support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release! 🚀

@fedilug@msky.ospn.jp

のご参加ありがとうございました。
:fedilug: のブースや本、ステッカー、セミナーなどは楽しんでいただけましたでしょうか?次のFediLUGイベントは6月22日の第9回勉強会です!!ご興味がある方はぜひご参加ください。
また、OSC名古屋及び技術書典18リアル会場で頒布した『自分だけのフェディバースのマイクロブログを作ろう!』と『Thinking Penguin Magazine Vol.0』は技術書典18のオンライン通販で全国から購入可能です!この際にぜひご検討ください。

同人誌販売:
https://techbookfest.org/organization/7JepZT0g3C6qbddiLmkAwp
第9回勉強会:
https://fedilug.connpass.com/event/357642/

If you're on the fence about which driver to choose for '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:

Curious to see the results? Check out the GitHub repository!

https://github.com/dahlia/fedify-queue-benchmarks

https://fosstodon.org/@hongminhee/113247723368865290

@hongminhee@fosstodon.org · Reply to 洪 民憙 (Hong Minhee)

@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.

github.com/dahlia/fedify-queue

🎉 support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, can now run on Cloudflare Workers.

What's included:

Try 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!

npmjs.com

@fedify/fedify

An ActivityPub server framework. Latest version: 1.5.3, last published: 16 days ago. Start using @fedify/fedify in your project by running `npm i @fedify/fedify`. There are 3 other projects in the npm registry using @fedify/fedify.

@fedilug@msky.ospn.jp

明日は 📕!!
:fedilug:​ は 6月1日 (日) 11:00~17:00 に 池袋・サンシャインシティ 展示ホールD(文化会館ビル2F)で開催される にサークル出展します!
・FediLUG合同誌『Thinking Penguin Magazine Vol.0』
・ホンさん著『自分だけのフェディバースのマイクロブログを作ろう!』
それぞれ500円でご用意してお待ちしております!!

ActivityPubサーバーを構築してみたいけれど、どこから始めればよいかわからない方には、Fedifyのチュートリアル『自分だけのフェディバースのマイクロブログを作ろう!』をおすすめします。包括的でステップバイステップのガイドで、完全に機能する連合型アプリケーションの構築方法を丁寧に解説しています。フェディバースに飛び込みたい開発者にぴったりです!

zenn.dev

自分だけのフェディバースのマイクロブログを作ろう!

このチュートリアルでは、ActivityPubサーバーフレームワークであるFedifyを使用して、MastodonやMisskeyのようなActivityPubプロトコルを実装するマイクロブログ(microblog)を作成します。

@hongminhee@hollo.social

If you're interested in building your own server but don't know where to start, I recommend checking out 's 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 !

fedify.dev

Creating your own federated microblog | Fedify

In this tutorial, we will build a small microblog that implements the ActivityPub protocol, similar to Mastodon or Misskey, using Fedify, an ActivityPub server framework.

@hongminhee@hollo.social

오픈 소스 컨퍼런스 名古屋(나고야)에서 Fedify () 《나만의 聯合宇宙(연합우주) 마이크로블로그 만들기》(自分だけのフェディバースのマイクロブログを作ろう!)가 完販(완판)되었다고…!

mstdn.y-zu.org

もちもちずきん :teto_zuho: 🍆 (@Yohei_Zuho@mstdn.y-zu.org)

OSC名古屋、Fedify本完売した(6冊)

@fedilug@msky.ospn.jp

本日はオープンソースカンファレンス名古屋( )当日です!
吹上駅から徒歩5分ほどの中小企業振興会館、第にファッション展示場で
はブース出展、セミナーでのLT大会を開催予定です!
ステッカー、同人誌用意してお待ちしています!!

今週末開催される、 では ブースにて、
・有志8人による執筆のThinking Penguin Magazine Vol.0(500円)
・和条門さん(
@naoki_wjm@k.my-sky.blue )による『さばかんライフ!』(1000円)
・ホンさん(
@hongminhee@hollo.social )による『自分だけのフェディバースのマイクロブログを作ろう!』(500円)
も頒布いたします!
そのほかにもステッカーや各種チラシも扱っておりますので、ぜひ足をお運びください!!

@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!

We're planning to reorganize our labels to better reflect '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 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?

Check out the full proposal: https://github.com/fedify-dev/fedify/issues/238.

github.com

Reorganize repository labels to better fit Fedify project structure · Issue #238 · fedify-dev/fedify

Problem Currently, the Fedify repository uses GitHub's default labels, which don't reflect the specific needs and structure of the Fedify project. These generic labels make it difficult to: Categor...

@hongminhee@hackers.pub
@fedify@hollo.social · Reply to Antolius

@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 would generate releases like:

  • First push: 1.6.0-pr.123.1
  • Second push: 1.6.0-pr.123.2
  • And so on…

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.

github.com

Automated pull request builds for JSR and npm · Issue #236 · fedify-dev/fedify

Set up a CI pipeline that automatically publishes pre-release versions to JSR and npm for each pull request. This enables developers to test vocabulary extensions and other changes before they're m...

@fedify@hollo.social · Reply to Antolius

@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 would generate releases like:

  • First push: 1.6.0-pr.123.1
  • Second push: 1.6.0-pr.123.2
  • And so on…

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.

github.com

Automated pull request builds for JSR and npm · Issue #236 · fedify-dev/fedify

Set up a CI pipeline that automatically publishes pre-release versions to JSR and npm for each pull request. This enables developers to test vocabulary extensions and other changes before they're m...

@antolius@mastodon.social · Reply to Fedify: ActivityPub server framework

@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?)

While 's API provides comprehensive support for 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 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.

unstable.fedify.dev

Vocabulary | Fedify

The Activity Vocabulary is a collection of type-safe objects that represent the Activity Vocabulary and the vendor-specific extensions. This section explains the key features of the objects.

We inadvertently published @fedify/fedify 1.6.0 and @fedify/cli 1.6.0 to npm before they were ready for release. (Note: 1.6.0 was not released to JSR.)

Both versions have been deprecated and unpublished. Please avoid using these versions.

Our next minor release will be version 1.6.1, which will include the intended changes and fixes.

We apologize for any inconvenience this may have caused.