A milestone worth celebrating—#Fedify just hit 100+ releases! From day one, we've been committed to building a robust #ActivityPub framework, and each release has brought us closer to that goal. Here's to many more releases as we continue growing the #fediverse together! #fedidev
fedidev
BotKit 0.1.1 is out!
This security update fixes a message visibility bug where direct/followers-only replies to bots were unintentionally forwarded to bot followers. Upgrade recommended. Download at JSR:
deno add jsr:@fedify/botkit@^0.1.1
Build your own #fediverse server with #Fedify!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
✨ Key features
Complete protocol support including WebFinger, HTTP Signatures, and NodeInfo
Enhanced interoperability with Object Integrity Proofs and Linked Data Signatures
Type-safe Activity Vocabulary API to prevent development mistakes
Reliable delivery with automatic retries and message queues
Full observability through OpenTelemetry integration
Multiple backend support: Redis, PostgreSQL, AMQP
Seamless integration with popular web frameworks: Express, Hono, Fresh, SvelteKit
Comprehensive logging and tracing
Debug ActivityPub in real-time with ephemeral inbox server
Inspect ActivityPub objects and actors with lookup tool
Tunnel your local server for development
🚀 Runtime support
📚 Easy to learn
Extensive docs
Step-by-step tutorials
Community support via Matrix & Discord
Available under the #MIT license—free and open source!
We're excited to announce two major features coming in #Fedify 1.5.0, focused on giving you more control over domain names in your federated apps:
Separate WebFinger Host from Server Origin
Want different domains for your WebFinger handles and server URIs? Fedify 1.5.0 will let you use domains like @alice@example.com as fediverse handles while serving content from https://ap.example.com. This gives you more flexibility in how you structure your federated services.
Need to ensure consistent URLs across your infrastructure? The new canonical origin support lets you explicitly set your server's authoritative domain. This is particularly useful when running behind reverse proxies or load balancers—no more unexpected URLs generated from internal hostnames.
These features represent our ongoing commitment to making Fedify more flexible and production-ready.
Can't wait to try these features? You can experiment with them today using our unstable release v1.5.0-dev.680+562e3dc0 (JSR & npm). Keep in mind that this is an unstable release intended for testing—use it in production at your own risk.
Otherwise, stay tuned for the stable Fedify 1.5.0 release!
We're considering adding custom background task support to #Fedify 1.5.0.
Want to use Fedify's worker system for your own background tasks? We're exploring ways to let you register and process custom tasks alongside #ActivityPub jobs.
Check out the proposal: https://github.com/fedify-dev/fedify/issues/206.
Key considerations:
Should this be part of Fedify's scope?
Quick API extension vs complete worker architecture redesign
Integration with existing task queue systems
We'd love to hear your thoughts! Do you need this feature? How would you use it? Share your feedback in the issue thread.
I just discovered why some of my followers from larger #Mastodon instances (like mastodon.social) would mysteriously unfollow me after a while!
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. 😊
📣 Exciting news! Fedify CLI is now available via Homebrew!
If you're using #Homebrew on macOS or #Linuxbrew on Linux, you can now install our CLI toolchain with a simple command:
brew install fedify
This makes it even easier to get started with building your federated server app. Try it out and let us know what you think!
I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:
Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.
Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).
Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.
These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.
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.
Matrix space: #fedify:matrix.org
Discord server: https://discord.gg/bhtwpzURwd
Feel free to join either community based on your preference. Both channels have active discussions about Fedify and federation topics.
We're excited to introduce emoji reactions in the upcoming #BotKit 0.2.0 release!
With the new Message.react() method, your bot can now react to messages using standard Unicode #emojis:
await message.react(emoji`👍`);
#Custom_emoji support is also included, allowing your bot to react with server-specific emojis:
const emojis = bot.addCustomEmojis({ // Use a remote image URL: yesBlob: { url: "https://cdn3.emoji.gg/emojis/68238-yesblob.png", mediaType: "image/png", }, // Use a local image file: noBlob: { file: `${import.meta.dirname}/emojis/no_blob.png`, mediaType: "image/webp", },});await message.react(emojis.yesBlob);
Reactions can be removed using the AuthorizedReaction.unreact() method:
const reaction = await message.react(emoji`❤️`);await reaction.unreact();
Want to try these features now? You can install the development version from JSR today:
deno add jsr:@fedify/botkit@0.2.0-dev.84+c997c6a6
We're looking forward to seeing how your bots express themselves with this new feature!
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.tsimport { 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.tsimport { createFederationBuilder } from "@fedify/fedify";export const builder = createFederationBuilder<AppContext>();// other files can import and configure this builder...
// actors.tsimport { builder } from "./builder.ts";import { Person } from "@fedify/fedify";builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => { // Actor implementation});
// inbox.tsimport { builder } from "./builder.ts";import { Follow } from "@fedify/fedify";builder.setInboxListeners("/users/{handle}/inbox", "/inbox") .on(Follow, async (ctx, follow) => { // Follow handling });
// main.ts — Only create the Federation instance at startupimport { builder } from "./builder.ts";// Build the Federation object with actual dependenciesexport 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:
# Denodeno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01# Node.jsnpm add @fedify/fedify@1.6.0-dev.777# Bunbun add @fedify/fedify@1.6.0-dev.777