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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.ts
import { 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.ts
import { createFederationBuilder } from "@fedify/fedify";
export const builder = createFederationBuilder<AppContext>();
// other files can import and configure this builder...
// actors.ts
import { builder } from "./builder.ts";
import { Person } from "@fedify/fedify";
builder.setActorDispatcher("/users/{handle}", async (ctx, handle) => {
// Actor implementation
});
// main.ts — Only create the Federation instance at startup
import { builder } from "./builder.ts";
// Build the Federation object with actual dependencies
export 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:
# Deno
deno add jsr:@fedify/fedify@1.6.0-dev.777+1206cb01
# Node.js
npm add @fedify/fedify@1.6.0-dev.777
# Bun
bun add @fedify/fedify@1.6.0-dev.777
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.
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.
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.
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.
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.
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.
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.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Don't build #ActivityPub from scratch! It's complex. See why using the #Fedify framework is the smarter way to develop for the fediverse in my new post:
So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!
But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.
That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.
This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.
Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently
At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.
First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.
Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:
Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}
Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}
Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.
Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.
Challenge #2: Discovery & Identity—Finding Your Actors
Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.
Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.
// Example: Define how to find actorsfederation.setActorDispatcher( "/users/{username}", async (ctx, username) => { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!
Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections
Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.
Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.
Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.
Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.
// Configure Fedify with a persistent queue (e.g., Deno KV)const federation = createFederation({ queue: new DenoKvMessageQueue(/* ... */), // ...});// Sending is now reliable and non-blockingawait ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);
Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.
Challenge #6: Interoperability & Maintenance—Playing Nicely with Others
The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.
Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().
Challenge #7: Developer Experience—Actually Building Your App
Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.
Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.
You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.
For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:
Will first show progress messages and then output the structured representation of the actor, similar to this:
// Output of fedify lookup command (shows parsed object structure)Person { id: URL "https://fedify-blog.deno.dev/users/fedify-example", name: "Fedify Example Blog", published: 2024-03-03T13:18:11.857Z, // Simplified timestamp summary: "This blog is powered by Fedify, a fediverse server framework.", url: URL "https://fedify-blog.deno.dev/", preferredUsername: "fedify-example", publicKey: CryptographicKey { id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key", owner: URL "https://fedify-blog.deno.dev/users/fedify-example", publicKey: CryptoKey { /* ... CryptoKey details ... */ } }, // ... other properties like inbox, outbox, followers, endpoints ...}
This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.
Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:
$ fedify inbox✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/✔ Sent follow request to @<some_test_account>@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@<unique_id>.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://<unique_id>.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://<unique_id>.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://<unique_id>.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/
You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inboxonly prints a summary table to your console indicating that a request was received:
Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.
The Fedify Inbox web UI is where you view detailed activity information.
When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.
Conclusion: Build Features, Not Plumbing
Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.
Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!
Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Fetching remote #ActivityPub objects or actors often involves handling #WebFinger lookups, content negotiation, and then parsing potentially untyped JSON.
With #Fedify, it's much simpler: use Context.lookupObject(). Pass it a URI (e.g., https://instance.tld/users/alice) or a handle (e.g., @alice@instance.tld), and Fedify handles the lookup and content negotiation automatically.
The real power comes from the return value: a type-safe Activity Vocabulary object, not just raw JSON. This allows you to confidently access properties and methods directly. For example, you can safely traverse account moves using .getSuccessor() like this:
let actor = await ctx.lookupObject("@alice@instance.tld");
while (isActor(actor)) {
const successor = await actor.getSuccessor();
if (successor == null) break;
actor = successor;
}
// actor now holds the latest account after moves
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
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:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
This is a significant milestone for our project, and we're deeply grateful to @johnonolan and the entire Ghost team for their support and recognition of our work in the #ActivityPub ecosystem.
Ghost's social web integration built on #Fedify is a perfect example of how open standards can connect different publishing platforms in the fediverse. Their backing over the past months has been invaluable, and this formal sponsorship will help ensure Fedify remains sustainable as we continue to develop and improve the framework.
If you're building with ActivityPub or interested in federated applications, please consider joining Ghost in supporting open source development through our Open Collective:
Every contribution, no matter the size, helps us maintain and enhance the tools that make the fediverse more accessible to developers. Thank you for being part of this journey with us! ❤️
Ghost's social web integration is built on the fantastic work of @hongminhee and the Fedify.dev framework.
We've been backing work on the project for 6 months or so, and now we're thrilled to be formal sponsor of the project on Open Collective!
If you're building with Fedify and ActivityPub, please consider joining us to keep helping to make great open source work sustainable ❤️ Every little helps
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
I had trouble finding good resources explaining ActivityPub, but after reading through the Fedify docs from start to finish, I feel like I've actually digested it.
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
We're excited to announce the release of Fedify 1.5.0! This version brings several significant improvements to performance, configurability, and developer experience. Let's dive into what's new:
Two-Stage Fan-out Architecture for Efficient Activity Delivery
#Fedify now implements a smart fan-out mechanism for delivering activities to large audiences. This change is particularly valuable for accounts with many followers. When sending activities to many recipients, Fedify now creates a single consolidated message containing the activity payload and recipient list, which a background worker then processes to re-enqueue individual delivery tasks.
This architectural improvement delivers several benefits: Context.sendActivity() returns almost instantly even with thousands of recipients, memory consumption is dramatically reduced by avoiding payload duplication, UI responsiveness improves since web requests complete quickly, and the system maintains reliability with independent retry logic for each delivery.
For specific requirements, we've added a new fanout option with three settings:
// Configuring fan-out behavior
await ctx.sendActivity(
{ identifier: "alice" },
recipients,
activity,
{ fanout: "auto" } // Default: automatic based on recipient count
// Other options: "skip" (never use fan-out) or "force" (always use fan-out)
);
Canonical Origin Support for Multi-Domain Setups
You can now explicitly configure a canonical origin for your server, which is especially useful for multi-domain setups. This feature allows you to set different domains for WebFinger handles and #ActivityPub URIs, configured through the new origin option in createFederation(). This enhancement prevents unexpected URL construction when requests bypass proxies and improves security by ensuring consistent domain usage.
const federation = createFederation({
// Use example.com for handles but ap.example.com for ActivityPub URIs
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
// Other options...
});
Optional Followers Collection Synchronization
Followers collection synchronization (FEP-8fcf) is now opt-in rather than automatic. This feature must now be explicitly enabled through the syncCollection option, giving developers more control over when to include followers collection digests. This change improves network efficiency by reducing unnecessary synchronization traffic.
Key format support has been expanded for better interoperability. Fedify now accepts PEM-PKCS#1 format in addition to PEM-SPKI for RSA public keys. We've added importPkcs1() and importPem() functions for additional flexibility, which improves compatibility with a wider range of ActivityPub implementations.
Improved Key Selection Logic
The key selection process is now more intelligent. The fetchKey() function can now select the public key of an actor if keyId has no fragment and the actor has only one public key. This enhancement simplifies key handling in common scenarios and provides better compatibility with implementations that don't specify fragment identifiers.
New Authorization Options
Authorization handling has been enhanced with new options for the RequestContext.getSignedKey() and getSignedKeyOwner() methods. This provides more flexible control over authentication and authorization flows. We've deprecated older parameter-based approaches in favor of the more flexible method-based approach.
Efficient Bulk Message Queueing
Message queue performance is improved with bulk operations. We've added an optional enqueueMany() method to the MessageQueue interface, enabling efficient queueing of multiple messages in a single operation. This reduces overhead when processing batches of activities. All our message queue implementations have been updated to support this new operation:
If you're using any of these packages, make sure to update them alongside Fedify to take advantage of the more efficient bulk message queueing.
CLI Improvements
The Fedify command-line tools have been enhanced with an improved web interface for the fedify inbox command. We've added the Fedify logo with the cute dinosaur at the top of the page and made it easier to copy the fediverse handle of the ephemeral actor. We've also fixed issues with the web interface when installed via deno install from JSR.
Additional Improvements and Bug Fixes
Updated dependencies, including @js-temporal/polyfill to 0.5.0 for Node.js and Bun
Fixed bundler errors with uri-template-router on Rollup
Improved error handling and logging for document loader when KV store operations fail
Added more log messages using the LogTape library
Internalized the multibase package for better maintenance and compatibility
For the complete list of changes, please refer to the changelog.
To update to Fedify 1.5.0, run:
# For Deno
deno add jsr:@fedify/fedify@1.5.0
# For npm
npm add @fedify/fedify@1.5.0
# For Bun
bun add @fedify/fedify@1.5.0
Thank you to all contributors who helped make this release possible!
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
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. 😊
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Excited to see the #FediLUG (#Fediverse Linux Users Group) in #Japan organizing a reading club for our Creating your own federated microblog tutorial! 🎉 Their first session is coming up, where participants will work through creating their own #ActivityPub-compatible microblog using #Fedify. Thanks for spreading the word about Fedify in Japan! 🇯🇵
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
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:
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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 (@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 (@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 (@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:
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
A background worker then processes this message and re-enqueues individual delivery tasks
The benefits are substantial:
Context.sendActivity() returns almost instantly, even for massive follower counts
Memory usage is dramatically reduced by avoiding payload duplication
UI responsiveness improves since web requests complete quickly
The same reliability for individual deliveries is maintained
For 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
ALT text detailsFlowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery.
The current approach shows:
1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck)
2. These individual messages are queued in outbox
3. Messages are processed independently
4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The fan-out approach shows:
1. sendActivity creates a single message with multiple recipients
2. This single message is queued in fan-out queue (marked as providing quick response)
3. A background worker processes the fan-out message
4. The worker re-enqueues individual messages in outbox
5. These are then processed independently
6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server)
The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
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는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
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는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
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는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
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
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는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
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:
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 (@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 (@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:
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 개발을 더 접근하기 쉽게 만들고 연합우주 생태계를 확장한다는 공통된 목표를 공유합니다.
이러한 프로젝트를 사용해보거나 개발에 기여하는 데 관심이 있으시다면, 다음을 확인해보세요:
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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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:
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:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
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.
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:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
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.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
Getting back to #Fedify development today! Working on optimizing the outgoing activity queue to improve response times. Currently focusing on reducing latency when sending posts to large follower counts—should make the whole publishing experience feel much snappier.
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:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
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.
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:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
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.
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:
Design a more robust and flexible worker architecture
Ensure better integration with existing task queue systems
Properly document the new APIs without rushing
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 is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
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:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
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:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
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:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
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:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
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:
Fixed a WebFinger handler bug that prevented matching acct: URIs with port numbers in the host. Thanks to @revathskumar for reporting and debugging the bug!
Resolved server errors that occurred when invalid URLs were passed to the base-url parameter of followers collections.
We recommend all users upgrade to these latest patch versions for improved stability and federation compatibility.
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
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
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
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
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:
Fast servers get messages delivered promptly
Slow servers don't delay delivery to others
Failed deliveries can be retried independently
Your UI remains responsive while deliveries happen in the background
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!
ALT text detailsA flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
Fedify는 #ActivityPub 기반 연합형 서버 프레임워크로, 개발자들이 분산형 소셜 네트워크인 #연합우주(#fediverse)에 애플리케이션을 쉽게 통합할 수 있도록 돕습니다. 복잡한 ActivityPub 프로토콜 구현을 단순화하여 개발 시간을 크게 단축시킵니다. MIT 라이선스 하에 제공되는 오픈 소스 프로젝트입니다.
💼 Fedify를 활용하는 프로젝트들
다양한 프로젝트들이 이미 Fedify를 활용하고 있습니다:
Ghost: 수백만 사용자를 보유한 전문적인 오픈 소스(MIT 라이선스) 퍼블리싱 플랫폼으로, Fedify의 주요 후원사이자 파트너입니다.
Fedify is looking for new partnership opportunities!
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.
💼 Projects using Fedify
Various projects are already leveraging Fedify:
Ghost: A professional publishing platform with millions of users, open source under MIT license, and a major sponsor and partner of Fedify.
Hollo: A lightweight microblogging platform for individual users (open source, AGPL-3.0)
Hackers' Pub: A fediverse blogging platform for software engineers (open source, AGPL-3.0)
Encyclia: A bridge service that makes ORCID academic records available via ActivityPub
🚀 Value provided by Fedify
80% development time reduction: Utilize a proven framework instead of complex ActivityPub implementation
Immediate fediverse compatibility: Instant compatibility with various fediverse services including Mastodon, Misskey, Pleroma, Pixelfed, PeerTube, etc.
Expert technical support: Direct support from ActivityPub and Federation protocol experts
Custom development: Tailored feature development to meet your specific requirements
🤝 Potential collaboration models
Custom consulting and integration support: Professional assistance for integrating Fedify into your platform
Custom feature development: Development and implementation of specific features needed for your platform
Long-term technical partnership: Long-term collaboration for continuous development and maintenance
🌟 Benefits of collaborating with Fedify
Technical advantage: Save time and resources compared to in-house implementation
Brand image: Enhance corporate image through support of the open-source ecosystem
Entry to decentralized social networks: Easily participate in the fediverse ecosystem
Competitive edge: Strengthen product competitiveness through social features
📩 Interested?
If you're considering implementing ActivityPub or wish to collaborate with the Fedify project, please get in touch:
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
I talked about #ActivityPub and #Fedify on @guu's wonderful podcast, Software Sessions. I'm embarrassed by my poor English, but if you're interested, please listen!
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
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 (@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:
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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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 (@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:
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 (@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 (@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 (@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 (@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 (@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 (@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:
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 (@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 (@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 (@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 (@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 (@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 (@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 (@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:
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 (@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:
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 (@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:
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
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!
ALT text detailsSeparating WebFinger host from the server origin
This API is available since Fedify 1.5.0.
Sometimes you may want to use different domain names for WebFinger handles (i.e., fediverse handles) and the server origin. For example, you may want to use https://ap.example.com/actors/alice as an actor URI but want to use @alice@example.com as its fediverse handle.
In such cases, you can set the handleHost different from the webOrigin in the origin option. The handleHost is used to construct the WebFinger handles, and the webOrigin is used to construct the URLs in the Context object:
const federation = createFederation({
origin: {
handleHost: "example.com",
webOrigin: "https://ap.example.com",
},
});
NOTE
Even if you set the handleHost different from the webOrigin, the other fediverse handle with the same domain name as the webOrigin will still be recognized.
In the above example, two fediverse handles are recognized as the same:
• @alice@example.com
• @alice@ap.example.com
ALT text detailsExplicitly setting the canonical origin
This API is available since Fedify 1.5.0.
Or you can explicitly set the canonical origin of the server by passing the origin option to the createFederation() function. The origin option is either a string or a FederationOrigin object, which consists of two fields: handleHost and webOrigin.
For example, if you want to set the canonical origin to https://example.com, you can pass the string:
const federation = createFederation({
origin: "https://example.com",
});
NOTE
The origin option has to include the leading https:// or http:// scheme.
Such a configuration leads the constructed URLs using Context to use the canonical origin instead of the origin from the incoming HTTP requests, which avoids constructing unexpected URLs when a request bypasses a reverse proxy or a load balancer.
CAUTION
For example, suppose that your federated server (upstream) is accessible at the http://1.2.3.4:8000 and your load balancer (downstream) is accessible at the https://example.com and forwards the requests to the upstream server. In this case, you should set the canonical origin to https://example.com to construct the correct URLs. Otherwise, when some malicious actor directly sends a request to the upstream server, the constructed URLs will start with http://1.2.3.4:8000 instead of https://example.com, which can lead to security issues.
Although the vast majority of ActivityPub software encodes RSA public keys in PEM-SPKI format, some software encodes RSA public keys in PEM-PKCS#1 format (see: https://github.com/fedify-dev/hollo/pull/109#issuecomment-2662591619). Fedify currently only accepts PEM-SPKI format, so it needs to accept PEM-PKCS#1 format as well for better interoperability.
Although the vast majority of ActivityPub software encodes RSA public keys in PEM-SPKI format, some software encodes RSA public keys in PEM-PKCS#1 format (see: https://github.com/fedify-dev/hollo/pull/109#issuecomment-2662591619). Fedify currently only accepts PEM-SPKI format, so it needs to accept PEM-PKCS#1 format as well for better interoperability.
Although the vast majority of ActivityPub software encodes RSA public keys in PEM-SPKI format, some software encodes RSA public keys in PEM-PKCS#1 format (see: https://github.com/fedify-dev/hollo/pull/109#issuecomment-2662591619). Fedify currently only accepts PEM-SPKI format, so it needs to accept PEM-PKCS#1 format as well for better interoperability.
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Fedify is a #TypeScript framework that simplifies #ActivityPub implementation. Want to build a federated server without the complexity? Fedify has got you covered!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Excited to share that Fedify CLI is now available on Scoop for #Windows users! You can easily install it with scoop install fedify. One more way to get started with #ActivityPub development!
Just integrated #Deno's new workspaces feature into the #Fedify repository! This means we can now manage the main package, CLI tool, and examples all in one place. The best part? No more custom import map generators—everything's simpler and more intuitive for new contributors. Loving how Deno 2.0's workspace support makes managing monorepos so much cleaner.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
Love building federated apps with #Fedify? Consider supporting its development! We have tiers starting from just $5/month, and every contribution helps keep the project sustainable.
We're considering adding custom background task support to #Fedify 1.5.0. Got thoughts on whether Fedify should support user-defined background tasks alongside ActivityPub operations? Check out the proposal and share your feedback: https://github.com/fedify-dev/fedify/issues/206.
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.
@reiver@andypiper@rwg@andresmh Re: which networks, I haven't personally done any academic research about social platforms. Pondering questions, yes, written anything down, no.
I have a project cooking that I think you'll like, for which I'm hoping to run a semi-public alpha test within the next few months. Join the @fedify Matrix room at #fedify-users:matrix.org to witness my implementation struggles. 👍
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
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
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
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
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
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
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
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
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
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
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
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
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
ALT text detailsScreenshot shows release stats for Fedify: latest version 1.4.1 was released 6 minutes ago, with a green tag showing “Latest.” Total release count shows “+ 100 releases.” A green icon resembling a tag appears next to the Fedify name.
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.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
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.
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.
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.
We're considering adding custom background task support to #Fedify 1.5.0. Got thoughts on whether Fedify should support user-defined background tasks alongside ActivityPub operations? Check out the proposal and share your feedback: https://github.com/fedify-dev/fedify/issues/206.
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.
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.
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.
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
We're excited to announce the release of Fedify 1.4.0! This release brings significant improvements to enhance compatibility and flexibility in #ActivityPub federation.
Introduced a new system to adjust outgoing activities for better compatibility with various ActivityPub implementations. This includes automatic ID assignment for activities and actor dehydration to satisfy implementation quirks (looking at you, Threads!).
WebFinger customization
Added the ability to customize WebFinger responses through the new mapAlias() API, giving you more control over how your actors are discovered.
New interaction collections
Added support for shares, likes, and emojiReactions properties to the Object class, making it easier to access and traverse these interaction collections.
More flexible document/context loader
Document loader and context loader are now configurable through factory functions, giving you more control over how your application handles JSON-LD documents.
CLI improvements
The fedify lookup command now supports two new options:
Improved error handling in collection traversal and JSON-LD processing
Added support for private network access control in WebFinger lookups
User-Agent headers now automatically include your instance URL, making it easier for other servers to identify your instance
For the complete list of changes and bugfixes, please visit our changelog.
Whether you're building a new federated application or maintaining an existing one, #Fedify 1.4.0 provides the tools you need for robust ActivityPub federation.
Supporting us
We're grateful to all our sponsors who make this project possible. Check out our new sponsors showcase page to see the amazing individuals and organizations supporting Fedify's development. If you'd like to support Fedify's development, please consider becoming a sponsor!
Upgrade now
You can install Fedify 1.4.0 from JSR or npm. Upgrade today and let us know what you think!
Made a little bit of progress on my #Fedify project yesterday. Spun my wheels testing a few #TypeScript ORMs and running into compatibility problems with each of them. By the time I went to bed, the preferences page was capable of storing and loading account-local form data for the first time. 🥳
For this project, when progress looks slow from the outside, it's because I'm learning the ecosystem pretty much from scratch. Not letting myself get discouraged. 🙂
Made a little bit of progress on my #Fedify project yesterday. Spun my wheels testing a few #TypeScript ORMs and running into compatibility problems with each of them. By the time I went to bed, the preferences page was capable of storing and loading account-local form data for the first time. 🥳
For this project, when progress looks slow from the outside, it's because I'm learning the ecosystem pretty much from scratch. Not letting myself get discouraged. 🙂
ALT text detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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.
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:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
ALT text detailsFedify'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.
I want to automatically list the names of people who have sponsored #Fedify with Open Collective in README.md. Is there a good way to do this? (I think I can use GitHub Actions or Open Collective's webhooks, but it's a bit of a hassle to create it myself.)
ALT text detailsFedify'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 detailsFedify'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.
I want to automatically list the names of people who have sponsored #Fedify with Open Collective in README.md. Is there a good way to do this? (I think I can use GitHub Actions or Open Collective's webhooks, but it's a bit of a hassle to create it myself.)
ALT text detailsFedify'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.
I want to automatically list the names of people who have sponsored #Fedify with Open Collective in README.md. Is there a good way to do this? (I think I can use GitHub Actions or Open Collective's webhooks, but it's a bit of a hassle to create it myself.)
ALT text detailsFedify'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 detailsFedify'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 detailsFedify'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.
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:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
ALT text detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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 detailsFedify'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.
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
All repositories have been transferred and GitHub's automatic redirects are in place, so existing links will continue to work. Also, the project's core functionality and development process remain unchanged.
Thanks to everyone who participated in our naming poll. Looking forward to Fedify's continued growth under its new organizational home!
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Key Points: ➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints. ➡️ It is user-friendly and written in TypeScript, ensuring type safety. ➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers. ➡️ Powered by #Fedify, a robust #ActivityPub framework.
Key Points: ➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints. ➡️ It is user-friendly and written in TypeScript, ensuring type safety. ➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers. ➡️ Powered by #Fedify, a robust #ActivityPub framework.
Key Points: ➡️ BotKit enables the creation of standalone ActivityPub bots, free from platform constraints. ➡️ It is user-friendly and written in TypeScript, ensuring type safety. ➡️ BotKit is easy to deploy with minimal dependencies on various virtual servers. ➡️ Powered by #Fedify, a robust #ActivityPub framework.
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot in a single TypeScript file using our simple, expressive API.
Currently #Deno-only, with Node.js & Bun support planned. Built on the robust #Fedify foundation.
ALT text detailsimport {
createBot,
InProcessMessageQueue,
MemoryKvStore,
mention,
text,
} from "@fedify/botkit";
// Create a bot instance:
const bot = createBot<void>({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the display name:
name: "Greet Bot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
summary: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social")}.`,
// Store data in memory (for development):
kv: new MemoryKvStore(),
// Use in-process message queue (for development):
queue: new InProcessMessageQueue(),
});
// A bot can respond to a mention:
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};
// Or, a bot also can actively publish a post:
const session = bot.getSession("https://mydomain/");
setInterval(async () => {
await session.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
Even though it's built on #Fedify, its API looks completely different from Fedify's one. I intended to make it resembles more Discord/Telegram bot frameworks than Fedify. I think it's close to my intention.
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
The last "big" code thing I need to get done before the alpha test of my current @fedify project is the task queue - make sure routine data updates happen, consider individual importance and urgency, respect external API rate limits, etc.
But that's super intimidating so I'm currently procrastinating by making it a cute lil home page instead. 🙃
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
Added an experimental feature flag TIMELINE_INBOXES to store all posts visible to your timeline in the database, rather than filtering them in real-time as they are displayed. This is useful for relatively larger instances with many incoming posts, but as of now it may have several bugs. It is expected to be the default behavior in the future after it is stabilized.
Now you can import and export your data from the administration dashboard in CSV format: follows, lists, accounts you muted, accounts you blocked, and bookmarks.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
ALT text detailsHollo's memory usage graph. When I was running on Bun, it used about 4GB of memory, but after switching to Node.js, it uses about 0.5GB of memory.
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
I'm currently brainstorming a framework for creating fediverse bots called #BotKit, based on #Fedify. It's less flexible than Fedify, but the goal is to make it possible to create simple fediverse bots with much less code. What do you think?
ALT text detailsimport { createBot, mention, text } from "@fedify/botkit";
import { RedisKvStore } from "@fedify/redis";
import { Redis } from "ioredis";
// Create a bot instance:
const bot = createBot({
// The bot will have fediverse handle "@greetbot@mydomain":
username: "greetbot",
// Set the profile icon (avatar):
icon: new URL("https://mydomain/icon.png"),
// Set the bio:
bio: text`Hi, there! I'm a simple fediverse bot created by ${
mention("@hongminhee@hollo.social").}`,
// Use Redis as a key-value store:
kv: new RedisKvStore(new Redis()),
// Use Redis as a message queue:
queue: new RedisMessageQueue(() => new Redis()),
});
// A bot can respond to a mention:
bot.on(/hi|hello|what'?s\s+up/i, (ctx) => {
return ctx.reply(text`Hi, ${ctx.actor}!`);
});
// Or, a bot also can actively publish a post:
setInterval(async () => {
await bot.publish(text`Hi, forks! It's an hourly greeting.`);
}, 1000 * 60 * 60);
export default bot;
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
I'd like to translate #Fedify's docs into multiple languages, at least into Korean and Japanese, which are languages I speak, but I'm not sure how useful it would be compared to the cost. Fedify's docs are already pretty extensive, so translating them would be difficult, plus the cost of updating them would be quite high. 🤔
Since #Fedify 1.4.0, our next release, the fedify lookup command will have the -t/--traverse option! It takes a URL of the collection, and traverse its items from the beginning to the end. Here's a demo:
ALT text detailsThe demo session of the -t/--traverse option which will be introduced to the fedify lookup command since Fedify 1.4.0.
I was learning #Fedify and I wanted to make a minimal Next.js example of a "read-only" app that was for consuming the Fediverse and didn't mess with interactions. It started as a boilerplate to benefit other devs, but the act of making it forced me to learn a lot more about Fedify and ActivityPub. #WebDev#Demo
ALT text detailsA screenshot showing 2 browser windows, one in landscape format, one in portrait format, to represent desktop and mobile viewports. The design is very yellow and sepia-ish showing a toot and an image next to it. A lot of brush and marker strokes are incorporated into the design. Otherwise the design is minimal.
Wondering how much work it would be to stick together #Fedify and an as-of-yet-unidentified #PDS framework to have a #Ghost blog be on both #ActivityPub and #Bluesky natively at once.
I was looking at the properties on the Person #ActivityPub object implemented by #fedify, and wasn't expecting this one, haha!
I'm presuming this is #Misskey related? The quirks of having to implement many different versions of a spec!
ALT text detailsA screenshot of a code editor showing a TypeScript class Person with a property get cat(): boolean | null. The accompanying comment explains that the property is "used on actors to indicate that they in some way identify as a cat, expressed as a boolean value. If this property is set to true, displaying the actor or their notes will have some special effects attached in some clients."
#WIP - I'm learning ActivityPub for a larger project, but taking a moment to #design and code a minimal fediverse reader.
I found it tricky learning to make a read-only app with #Fedify, so wanted to make this example Next.js project available. Got a little carried away with the design.
Mockup in #Inkscape, it's a better prototyping tool than one might expect.
Hopefully @tamami doesn't mind me using her nice post in my mockup .
ALT text detailsA design mockup of a minimalistic "Fediverse Reader" app created in Inkscape, showcasing layouts for desktop and mobile screens. The designs include variations of a homepage and post view with text and images. The interface uses light yellow tones and emphasizes simplicity with modern, clean lines.
Thanks to @joschi, Hollo now support local filesystem storage for media files. You can configure DRIVE_DISK=fs and FS_ASSET_PATH to store media files in the local filesystem. For users who've used S3, no further action is required—but, it's recommended to configure DRIVE_DISK=s3 as DRIVE_DISK will be required in the future releases.
Added support for Sentry. If you want to see error reports and instrumented traces in Sentry, please configure SENTRY_DSN.
Added pagination to the profile page.
Minor performance improvements and bug fixes due to upgrading Fedify to 1.3.0.
You can upgrade to Hollo 0.3.0 using the following ways:
I would like to translate #Fedify's docs into Korean and Japanese, the languages I can speak, but the amount of the docs is quite much, so I can't even think of doing it. The maintenance costs for updating the docs also cannot be ignored.
ALT text detailsInstrumented spans
Fedify automatically instruments the following operations with OpenTelemetry spans:
Operation Span type Description
Federation.fetch() Server Serves the incoming HTTP request.
lookupObject() Client Looks up the Activity Streams object.
lookupWebFinger() Client Looks up the WebFinger resource.
handleWebFinger() Server Handles the WebFinger request.
More operations will be instrumented in the future releases.
ALT text detailsSemantic attributes for ActivityPub
The OpenTelemetry Semantic Conventions currently do not have a specification for ActivityPub. However, Fedify provides a set of semantic attributes for ActivityPub. The following table shows the semantic attributes for ActivityPub:
Attribute Type Description Examples
activitypub.activity.id string The IRI of the activity object. "https://example.com/activity/1"
activitypub.activity.type string[] The qualified IRI(s) of the activity type(s). ["https://www.w3.org/ns/activitystreams#Create"]
activitypub.activity.to string[] The IRI(s) of the recipient collections/actors of the activity. ["https://example.com/1/followers/2"]
activitypub.activity.cc string[] The IRI(s) of the carbon-copied recipient collections/actors of the activity. ["https://www.w3.org/ns/activitystreams#Public"]
activitypub.activity.resend_count int The ordinal number of activity resending attempt (if and only if it's retried). 3
activitypub.actor.id string The IRI of the actor object. "https://example.com/actor/1"
activitypub.actor.type string[] The qualified IRI(s) of the actor type(s). ["https://www.w3.org/ns/activitystreams#Person"]
activitypub.object.id string The IRI of the object or the object enclosed by the activity. "https://example.com/object/1"
activitypub.object.type string[] The qualified IRI(s) of the object type(s). ["https://www.w3.org/ns/activitystreams#Note"]
activitypub.object.in_reply_to string[] The IRI(s) of the orig
ALT text detailsSvelteKit
This API is available since Fedify 1.3.0.
SvelteKit is a framework for building web applications with Svelte. Fedify has the @fedify/fedify/x/sveltekit module that provides a hook handler to integrate Fedify with SvelteKit. Put the following code in your hooks.server.ts file:
import { createFederation } from "@fedify/fedify";
import { fedifyHook } from "@fedify/fedify/x/sveltekit";
const federation = createFederation<string>({
// Omitted for brevity; see the related section for details.
});
// This is the entry point to the Fedify hook from the SvelteKit framework:
export const handle = fedifyHook(federation, (req) => "context data");
• Smart object lookup with content negotiation • Interactive inbox testing with a web UI • NodeInfo visualization • Local development tunneling • And more!
내일 서울 서초구 오픈업 플레이그라운드에서 이뤄지는 Open Contribution Jam 2024에 #Fedify 메인테이너(@hongminhee)가 참여합니다. Fedify에 기여해보고 싶은 분들은 와주시면 메인테이너가 성심껏 도와드리겠습니다! 자세한 행사 정보는 아래 링크를 참고하시면 됩니다.
ALT text detailsUsing different message queues for different tasks
This API is available since Fedify 1.3.0.
In some cases, you may want to use different message queues for different tasks, such as using a faster-but-less-persistent queue for outgoing activities and a slower-but-more-persistent queue for incoming activities. To achieve this, you can pass FederationQueueOptions to the CreateFederationOptions.queue option.
For example, the following code shows how to use a PostgresMessageQueue for the inbox and a RedisMessageQueue for the outbox:
const federation = createFederation<void>({
queue: {
inbox: new PostgresMessageQueue(
postgres("postgresql://user:pass@localhost/db")
),
outbox: new RedisMessageQueue(() => new Redis()),
},
// ... other options
});
Or, you can provide a message queue for only the inbox or outbox by omitting the other:
const federation = createFederation<void>({
queue: {
inbox: new PostgresMessageQueue(
postgres("postgresql://user:pass@localhost/db")
),
// outbox is not provided; outgoing activities will not be queued
},
// ... other options
});
ALT text detailsuserAgent
This API is available since Fedify 1.3.0.
The options for making User-Agent header in the HTTP requests that Fedify makes. By default, it contains the name and version of the Fedify library, and the name and version of the JavaScript runtime, e.g.:
Fedify/1.3.0 (Deno/2.0.4)
Fedify/1.3.0 (Node.js/v22.10.0)
Fedify/1.3.0 (Bun/1.1.33)
You can customize the User-Agent header by providing options like software and url. For example, if you provide the following options:
{
software: "MyApp/1.0.0",
url: "https://myinstance.com/"
}
The User-Agent header will be like:
MyApp/1.0.0 (Fedify/1.3.0; Deno/2.0.4; +https://myinstance.com/)
Or, you can rather provide a custom User-Agent string directly instead of an object for options.
Thanks to @thisismissem, now you can report remote accounts and posts.
Added two-factor authentication support.
Thanks again to @thisismissem, Hollo improved alignment on Mastodon API changes about OAuth and apps.
Thanks again to @thisismissem, RFC 8414 for OAuth Authorization Server metadata endpoint. It will improve interoperability between Hollo and Mastodon-compatible client apps.
Renamed the Data menu from the administration dashboard to Federation, and:
Now posts also can be force-refreshed.
Now the number of messages in the task queue is shown.
Custom emojis now can be deleted from the administration dashboard.
Added InboxContext.recipient property. It's useful for determining whether it is a shared inbox or a personal inbox, and whose personal inbox is invoked.
Continued my experiments with #Fedify and #ActivityPub yesterday and I think I’m confused.
I was trying to make an extension for an Object, and if I understand #JsonLd, the context property contains the definition of any extra property added. I see e.g. the activity streams ns resolves to a nice JSON LD that contains all the properties, but the mastodon one doesn’t resolve to anything? Is it not necessary?
Starting with the next release of #Fedify, v1.2.0, we will support traceable logs for easier debugging. Fedify's traceable logs are implemented using the implicit contexts introduced in LogTape 0.7.0, and most of the logs that Fedify records are given a requestId or messageId. This means that logs can be grouped into requests or background tasks for better analysis.
Want to try it out in advance? Try Fedify v1.2.0-dev.468+2e17cd69 (JSR & npm)!
As someone who works mainly in the front-end, ActivityPup (and related) always felt quite overwhelming and complicated to understand. I’ve been playing around with #Fedify for the past week or so and the documentation is so good it all just clicked for me! (I think so, at least :p)
Really excited to see what people build as ActivityPub becomes more approachable!
ALT text detailsLast week, along with a DDOS attack and exposure of patron email addresses and encrypted passwords, the Internet Archive’s website javascript was defaced, leading us to bring the site down to access and improve our security.
The stored data of the Internet Archive is safe and we are working on resuming services safely. This new reality requires heightened attention to cyber security and we are responding. We apologize for the impact of these library services being unavailable.
The Wayback Machine, Archive-It, scanning, and national library crawls have resumed, as well as email, blog, helpdesk, and social media communications. Our team is working around the clock across time zones to bring other services back online. In coming days more services will resume, some starting in read-only mode as full restoration will take more time.
We’re taking a cautious, deliberate approach to rebuild and strengthen our defenses. Our priority is ensuring the Internet Archive comes online stronger and more secure.
As a library community, we are seeing other cyber attacks—for instance the British Library, Seattle Public Library, Toronto Public Library, and now Calgary Public Library. We hope these attacks are not indicative of a trend.
For the latest updates, please check this blog and our official social media accounts: X/Twitter, Bluesky and Mastodon.
Thank you for your patience and ongoing support.
If you're interested in Hollo, please give it a try! There are several ways to install it: using Railway, using Docker (and Docker Compose), or manually.
If you're already using Hollo, please upgrade it to v0.1.0:
Added Export class to Activity Vocabulary API. [FEP-9091]
Added service property to the Actor types in the Activity Vocabulary API. [FEP-9091]
The default time window for verifying HTTP Signatures of incoming requests is now an hour (was a minute). This new default window is according to the ActivityPub and HTTP Signatures document.
In the fedify inbox command's web interface, the Raw Activity tab is added to show the raw JSON object of the received activity.
#Fedify now has an #AMQP driver! This means you can use #RabbitMQ as Fedify's message queue. To use it, first install the @fedify/amqp package, then set it up like below:
import { createFederation } from "@fedify/fedify";
import { AmqpMessageQueue } from "@fedify/amqp";
import { connect } from "amqplib";
const federation = createFederation({
queue: new AmqpMessageQueue(await connect("amqp://localhost")),
// ... other configurations
});
Even though I am a slow coder, it only took me about a month to create most of #Hollo's features in #Fedify. Having a framework makes a huge difference in productivity.
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:
@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.
Introducing Fedify: Build Your Own Fediverse App with Ease! 🚀
Are you excited about the #fediverse but find implementing #ActivityPub daunting? Meet #Fedify, a #TypeScript framework that simplifies building federated server apps. Whether you're creating the next Mastodon, Pixelfed, or something entirely new, Fedify has you covered.
Fedify abstracts away the complexities of ActivityPub, letting you focus on your app's unique features. It's designed to work seamlessly with popular web frameworks like Hono, Express, and Fresh.
@FiFachik@rf Для тех, кто хочет потестить федерирование для своего бложика с поддержкой #ActivityPub, могу только посоветовать #Fedify. Там есть встроенная команда для подключения к сервису на выбор, который может дать временный домен для тестирования.
activitypub typescript server framework called Fedify announces first stable release. It is being used by the open source Ghost CMS platform. Can't wait to see what other apps are created with Fedify
ALT text detailsactivitypub typescript server framework called Fedify announces first stable release. It is being used by the open source Ghost CMS platform. Can't wait to see what other apps are created with Fedify
Github repo here: https://github.com/dahlia/fedify/releases/tag/1.0.0
Fedify, an ActivityPub framework, has finally released its first stable version, 1.0.0! Here are key changes:
Deprecation of the term handle
From this version, the term handle across Fedify will only be used to refer to fediverse handles (e.g., @hongminhee@fosstodon.org). An actor's internal unique ID (e.g., b379dbdc-3b4f-4ef4-88c2-fc25632d1c22) is referred to as an identifier, and the WebFinger name (e.g., hongminhee) is referred to as a username.
The term handle in the API will be maintained for a while for backward compatibility, but deprecation warnings will be logged, and it is planned to be removed in the future.
Linked Data Signatures is an outdated standard, but it's still relied upon by major fediverse implementations such as Mastodon.
In addition to HTTP Signatures and Object Integrity Proofs, Fedify now supports Linked Data Signatures from this version, thus supporting all types of signature methods used in the fediverse. This makes Fedify an ActivityPub implementation with the best interoperability.
However, Fedify users don't need to do anything special to use Linked Data Signatures. If an incoming activity has Linked Data Signatures, it automatically verifies the signature, and all outgoing activities will have signatures in three formats: HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs.
From this version, you can forward activities received in the inbox to other actors using the InboxContext.forwardActivity() method.
At first glance, you might think that you could just resend an activity received in the inbox using the Context.sendActivity() method. However, if you do this, the original signature is removed before the activity is delivered to the inbox, and when sending it, the signature of the forwarding actor is attached instead, causing the receiving side of the forwarded activity to not trust it.
On the other hand, when using the InboxContext.forwardActivity() method, the activity is forwarded with the original signature preserved, avoiding this problem. (Of course, the original activity itself must be signed with Linked Data Signatures or Object Integrity Proofs.)
Sending Delete(Application) on fedify inbox termination
From this version, fedify inbox will send a Delete(Application) activity to all peer servers it encountered when terminated. This is typically an activity sent when deleting an account, which will help prevent residual data related to temporary actors from remaining on other servers.
PostgreSQL drivers
The @fedify/postgres package, which implements PostgreSQL drivers for the KvStore and MessageQueue interfaces, has been released alongside this version.
The PostgreSQL driver is a backend that can be sufficiently used in production, especially recommended for projects already using PostgreSQL.
Additionally, an option to select the PostgreSQL driver has been added to the fedify init command.
Celebrating Fedify 1.0.0
With the release of version 1.0.0, Fedify will now maintain API backward compatibility as much as possible. (Of course, in the long term, there may be a 2.0.0 that breaks backward compatibility.) This should be good news for those who have been hesitant to use Fedify because there hasn't been a stable version until now!
So, hoping that more services will support ActivityPub in the future, I conclude this post!
Starting with #Fedify v1.0.0, the term handle throughout Fedify will only be used to refer to a fediverse handle (e.g., @hongminhee@fosstodon.org). An actor's internal unique ID (e.g., b379dbdc-3b4f-4ef4-88c2-fc25632d1c22) will be referred to as identifier and a WebFinger name (e.g., hongminhee) will be referred to as username. The term handle in the API will be retained for the time being for backwards compatibility, but a deprecation warning will be logged and will be deprecated in the future.
Once the next version of #Fedify, v1.0.0, is released, the API will be stabilized. Are there any features you'd like to see before the API is stabilized?
Once the next version of #Fedify, v1.0.0, is released, the API will be stabilized. Are there any features you'd like to see before the API is stabilized?
#Fedify started out exclusively for #Deno, but now also supports #Node.js and #Bun. However, the #logo we created in the early days still features the character from Deno. Should Fedify change its logo now?
One of the benefits of #Fedify is that you don't have to worry about whether a property of an Activity Vocabulary object has a URL or embeds an actual object. If you need an object, you can call the `getObject()` method (which will fetch a remote object if necessary). If you need a URI, you can access the `objectId` property.
#Fedify is built in #Deno for ease of development, but it also supports #Node.js and #Bun using #dnt. Deno's DX is so good that I don't regret this decision, and I'm looking forward to Deno 2.0 as well.
I'm applying #Twoslash to the #Fedify docs. It works like magic! When I'm done, the Fedify docs will be even easier to read the example code than they are now.
ALT text detailsThe mouse cursor is hovering over a method in the example code, and information about that API pops up as a tooltip.
In addition, activities sent with the Context.sendActivity() method will have Linked Data Signatures attached in addition to HTTP Signatures if any RSA-PKCS#1-v1.5 key pairs are present.
We were not motivated by implementing Linked Data Signatures, which is already an outdated standard, but we hope this change will lead to better compatibility and interoperability of Fedify apps!
I recently wrote a #Fedify manual in Korean, and then translated it into English and Japanese. It's quite a long post, but it's relatively easy to accomplish with #Claude. Here's how I used it:
• Utilize projects to provide prior knowledge. • Translate the table of contents first. • Define a glossary. • Translate chapter by chapter.
However, this method assumes you speak the target language—it's a way to reduce the labor of #translation, not a way to become fluent in a language you don't know.
ALT text detailsThe combination of HTTP Signatures and Linked Data Signatures is the most widely supported way to sign activities in the fediverse, as of September 2024. Despite Linked Data Signatures is outdated and not recommended for new implementations, it is still widely used in the fediverse due to Mastodon and other major implementations' reliance on it.
However, for new implementations, you should consider using both Object Integrity Proofs and Linked Data Signatures for maximum compatibility and future-proofing.
#Fedify has a side effect that when you call the getter method of an Activity Vocabulary object, the property that was internally a URI is populated with the actual ActivityStreams object. Today, someone at Ghost gave us a cool term for this: #hydration.
Imagine what if every website implemented HTTP/TLS themselves. There would be so much fragmentation that we wouldn't see the #interoperability we see today.
To me, that's what the #fediverse looks like today. Mastodon, Pixelfed, etc. have their own implementations of #ActivityPub, WebFinger, HTTP Signatures, etc. and each one behaves slightly differently, which leads to poor interoperability. Adoption of new standards is slow.
I wish each major programming language had something like #Fedify.
I received a request from @ghost today to add #LDSignatures to @fedify for compatibility with #Mastodon, as Mastodon does not plan to implement Object Integrity Proofs (FEP-8b32) for the near future. 😩
However, Mastodon's implementation of LD Signatures does not even use valid JSON-LD properties (despite the name), so I'm not sure how to make it compatible with Mastodon since #Fedify does JSON-LD processing. 🤔
ALT text detailsThe JSON-LD representation of a Create(Note) activity containing LD Signatures produced by Mastodon and its expanded form. The “signature” property and its child properties are not properly namespaced.
I handwavingly predict that the most stable #misskey fork will be whichever one decides to rebuild its foundations atop of #fedify, thus freeing up the dev(s) to focus on the client-side innovations that the #forkeys have always excelled at.
In the next version of #Fedify, the Article, ChatMessage, Note, and Question classes will have a quoteUrl property. This property corresponds to the following three JSON-LD properties all at once:
We just finished drafting a new tutorial for #Fedify! This tutorial will walk you through the steps of creating your own federated #microblog. It's pretty long, though.
ALT text detailsA panel from the original Watchmen comic, depicting Dr. Manhattan partially reassembling himself after the accident that created him. Text is modified to read: "SEPTEMBER 3RD: A PARTIALLY IMPLEMENTED FEDIFY APP RUNS BEHIND A SERVEO TUNNEL AND FEDERATES FOR THIRTY SECONDS BEFORE VANISHING..."
I finally finished the first draft of the new #Fedify tutorial, but it's still in Korean. Now I just need to polish it up and translate it into English.
#Fedify 튜토리얼 이제 ½도 못 쓴 것 같은데, 目次가 이만큼이다. 다 쓸 수 있을까…? 다 쓰더라도 사람들이 읽고 따라할까?
ALT text details나만의 단문 블로그 만들기
대상 독자
목표
개발 환경 셋업
Node.js 설치하기
fedify 명령어 설치
fedify init으로 프로젝트 초기화
Visual Studio Code
선수 지식
TypeScript
JSX
계정 생성 페이지
데이터베이스 셋업
앱에서 데이터베이스 연결
레코드 삽입
테스트
프로필 페이지
액터 구현하기
테이블 생성
액터 레코드
액터 디스패처
테스트
암호 키 쌍들
테이블 생성
키 쌍 디스패처
테스트
Mastodon과 연동
공개 인터넷에 노출
수신함
테이블 생성
Follow 액티비티 수신
ActivityPub Academy
테스트
팔로 취소
Undo 액티비티 수신
ALT text detailsInspecting ActivityPub objects
BrowserPub
BrowserPub is a browser for debugging ActivityPub and the fediverse. You can punch in any ActivityPub discoverable web URL or fediverse handle, and it will discover and display the underlying ActivityPub.
For example:
• hollo.social/@fedify
• @hongminhee@fosstodon.org
If you want to know further details about BrowserPub, read the creator's Mastodon thread.
fedify lookup command
Fedify provides a CLI toolchain for testing and debugging. The fedify lookup command is a simple tool for looking up an ActivityPub object by its URL or fediverse handle.
@hongminhee I'd be happy to take a look sometime. I am planning on using #Fedify to build my own ActivityPub server soon and I am pretty new to TypeScript.
The new #Fedify tutorial I'm writing now even includes an explanation of #TypeScript and #JSX for readers who don't know them. As a result, it's getting very long. 😓
I'm sharing a prototype of #Fedify written in #Python, codenamed “FediKit.” Many of the ideas for Fedify were already implemented in this prototype, albeit in a different language.
For educational purpose, I've created a federated microblog example using #Fedify, with a total of about 30 commits, which you can follow step by step.
Now, I'm starting to write a hands-on Fedify tutorial based on this example code. I'll make it public when I'm done!
I've rewritten #Fedify several times and in several languages. The first time it was written in #TypeScript, then #Python, then C#, then back to TypeScript. (It was codenamed FediKit at the time of development.) I settled on TypeScript for the following reasons:
• It has a decent JSON-LD implementation. • Lots of people use it. (I wanted Fedify to be widely used.) • It's type-safe enough.
Even if I were to build Fedify again, I would choose TypeScript.
In the next version (v0.14.0) of #Fedify, the performance of the Object.toJsonLd() method will be dramatically (~3k ×) faster. This is expected to improve the overall performance of Fedify apps!
I feel that the current abstraction level of #Fedify is not high enough which makes the tutorial lengthy, so I'm considering adding a higher-level API. One way would be to add a façade to the @fedify/fedify package, and another way would be to create a sort of metaframework as a separate package (e.g., @fedify/start?). Which way would be better?
I'm writing a #Fedify tutorial, and I keep saying things like “you don't need to know what Ed25519 is” and “you don't need to know what JWK is for this tutorial.” Would this be okay?
ALT text details—In your opinion, what is Fedify's weakest point?
Based on my review of the Fedify documentation, I think one potential weak point of Fedify is:
The learning curve and complexity involved in properly implementing all the components of a federated ActivityPub server.
While Fedify aims to simplify building ActivityPub servers, there are still many concepts and pieces that developers need to understand and implement correctly, including:
• Actor dispatchers
• Inbox listeners
• Collection dispatchers (outbox, followers, etc.)
• Key pair management
• Object dispatchers
• Access control
• Integration with web frameworks
The documentation is quite extensive, which is good, but also indicates there's a lot for developers to learn and configure properly. Even with Fedify abstracting away some of the low-level details, building a fully-featured and interoperable ActivityPub server requires understanding many moving parts.
Additionally, since Fedify provides flexibility in how these components are implemented, developers still need to make many decisions about data storage, business logic, etc. This flexibility is powerful but also puts more onus on developers to implement things correctly.
So while Fedify seems to be a very capable framework, the inherent complexity of building a federated server means there's still a significant learning curve and potential for implementation mistakes…
The JSON-LD processor ended up being #Fedify's bottleneck, so I'm in the process of fixing Fedify to generate JSON-LD without the proper JSON-LD processor.
Introducing @fedify/express, a package that integrates Express, a popular web framework in Node.js, with Fedify. You can install it with the following command:
npm add @fedify/express
This package provides a middleware called integrateFederation() that allows you to integrate #Fedify with #Express:
import express from "express";
import { integrateFederation } from "@fedify/express";
import { federation } from "./federation"; // Your `Federation` instance
export const app = express();
app.set("trust proxy", true);
app.use(integrateFederation(federation, (req) => "context data goes here"));
I'm unsure whether to adopt an emerging JavaScript runtime like #Bun or #Deno for #Fedify's tutorial, or stick with traditional #Node.js. 🤔
If I choose Bun/Deno, it comes with built-in #TypeScript support, hot reloading, and a fetch-style HTTP server, so I don't have to explain much about it, but I need to deal with installing Bun/Deno itself.
On the other hand, Node.js can be assumed to be already installed on the reader's system, but they will need to set up TypeScript, hot reloading, etc.
Starting with the next release, v0.13.0, the fedify tunnel command will be added. The following command exposes a local HTTP server running on port 3000 to the public internet:
If you've created a new web framework, you can assume that your readers will have some knowledge of HTTP when you write tutorials for it. However, if you have created a new #ActivityPub server framework, you should also explain ActivityPub itself in the tutorials for this framework.
I kept thinking about this while writing the #Fedify framework tutorial. 😩
유연성은 중요하죠! #Fedify 프레임워크는 풀 스택 솔루션이 아닙니다—여러분이 좋아하는 웹 프레임워크와 함께 작동하도록 설계되었죠. #Hono 및 #Fresh 등, Fedify는 여러 웹 프레임워크와의 쉬운 통합 옵션을 제공합니다. 여러분만의 방식으로 #연합우주 (#fediverse) 앱을 만드세요! 🛠️
튜토리얼에서 이렇게 에디터 뭐 쓰라고 이래라 저래라 하는 게 그다지 좋지 않다는 것은 잘 알고 있지만… #Fedify 쓰는데 TypeScript LSP 안 켜두고 코딩하다가 자잘한 타입 에러를 못 보고 지나쳐서 오랫동안 트러블슈팅하는 사람들을 꽤 봤기 때문에 이렇게 Visual Studio Code 쓰라고 할 수밖에 없었다.
ALT text detailsVisual Studio Code
Visual Studio Code가 여러분의 최애 에디터가 아닐 수 있습니다. 그렇지만, 이 튜토리얼을 따라하는 동안에는 Visual Studio Code를 써보실 것을 권합니다. 왜냐하면 우리는 TypeScript를 써야 하는데, Visual Studio Code는 현존하는 가장 간편하면서도 뛰어난 TypeScript IDE이기 때문입니다. 또한, 생성된 프로젝트 셋업에 이미 Visual Studio Code 설정이 갖춰져 있기 때문에 포매터나 린트 등과 씨름할 필요도 없습니다.
Visual Studio Code를 설치하였다면, 파일 → 폴더 열기… 메뉴를 눌러 작업 디렉터리를 불러오십시오.
만약 「이 리포지토리에 대한 권장되는 biomejs의 ‘Biome’ 확장을(를) 설치하시겠습니까?」라고 묻는 창이 뜨면 설치 버튼을 눌러 해당 확장을 설치하세요. 이 확장을 설치하면 들여쓰기나 띄어쓰기 같은 코드 스타일과 씨름할 필요 없이 자동으로 코드가 서식화 됩니다.
Tip
여러분이 충성스러운 Emacs 또는 Vim 사용자라면, 쓰던 여러분의 최애 에디터를 쓰는 것을 말리지 않겠습니다. 다만, 다음 몇 가지 설정은 짚고 넘어갈 것을 권합니다:
TypeScript LSP
Biome LSP
위 두 LSP 설정 여부에 따라 생산성의 차이가 크기 때문입니다.
I'm writing a new #Fedify#tutorial. If a tutorial on creating an #ActivityPub server needs to deal with persistent data, where should they be stored? I want the tutorial to focus as much as possible on implementing the business logic and as little as possible on other things.
Improved multitenancy (virtual hosting) support: You can now easily determine the host of the current request via the hostname, host, and origin properties of the Context.
When validating HTTP Signatures and Object Integrity Proofs, once fetched public keys are now cached.
It's available on JSR and npm now, and you can upgrade it using the deno add command on Deno:
Since #Fedify v0.12.0, when verifying HTTP Signatures or Object Integrity Proofs, it will cache the public keys once fetched. It is okay even if a cached key becomes outdated because a verification failure due to a cached key will invalidate the cache and force a verification retry.
This feature is available for preview in v0.12.0-dev.307+235629d5 (JSR or npm).
Now that I've created the `fedify init` command, I've been thinking about how to modify #Fedify's #tutorial. If I make Fedify's tutorial use `fedify init`, it could omit the project setup part at the beginning. However, the chance to get some understanding of how things work like in the current tutorial would be lost. 🤔
ALT text detailsA demo of the `fedify init` command. The JavaScript runtime choices are Deno, Node.js, and Bun, of which Deno is selected. The web framework choices are Bare-bones, Astro, Fresh, and Hono, with Hono selected. The key-value store options are No cache, Redis, and Deno KV, with Deno KV selected. The message queue options are No background jobs, Redis, Deno KV, and Deno KV is selected. Finally, an Hono project integrated with Fedify is created and the server is started by running the `deno task dev` command.
Currently, #Fedify's tutorial is lengthy in explaining how to set up a project. If there was a command like `fedify init`, that part could be greatly shortened.
Fedify uses hierarchical categories for fine-grained control over log output. Key categories include ["fedify", "federation", "http"] for HTTP requests/responses and ["fedify", "federation", "inbox"]/["fedify", "federation", "outbox"] for incoming/outgoing activities. (There are more categories.)
With #LogTape integration, you gain valuable insights into your Fedify app's behavior, making troubleshooting and optimization much more straightforward!
Debugging #ActivityPub interactions can be tricky, but #Fedify's got your back! It includes a CLI toolchain for testing and debugging, making development and troubleshooting a breeze. Spend less time scratching your head and more time building awesome features! 🔍
Flexibility is key! #Fedify isn't a full-stack solution—it's designed to work alongside your favorite web frameworks. Whether you're using #Astro, #Hono, #Fresh, or others, Fedify has got you covered with easy integration options. Build your #fediverse app, your way! 🛠️
One of #Fedify's strongest features is its type-safe vocabulary objects. These represent the Activity Vocabulary and vendor-specific extensions, ensuring robust and safe code when working with ActivityPub objects and activities. Say goodbye to runtime errors and hello to confident coding! 💪🏼
Fedify aims to simplify the complex world of federated apps, allowing developers to focus on what matters most—their unique features and user experience. Let's explore what makes Fedify stand out! 🧵
Finally, @ghost has open sourced their #ActivityPub implementation powered by #Fedify! For Fedify users, this means another production-grade example code.
If you'd like to follow updates on #Ghost's ActivityPub implementation, you can do so by following @index!
CVE-2024-39687, a vulnerability that could potentially allow a Server Side Request Forgery (SSRF) attack, was discovered in #Fedify and a security patch has been applied to fix it. The patched versions are 0.9.2, 0.10.1, and 0.11.1, respectively. If you are using an earlier version, please update as soon as possible.
Thanks to @thisismissem for reporting the vulnerability!
한 달 앞서 제가 일자리를 찾는다는 글을 올렸었지요? 그런데 갑작스럽게 제가 오픈 소스로 만들고 있던 @fedify 프로젝트가 글로벌 블로깅 플랫폼인 @ghost 로부터 펀딩을 받게 되었습니다. 그래서 일자리 찾는 것은 그만두고, 한동안 #Fedify 일을 하게 될 것 같습니다.
#Fedify now has a queue for incoming activities and they are automatically retried when they fail. The default retry strategy is good enough (exponential backoff + decorrelated jitter), and it's even fully customizable. Updated also the docs:
In the next version of #Fedify, the #RetryPolicy type is introduced to let you fully customize the retry policy of the task queue for incoming and outgoing activities. Of course, you can also simply adjust the parameters of the built-in exponential backoff + decorrelated jitter policy.
ALT text detailsoutboxRetryPolicy
This API is available since Fedify 0.12.0.
The retry policy for sending activities to recipients' inboxes.
By default, this uses an exponential backoff strategy with a maximum of 10 attempts and a maximum delay of 12 hours.
You can fully customize the retry policy by providing a custom function that satisfies the RetryPolicy type. Or you can adjust the parameters of the createExponentialBackoffRetryPolicy() function, which is a default implementation of the retry policy.
ALT text detailsMaking inbox listeners non-blocking
This API is available since Fedify 0.12.0.
Usually, processes inside an inbox listener should be non-blocking because they may involve long-running tasks. Fortunately, you can easily turn inbox listeners into non-blocking by providing a queue option to createFederation() function. If it is not present, incoming activities are processed immediately and block the response to the sender until the processing is done.
While the queue option is not mandatory, it is highly recommended to use it in production environments to prevent the server from being overwhelmed by incoming activities.
Note: Activities with invalid signatures/proofs are silently ignored and not queued.
In the next version of #Fedify, the Context.hostname, Context.host, and Context.origin properties will be added for better multitenancy/virtual hosting support.
When there is no queue, if the process fails, the inbox can just respond with a 500 server error and the sender will resend it.
But with a queue, by the time the inbox responds, it doesn't know if the process will fail because it hasn't run yet. So the sender won't retry whether it fails or not.
So, should it have its own retry logic when there is a queue?
#Fedify has always been queuing outgoing activities, but not incoming activities. Thanks to @ghost's sponsorship, we are now implementing queues for incoming activities!
I'm not sure if it's new or if I'm just really bad at paying attention, but I just learned about it and I'm so excited about #fedify: https://unstable.fedify.dev/
I think systems that are shaped like fedify are one of the key things needed to really open experimentation and exploration of the possibilities that the fediverse affords.
#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:
• Type-safe objects for Activity Vocabulary (including some vendor-specific extensions) • #WebFinger client and server • HTTP Signatures • Middleware for handling webhooks • #NodeInfo protocol • #Node.js, #Deno, and #Bun support • CLI toolchain for testing and debugging
If you're curious, take a look at the Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
#Fedify has supported optional queuing for outgoing activities, with two built-in message queue backends: InProcessMessageQueue, which is suitable for development, and DenoKvMessageQueue, which is only available in Deno.
Fedify has also had two built-in cache backends, MemoryKvStore, which is suitable for development, and DenoKvStore, which is only available in Deno.
Now, however, by installing the @fedify/redis package, you can use #Redis as both a message queue backend and a cache backend! Unlike DenoKvMessageQueue and DenoKvStore, it's also available for #Node.js and #Bun.
This feature was made possible with the support of @ghost.
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:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
As it turns out, the issue was neither on #Fedify's end nor #Bun's end. It was a #Hollo issue that I discovered during Hollo development, and anyway it's now fixed!
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Fedify é uma biblioteca TypeScript para construir aplicativos de servidor federado desenvolvidos com ActivityPub e outros padrões, chamados fediverse . 1 Seu objetivo é eliminar a complexidade e o código padrão redundante ao construir um aplicativo de servidor federado, para que você possa se concentrar na lógica de negócios e na experiência do usuário.
Version 0.10.0 of #Fedify, an #ActivityPub server framework, has been released! Starting with this release, Fedify, previously distributed under AGPL 3.0, is now distributed under the MIT License to encourage wider adoption. Here are the major changes:
• In addition to RSA-PKCS#1-v1.5, Fedify now supports Ed25519 for signing and verifying the activities. • FEP-521a: Multiple key pairs can now be registered for an actor. • FEP-8b32: Implemented Object Integrity Proofs. • Added Arrive and Question classes.
I had three candidates for the name: Fedilib, Libfedi, and #Fedify, and when I put it to a poll, Fedify was the most popular choice, so it became the current name.
A little backstory about #Fedify's name: I originally wanted to name Fedify FediKit, but I realized that another project was already taking the name, so I had to change it in a hurry before release.
I'm very excited that the #Ghost team has chosen #Fedify to implement #ActivityPub. I've been working closely with the Ghost team, and it's been a lot of fun, and I can't wait to see the ActivityPub implementation at Ghost.
Thanks to @silverpill, #Fedify is finally FEP-8b32 compliant! Though it's not ready for general release yet, it's passing tests in the latest main branch. I'll test it with Mitra and other FEP-8b32-compliant implementations, and if it works well, it'll be included in 0.10.0.
You can try it out in version 0.10.0-dev.205+0cbca257.
Actors now have the #assertionMethods property, and the #Multikey class has been added. For example, if you look at the the actor from the Fedify Example Blog (https://fedify-blog.deno.dev/users/fedify-example), you can see that it has the assertionMethods property in addition to the publicKey property.
You can try it out in version 0.10.0-dev.196+55cc34d1.
As a first step towards adding Object Integrity Proofs (FEP-8b32) to #Fedify, I've made it support #Ed25519 keys. I've also enabled multiple keys to be associated with an actor. For example, if you look at the actor from the Fedify Example Blog (https://fedify-blog.deno.dev/users/fedify-example), you'll see that it has two public keys, one for RSA and one for Ed25519.
You can try it out in version 0.10.0-dev.190+4dffb89a.
Version 0.9.0 of #Fedify, an #ActivityPub server framework, has been released! Here are the main changes:
• Added Tombstone, Hashtag, and Emoji classes. • Added normalizeActorHandle() function to normalize an actor handle. This is needed when the domain of the actor handle is an IDN, or when the domain contains capital letters. • Added an option to the sendActivity() function, excludeBaseUris, to exclude specified servers from sending activities. This can be used when you don't want to send activities to your own server. • Added Context.parseUri(), a method to parse actor, object, inbox, and collection URIs. • The time window for HTTP Signatures verification is now configurable. • The @fedify/fedify/httpsig module has been renamed to . This is in preparation for implementing additional object integrity proofs other than HTTP Signatures. • Improved interoperability with #Misskey.
❤️ 
🍆
輪読会📖第零弾として 
.
![Semantic attributes for ActivityPub
The OpenTelemetry Semantic Conventions currently do not have a specification for ActivityPub. However, Fedify provides a set of semantic attributes for ActivityPub. The following table shows the semantic attributes for ActivityPub:
Attribute Type Description Examples
activitypub.activity.id string The IRI of the activity object. "https://example.com/activity/1"
activitypub.activity.type string[] The qualified IRI(s) of the activity type(s). ["https://www.w3.org/ns/activitystreams#Create"]
activitypub.activity.to string[] The IRI(s) of the recipient collections/actors of the activity. ["https://example.com/1/followers/2"]
activitypub.activity.cc string[] The IRI(s) of the carbon-copied recipient collections/actors of the activity. ["https://www.w3.org/ns/activitystreams#Public"]
activitypub.activity.resend_count int The ordinal number of activity resending attempt (if and only if it's retried). 3
activitypub.actor.id string The IRI of the actor object. "https://example.com/actor/1"
activitypub.actor.type string[] The qualified IRI(s) of the actor type(s). ["https://www.w3.org/ns/activitystreams#Person"]
activitypub.object.id string The IRI of the object or the object enclosed by the activity. "https://example.com/object/1"
activitypub.object.type string[] The qualified IRI(s) of the object type(s). ["https://www.w3.org/ns/activitystreams#Note"]
activitypub.object.in_reply_to string[] The IRI(s) of the orig](https://media.social.fedify.dev/media/01935d47-71d1-79c5-af27-43fe929b61b7/thumbnail)
