@fedify@hollo.social · 8 following · 641 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:
@fedify@hollo.social
Hello, #fediverse! It's the official fedi account of the Fedify, an #ActivityPub server framework!
@liaizon@social.wake.st
Theres a new interview with @hongminhee (of @fedify, @hollo, and now #Ghost fame). It's in with Korean subtitles but quite readable with YouTube's autogenerated English subs.
https://www.youtube.com/watch?v=sqxR8zscSDo
https://hollo.social/@hongminhee/0195a85a-6a29-71fa-a60f-3e79c1295b05 #fediverse #fedidev
@fedify@hollo.social · Reply to silverpill's post
@silverpill You've touched on a good point. Since Fedify abstracts the message queue, the performance characteristics depend on the backend you're using (Redis, PostgreSQL, AMQP, etc.). Some backends might support batch operations, but we need to maintain compatibility with all supported queue implementations, which often means separate write operations.
Your concern about sequential processing is valid. Our new approach actually addresses this by maintaining individual recipient messages in the second stage, so slow servers don't block others.
What we've found is that maintaining the (activity, single recipient) pattern in the final queue gives you the best of both worlds: fast API responses via the fan-out queue, plus independent delivery processing. This way, a slow server only affects its own delivery task.
@fedify@hollo.social · Reply to silverpill's post
@silverpill The bottleneck happens because for each recipient, we need to:
When you have thousands of followers, these operations add up quickly and block the HTTP response. With fan-out, we only do this once during the request.
What issues are you having with your current fan-out implementation? We're always looking to improve ours.
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
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:
Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient listThe benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower countsFor 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// Example with custom fanout setting
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "skip" } // Directly enqueues individual messages
);
This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!
For more details, check out our docs.
What other #performance optimizations would you like to see in future Fedify releases?
@fedify@hollo.social
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:
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!
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
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:
Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient listThe benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower countsFor 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// Example with custom fanout setting
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "skip" } // Directly enqueues individual messages
);
This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!
For more details, check out our docs.
What other #performance optimizations would you like to see in future Fedify releases?
@fedify@hollo.social
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:
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!
@fedify@hollo.social
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:
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!
@sakurasubnet@bumscode.com
Is the world in need of a federated Craigslist/Kleinanzeigen platform? I am currently thinking about a project to dig into #fediverse development and learning #golang or stay with #deno and using #fedify.
EDIT: There is already something like that on the fediverse! It's called Flohmarkt. Thanks for the comments mentioning that!
https://codeberg.org/flohmarkt/flohmarkt
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
Fedifyとは？Fedifyは、ActivityPubベースのフェデレーションサーバーフレームワークで、開発者が分散型ソーシャルネットワークである#フェディバース（#fediverse）にアプリケーションを簡単に統合できるよう支援します。複雑なActivityPubプロトコルの実装を簡素化し、開発時間を大幅に短縮します。MITライセンスの下で提供されるオープンソースプロジェクトです。
すでに様々なプロジェクトがFedifyを活用しています：
ActivityPubの実装をご検討中の方や、Fedifyプロジェクトとの協力にご興味のある方は、ぜひご連絡ください：
お客様の要件と目標に合わせたカスタマイズされた協力の可能性を一緒に探りましょう。
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
Fedify란?Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
ActivityPub 구현을 고려 중이시거나, Fedify 프로젝트와 협력하고 싶으시다면 연락 주세요:
귀사의 요구사항과 목표에 맞는 맞춤형 협력 방안을 함께 모색하겠습니다.
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
Fedifyの関連プロジェクトをご紹介したいと思います。ActivityPubアプリケーション開発をより簡単にするツール群です：
Fedify（@fedify）はActivityPubやその他のフェディバース標準を活用する連合型サーバーアプリケーションを構築するためのTypeScriptライブラリです。Activity Vocabularyの型安全なオブジェクト、WebFingerクライアント・サーバー、HTTP Signaturesなどを提供し、ボイラープレートコードを削減してアプリケーションロジックに集中できるようにします。
Hollo（@hollo）はFedifyで動作するお一人様用マイクロブログサーバーです。個人向けに設計されていますが、ActivityPubを通じて完全に連合化されており、フェディバース全体のユーザーと交流することができます。HolloはMastodon互換APIを実装しているため、独自のウェブインターフェースがなくても、ほとんどのMastodonクライアントと互換性があります。
Holloはまた、正式リリース前の最新Fedify機能をテストする実験場としても活用されています。
BotKit（@botkit）は私たちの最も新しいメンバーで、ActivityPubボットを作成するために特別に設計されたフレームワークです。従来のMastodonボットとは異なり、BotKitはプラットフォーム固有の制限（文字数制限など）に縛られない独立したActivityPubサーバーを作成します。
BotKitのAPIは意図的にシンプルに設計されており、単一のTypeScriptファイルで完全なボットを作成できます！
これら三つのプロジェクトはすべて@fedify-dev GitHubオーガニゼーションでオープンソースとして公開されています。それぞれ異なる目的を持っていますが、ActivityPub開発をより身近にし、フェディバースのエコシステムを拡大するという共通の目標を共有しています。
これらのプロジェクトを試してみたり、開発に貢献したりすることに興味がある場合は、以下をご覧ください：
#Fedify #ActivityPub #フェディバース #fediverse #Hollo #BotKit #fedidev
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
#Fedify 자매 프로젝트들을 소개해 드리고자 합니다. #ActivityPub 애플리케이션 개발을 더 쉽게 만들어주는 관련 도구들입니다:
Fedify(@fedify)는 ActivityPub와 다른 #연합우주(#fediverse) 표준을 기반으로 연합 서버 애플리케이션을 구축하기 위한 #TypeScript 라이브러리입니다. Activity Vocabulary를 위한 타입 안전한 객체, WebFinger 클라이언트·서버, HTTP Signatures 등를 제공하여 반복적인 코드를 줄이고 애플리케이션 로직에 집중할 수 있게 해줍니다.
Hollo(@hollo)는 Fedify로 구동되는 1인 사용자용 마이크로블로깅 서버입니다. 1인 사용자를 위해 설계되었지만, ActivityPub를 통해 완전히 연합되어 연합우주 전체의 사용자들과 상호작용할 수 있습니다. Hollo는 Mastodon 호환 API를 구현하여 자체 웹 인터페이스 없이도 대부분의 Mastodon 클라이언트와 호환됩니다.
Hollo는 또한 정식 출시 전에 최신 Fedify 기능을 테스트하는 실험장으로도 활용되고 있습니다.
BotKit(@botkit)은 저희의 가장 새로운 구성원으로, ActivityPub 봇을 만들기 위해 특별히 설계된 프레임워크입니다. 전통적인 Mastodon 봇과 달리, BotKit은 플랫폼별 제한(글자 수 제한 등)에 구애받지 않는 독립적인 ActivityPub 서버를 만듭니다.
BotKit의 API는 의도적으로 단순하게 설계되어 단일 TypeScript 파일로 완전한 봇을 만들 수 있습니다!
세 프로젝트 모두 @fedify-dev GitHub 조직에서 오픈 소스로 공개되어 있습니다. 각기 다른 목적을 가지고 있지만, ActivityPub 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
@fedify@hollo.social
We'd like to introduce the #Fedify project family—a set of related tools that make building #ActivityPub applications more accessible:
Fedify (@fedify) is a #TypeScript library for building federated server applications powered by ActivityPub and other #fediverse standards. It provides type-safe objects for Activity Vocabulary, WebFinger client/server, HTTP Signatures, and more—eliminating boilerplate code so you can focus on your application logic.
Hollo (@hollo) is a single-user microblogging server powered by Fedify. While designed for individual users, it's fully federated through ActivityPub, allowing interaction with users across the fediverse. #Hollo implements Mastodon-compatible APIs, making it compatible with most Mastodon clients without needing its own web interface.
Hollo also serves as our testing ground for bleeding-edge Fedify features before they're officially released.
BotKit (@botkit) is our newest family member—a framework specifically designed for creating ActivityPub bots. Unlike traditional Mastodon bots, #BotKit creates standalone ActivityPub servers that aren't constrained by platform-specific limitations (like character counts).
BotKit's API is intentionally simple—you can create a complete bot in a single TypeScript file!
All three projects are open source and hosted under the @fedify-dev GitHub organization. While they serve different purposes, they share common goals: making ActivityPub development more accessible and expanding the fediverse ecosystem.
If you're interested in trying any of these projects or contributing to their development, check out:
@fedify@hollo.social · Reply to Fedify: an ActivityPub server framework's post
We've been working on adding custom background task support to #Fedify as planned for version 1.5.0. After diving deeper into implementation, we've realized this is a more substantial undertaking than initially anticipated.
The feature would require significant API changes that would be too disruptive for a minor version update. Therefore, we've decided to postpone this feature to Fedify 2.0.0.
This allows us to:
We believe this decision will result in a more stable and well-designed feature that better serves your needs. However, some smaller improvements from our work that don't require API changes will still be included in Fedify 1.5.0 or subsequent minor updates.
We appreciate your understanding and continued support.
If you have specific use cases or requirements for background task support, please share them in our GitHub issue. Your input will help shape this feature for 2.0.0.
@fedify@hollo.social
What is Fedify?#Fedify is an #ActivityPub-based federated server framework that helps developers easily integrate their applications with the #fediverse, a decentralized social network. It simplifies the complex implementation of the ActivityPub protocol, significantly reducing development time. Fedify is an open-source project available under the MIT license.
Various projects are already leveraging Fedify:
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
We're excited to explore customized collaboration opportunities that align with your requirements and goals.
@fedify@hollo.social
Patch releases for #Fedify versions 1.0.21, 1.1.18, 1.2.18, 1.3.14, and 1.4.7 are now available. These updates address two important bugs across all supported release lines:
acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!base-url parameter of followers collections.We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
@fedify@hollo.social · Reply to Max's post
@PossiblyMax Great question about our queue implementation! Fedify doesn't actually create separate physical queues, but rather uses a single logical queue where each message contains its own destination information.
For resource management, we generally rely on the underlying queue implementation (Redis, PostgreSQL, etc.) to handle concurrent processing efficiently. Since version 1.0.0, we've introduced ParallelMessageQueue which processes multiple messages concurrently with a configurable worker count—usually set close to your CPU core count for IO-bound operations.
We don't spin up new queues dynamically; instead, we focus on making the message processing scalable. You can control the parallelism level when using ParallelMessageQueue, and for high-volume instances, you can horizontally scale by running multiple worker processes that connect to the same shared queue backend.
This approach keeps the architecture simpler while still allowing for good throughput and resource utilization that can scale with your instance size.
@fedify@hollo.social · Reply to Max's post
@PossiblyMax Great question about our queue implementation! Fedify doesn't actually create separate physical queues, but rather uses a single logical queue where each message contains its own destination information.
For resource management, we generally rely on the underlying queue implementation (Redis, PostgreSQL, etc.) to handle concurrent processing efficiently. Since version 1.0.0, we've introduced ParallelMessageQueue which processes multiple messages concurrently with a configurable worker count—usually set close to your CPU core count for IO-bound operations.
We don't spin up new queues dynamically; instead, we focus on making the message processing scalable. You can control the parallelism level when using ParallelMessageQueue, and for high-volume instances, you can horizontally scale by running multiple worker processes that connect to the same shared queue backend.
This approach keeps the architecture simpler while still allowing for good throughput and resource utilization that can scale with your instance size.
@fedify@hollo.social
Just released @fedify/markdown-it-mention v0.3.0! This update adds support for bare handles (e.g., @username without domain) with the new localDomain option, allowing you to specify the domain for these shortened mentions.
Install via npm, Bun, or Deno:
npm add @fedify/markdown-it-mention@0.3.0
bun add @fedify/markdown-it-mention@0.3.0
deno add jsr:@fedify/markdown-it-mention@0.3.0
@julian@community.nodebb.org · Reply to Fedify: an ActivityPub server framework's post
@fedify@hollo.social that's interesting! I didn't even consider that, but it makes a lot of sense.
@fedify@hollo.social · Reply to Julian Fietkau's post
@julian They are no deduplicated, but no worries! Even if the same activity is sent to the same recipient more than once, only the first one is received and rest of them are ignored.
@fedify@hollo.social
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:
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!
@bthj@hachyderm.io
Is any one looking into / thinking about publishing static site content via #activitypub , as @mapache has described in:
https://maho.dev/2024/11/a-guide-to-implementing-activitypub-in-a-static-site-or-any-website-part-7/
- but utilising @fedify ?
Content from static site generators like #faircamp and #hyper8 by @freebliss is easy to host, long term, but while one would be inclined to host more dynamic services, it would be great to have a kind of (general purpose) layer that could pick up newly published, static content and notify the #fediverse
🌺🎗️@mola@uri.life
fedify로 미디어위키 봇 있어도 괜찮을지도..
🍆@Yohei_Zuho@mstdn.y-zu.org
Fedify使ってなんかできないかなと考えている
@liaizon@social.wake.st
I just finished listening to @guu interview @hongminhee about development of @fedify and general interworkings of the #fediverse on the #SoftwareSessions podcast. It is a highly recommended listen! Was so good to finally hear Hong's voice after the last year or so of reading their words almost daily
https://softwaresessions.com/episodes/activitypub
via https://hollo.social/@hongminhee/01954bc9-ca93-70a3-a696-245917cd29a5
@julian@fietkau.social · Reply to julian's post
@julian@community.nodebb.org Can I confess something?
When @fedify first came out, I was worried that everyone might abandon their ActivityPub implementations for the convenience of "letting someone else handle it" and that the fediverse could run into a Chrome-esque engine monopoly. 😱
I'm honestly surprised how few projects rely on Fedify to this day. Turns out people have too much fun sticking their hands into the pipes after all! 😄
@julian@community.nodebb.org · Reply to Fedify: an ActivityPub server framework's post
@fedify@hollo.social ActivityPub as a Service... Closer and closer every day!
🍆@Yohei_Zuho@mstdn.y-zu.org
【輪読会やってみます！】
#FediLUG 
輪読会📖第零弾として #fedify の開発者である
Hong Minhee (洪 民憙) @hongminhee さんの著書『自分だけのフェディバースのマイクロブログを作ろう！』の輪読会を行います！
この機会に #Fedify を使用して皆さんで #ActivityPub や #TypeScript などの知識を強化しませんか？
本はGitHubから無料で読むことができます：
https://github.com/dahlia/fedify-microblog-tutorial-ja
参加：
https://fedilug.connpass.com/event/348240/
🍆@Yohei_Zuho@mstdn.y-zu.org
輪読会第一弾として
「〜自分でActivityPub対応SNSを作ってみよう〜『自分だけのフェディバースのマイクロブログを作ろう！』輪読会」
https://github.com/dahlia/fedify-microblog-tutorial-ja
を開きたい
🍆@Yohei_Zuho@mstdn.y-zu.org
Fedify本の輪読会がおもしろいかもしれない