Fedify 2.1.0: Unverified activity hooks, RFC 9421 negotiation, MySQL support, and Astro integration

[dahlia]

Fedify is a TypeScript framework for building ActivityPub servers that participate in the fediverse. It handles the heavy lifting of federation—HTTP Signatures, JSON-LD processing, WebFinger, and more—so you can focus on building your application instead.

We are pleased to announce Fedify 2.1.0. This release is largely focused on real-world federation reliability: giving applications more control over activities that fail signature verification, completing RFC 9421 Accept-Signature negotiation on both sides of the wire, and improving interoperability with GoToSocial. On top of that, two new packages expand Fedify's ecosystem—@fedify/mysql and @fedify/astro—and the fedify lookup CLI tool gains some useful new powers.

Handling unverified activities

Anyone who has run a Fedify application in the wild has seen the same kind of log noise: a Delete activity arrives from a remote server, but the actor's signing key now returns 404 Not Found or 410 Gone. Fedify can't verify the signature, so it returns 401 Unauthorized—and the remote server dutifully keeps retrying. The result is a steady stream of unresolvable errors and pointless traffic, with no good place to intercept them.

Fedify 2.1.0 addresses this with InboxListenerSetters.onUnverifiedActivity(). The hook receives the RequestContext, the parsed activity, and a reason object whose type is one of "noSignature", "invalidSignature", or "keyFetchError". If the callback returns a Response, Fedify uses it; if it returns nothing, Fedify falls back to the default 401. This keeps unverified activities out of your normal inbox listeners while still letting you act on them deliberately.

A common pattern is stopping the redelivery loop for Delete activities from permanently gone actors:

federation
  .setInboxListeners("/users/{identifier}/inbox", "/inbox")
  .onUnverifiedActivity((ctx, activity, reason) => {
    if (
      activity instanceof Delete &&
      reason.type === "keyFetchError" &&
      "status" in reason.result &&
      reason.result.status === 410
    ) {
      // Acknowledge the delete so the remote server stops retrying.
      return new Response(null, { status: 202 });
    }
  });

Alongside this, the new verifyRequestDetailed() function gives lower-level code fine-grained access to signature failure reasons, and OpenTelemetry spans now include HTTP signature failure reasons and key-fetch failure details for inbound activities. The FetchError type also gains an optional response property so callers can inspect the original HTTP error response.

This work was tracked in #472 and implemented in #611.

RFC 9421 Accept-Signature negotiation

Fedify has supported signing with RFC 9421 (HTTP Message Signatures) for some time, but it did not yet implement the negotiation layer described in RFC 9421 §5. Some servers respond to incoming requests with an Accept-Signature header specifying exactly which covered components or metadata parameters they require—and until now, Fedify couldn't adapt to those requirements.

Fedify 2.1.0 fills this gap on both sides:

On the outbound side, doubleKnock() now parses Accept-Signature challenges from 401 responses and retries with a compatible RFC 9421 signature before falling back to the legacy spec-swap behavior. Existing fallback behavior is preserved when no usable challenge exists.

On the inbound side, a new InboxChallengePolicy option in FederationOptions lets your server emit Accept-Signature headers on inbox 401 responses, with optional one-time nonce support for replay protection.

This was contributed by @2chanhaeng in #626, addressing #583 and #584.

GoToSocial interoperability improvements

Two changes in this release are specifically motivated by GoToSocial compatibility.

