iiinova — where your digital self keeps evolving

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 08/10/2025

### Announcement: AltStore becomes a financial contributor to Fedify We're thrilled to announce that AltStore has become a financial contributor to Fedify! This generous support comes as part of AltStore's broader commitment to strengthening the open social web […] [Original post on hollo.social]

1118 18

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 31/08/2025

The #Fedify monorepo has grown to 16 packages! We've been working hard to make Fedify more modular and easier to integrate with your favorite tools and platforms. From the core framework to database drivers, from CLI tools to web framework integrations—we've […] [Original post on hollo.social]

A table showing 16 Fedify packages with three columns: Package name, registry availability (JSR and npm links), and Description. The packages include the core @fedify/fedify framework, CLI toolchain, database drivers (PostgreSQL, Redis, SQLite, AMQP/RabbitMQ), web framework integrations (Express, Hono, H3, Elysia, NestJS, Next.js, SvelteKit, Cloudflare Workers), Deno KV integration, and testing utilities. Most packages are available on both JSR and npm registries, with some exceptions like @fedify/denokv (JSR only) and @fedify/elysia, @fedify/nestjs, @fedify/next (npm only).

0311 11

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 11/07/2025

🎉 Huge shoutout to two amazing contributors from Korea's #OSSCA program who've made excellent contributions to #Fedify! 👏 @gaebalgom tackled a tricky terminal compatibility issue in PR #282, fixing the `fedify node` command's favicon display on terminal […] [Original post on hollo.social]

Side-by-side comparison of `fedify node` command output showing terminal favicon display. Left side shows broken display on terminal without truecolor support with corrupted color blocks. Right side shows proper display after the fix with clean, correctly rendered favicon and NodeInfo output including mastodon.social server information and statistics.

015 5

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 04/07/2025

#Fedify has moved to a monorepo structure with unified versioning across all packages (`@fedify/fedify`, `@fedify/cli`, database adapters & framework integrations). All packages now release together, making dependency management much simpler! #ActivityPub #fedidev

Fedify monorepo structure diagram showing all packages (@fedify/fedify, @fedify/cli, database adapters, framework integrations) unified with shared versioning

004 4

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 09/05/2025

We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version. This implementation includes both signature generation […] [Original post on hollo.social]

HTTP Message Signatures

This API is available since Fedify 1.6.0.

RFC 9421, also known as HTTP Message Signatures, is the final revision of the HTTP Signatures specification. Although it is the official standard, it is not widely used in the fediverse yet. As of May 2025, major ActivityPub implementations, such as Mastodon, et al., still rely on the draft cavage version of HTTP Signatures for signing portable activities.

Fedify automatically signs activities with the sender's private key if the actor keys dispatcher is set and the actor has any RSA-PKCS#1-v1.5 key pair. If there are multiple key pairs, Fedify selects the first RSA-PKCS#1-v1.5 key pair among them.

NOTE

Although HTTP Message Signatures support other than RSA-PKCS#1-v1.5, Fedify currently supports only RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures. This limitation will be lifted in the future releases.

Double-knocking HTTP Signatures

This API is available since Fedify 1.6.0.

As you read above, there are two revisions of HTTP Signatures: the draft cavage version and the RFC 9421 version. The draft cavage version is declared as obsolete, but it is still widely used in the fediverse, and many ActivityPub implementations still rely on it. On the other hand, the RFC 9421 version is the official standard, but it is not widely used yet.

To support both versions of HTTP Signatures, Fedify uses the double-knocking mechanism: trying one version, then falling back to another if rejected. If it's the first encounter with the recipient server, Fedify tries the RFC 9421 version first, and if it fails, it falls back to the draft cavage version. If the recipient server accepts the RFC 9421 version, Fedify remembers it and uses the RFC 9421 version for the next time. If the recipient server rejects the RFC 9421 version, Fedify falls back to the draft cavage version and remembers it for the next time.

006 6

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 20/03/2025

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 […] [Original post on hollo.social]

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

105 5

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 10/03/2025

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 […] [Original post on hollo.social]

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

208 8

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 24/02/2025

We're excited to announce two major features coming in #Fedify 1.5.0, focused on giving you more control over domain names in your federated apps: ### Separate WebFinger Host from Server Origin Want different domains for your WebFinger handles and server […] [Original post on hollo.social]

Separating 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

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

004 4

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 18/02/2025

The web interface of the `fedify inbox` command has been slightly updated. This change will be included in the next minor release, Fedify 1.5.0.