First, RequestContext.getSignedKeyOwner() previously threw an unhandled error when a remote server with authorized fetch enabled returned 401 Unauthorized during a key owner lookup. This caused Fedify to respond with 500 Internal Server Error when federating with GoToSocial instances. It now correctly returns null instead (#473, #589).

Second, the preloaded https://gotosocial.org/ns JSON-LD context has been updated to match the GoToSocial v0.21+ namespace. New terms include LikeRequest, LikeAuthorization, automaticApproval, manualApproval, interactingObject, and several others, while deprecated terms are retained for backward compatibility (#453, #622).

GoToSocial interaction controls vocabulary

Building on the context update above, @fedify/vocab now includes the GoToSocial interaction controls vocabulary. This adds vocabulary types for expressing who is allowed to like, reply to, or announce a post, and for granting or revoking those approvals.

New additions include:

• InteractionPolicy and InteractionRule value classes
• LikeRequest, ReplyRequest, and AnnounceRequest activity types for requesting interaction approval
• LikeAuthorization, ReplyAuthorization, and AnnounceAuthorization types for proving approved interactions
• Object.interactionPolicy, Object.approvedBy, and corresponding authorization properties/accessors

This vocabulary lays the groundwork for applications implementing quote posts and interaction approval flows with GoToSocial-compatible servers (#453, #622).

@fedify/mysql: MySQL and MariaDB backends

The new @fedify/mysql package provides both KvStore and MessageQueue implementations backed by MySQL or MariaDB (MySQL 8.0+ or MariaDB 10.6+), using the mysql2 driver.

MysqlKvStore stores key–value pairs in a MySQL table with TTL, prefix listing, and compare-and-swap support. MysqlMessageQueue uses SELECT … FOR UPDATE SKIP LOCKED for polling, MySQL advisory locks (GET_LOCK/RELEASE_LOCK) for ordering-key serialization, and supports delayed delivery, enqueueMany(), and concurrent workers.

This rounds out the major relational databases alongside the existing @fedify/postgres and @fedify/sqlite packages (#585, #586, #597, #599).

@fedify/astro: Astro integration

The new @fedify/astro package integrates Fedify with Astro. It provides fedifyIntegration() for Vite SSR configuration and fedifyMiddleware() for request handling, with runtime-specific templates for Deno, Bun, and Node.js. The fedify init command now offers Astro as a web framework option.

This was contributed by @2chanhaeng in #50.

fedify lookup improvements

The fedify lookup command has gained several new capabilities.

--recurse/--recurse-depth follows object relationship chains—reply chains via inReplyTo/replyTarget, quote chains via quoteUrl, and similar relationships. It's mutually exclusive with --traverse, and --suppress-errors applies in recurse mode as best-effort lookup. --reverse reverses the presentation order of emitted results across all output modes.

By default, fedify lookup now disallows private and localhost addresses to prevent accidental exposure during normal use. The -p/--allow-private-address flag re-enables private address access for local development workflows (#606, #607, #608, #609).

xsd:decimal support

@fedify/vocab-runtime now includes Decimal, a branded string type for exact xsd:decimal values, along with isDecimal(), canParseDecimal(), and parseDecimal() for checking and validating XML Schema decimal lexical forms without introducing a decimal arithmetic dependency. The vocabulary code generator in @fedify/vocab-tools has been updated to generate Decimal properties for xsd:decimal ranges. This lays the groundwork for precision-safe marketplace and measurement values as needed by FEP-0837 (#617, #640).

Bug fixes

• Fixed Endpoints.toJsonLd() emitting invalid "type": "as:Endpoints" in JSON-LD output. The as:Endpoints type doesn't exist in the ActivityStreams vocabulary and caused validation failures on implementations like browser.pub. Source.toJsonLd() had the same issue with "type": "as:Source". (Endpoints object serializes with invalid "type": "as:Endpoints" in actor JSON #576)
• fedify init no longer adds "temporal" to deno.json's "unstable" field when the installed Deno version is 2.7.0 or later, and omits the "unstable" field entirely when no unstable feature is required.

Acknowledgments

Thanks to the contributors who made this release possible:

• ChanHaeng Lee (@2chanhaeng) — RFC 9421 Accept-Signature negotiation, @fedify/astro, fedify init improvements
• Julian Fietkau (@jfietkau) — detailed analysis and reproduction of the unverified activity problem

For the complete list of changes, please refer to the CHANGES.md file in the repository.