012 2

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 10/02/2025

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! :fedify: #fedidev

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

003 3

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 29/01/2025

🎉 Excited to announce that #Fedify is now on Open Collective! Support the project's development starting at: * Backer (from $5/mo) * Supporter (from $25/mo) * Sponsor (from $100/mo) * Corporate Sponsor (from $500/mo) * Custom donations welcome […] [Original post on hollo.social]

1211 11

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 24/01/2025

We're planning to move our GitHub repository to an organization account for better project management. We've requested GitHub support to help us acquire the inactive @fedify username for this purpose. (The attached screenshot is our formal request to GitHub […] [Original post on hollo.social]

Dear GitHub Support,

I am writing to request the takeover of the inactive GitHub username “@fedify”. This username is currently held by an account that shows no activity since its creation—no repositories, contributions, or any other engagement.

I am the maintainer of the Fedify project (https://github.com/dahlia/fedify), which is an open source ActivityPub server framework. We would like to use this username as an organization account to host our project and related repositories.

The reasons for this request are:

1. The current “@fedify” account has been completely inactive with no public contributions or repositories
2. The name directly relates to our project's name and purpose
3. We need an organization account to better manage our growing open source project
4. The username would help us maintain consistent branding across different platforms (@fedify on npm, JSR, etc.)

If possible, we would greatly appreciate if you could help us acquire this username. We believe this would benefit the GitHub community by putting the inactive username to active use for an open source project.

Please let me know if you need any additional information to process this request.

Thank you for your time and consideration.

Best regards,
Hong Minhee (@dahlia)

315 5

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 10/01/2025

:botkit: Introducing #BotKit: A #TypeScript framework for creating truly standalone #ActivityPub bots! Unlike traditional Mastodon bots, BotKit lets you build fully independent #fediverse bots that aren't constrained by platform limits. Create your entire bot […] [Original post on hollo.social]

1126 12

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 24/12/2024

Did you know? Fedify allows you to customize the `links` in WebFinger responses. Just put your `Link` objects in the `urls` property of the `Actor` object returned by the actor dispatcher! unstable.fedify.dev/manual/actor#we…

The related section of the Fedify docs. See also the link.

020 2

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 16/12/2024

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:

001 1

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 25/11/2024

Many more spans were added today! :opentelemetry: unstable.fedify.dev/manual/opentele…

$Instrumented spans Fedify automatically instruments the following operations with OpenTelemetry spans: Span name Span kind Description {method} {template} Server Serves the incoming HTTP request. activitypub.get_actor_handle Client Resolves the actor handle. activitypub.lookup_object Client Looks up the Activity Streams object. http_signatures.sign Internal Signs the HTTP request. http_signatures.verify Internal Verifies the HTTP request signature. ld_signatures.sign Internal Makes the Linked Data signature. ld_signatures.verify Internal Verifies the Linked Data signature. object_integrity_proofs.sign Internal Makes the object integrity proof. object_integrity_proofs.verify Internal Verifies the object integrity proof. webfinger.handle Server Handles the WebFinger request. webfinger.lookup Client Looks up the WebFinger resource. More operations will be instrumented in the future releases.$

102 2

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 24/11/2024

Though we have OpenTelemetry Semantic Conventions 1.28.0, it does not yet define attributes related to the fediverse. So #Fedify is taking the initiative to define semantic attributes related to the ActivityPub protocol and its related protocols. If you have […] [Original post on hollo.social]

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

107 7

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 23/11/2024

Thanks to @robin_maki, #SvelteKit integration support has been added to #Fedify! This feature will be included in Fedify 1.3.0. unstable.fedify.dev/manual/integrat…

SvelteKit

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");

003 3

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 22/11/2024

@hongminhee 내일 행사를 위해 급하게 처음으로 기여하는 분들을 위한 이슈를 만들고 있습니다!

Fedify 저장소의 이슈 목록.

• Display icon/image on fedify lookup [enhancement, good first issue]
• fedify node breaks favicon on terminal emulators without truecolor [bug, good first issue]
• Use Fedify to the latest version in example projects [good first issue]
• Specify engines property to package.json [good first issue]
• More examples [documentation, good first issue, help wanted]

000 0

Fedify: ActivityPub server framework @fedify.hollo.social.ap.brid.gy · 19/11/2024

Starting with #Fedify 1.3.0, you'll be able to use different message queues for incoming and outgoing activities! unstable.fedify.dev/manual/mq#using…

Using 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
});

012 2