Fedify: an ActivityPub server framework<p>We are pleased to announce the release of <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/Fedify" target="_blank">#<span>Fedify</span></a> 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/ActivityPub" target="_blank">#<span>ActivityPub</span></a> implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.</p><p>This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.</p><p><strong>Native retry mechanism support</strong></p><p>This release introduces support for native retry mechanisms in message queue backends. The new <a href="https://fedify.dev/manual/mq#native-retry-mechanisms" rel="nofollow noopener" target="_blank"><code>MessageQueue.nativeRetrial</code></a> property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.</p><p>When <code>nativeRetrial</code> is set to <code>true</code>, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.</p><p>Current implementations with native retry support include:</p><ul>
<li><a href="https://fedify.dev/manual/mq#denokvmessagequeue-deno-only" rel="nofollow noopener" target="_blank"><code>DenoKvMessageQueue</code></a> — utilizes Deno KV's automatic retry with exponential backoff</li><li><a href="https://fedify.dev/manual/mq#workersmessagequeue-cloudflare-workers-only" rel="nofollow noopener" target="_blank"><code>WorkersMessageQueue</code></a> — leverages Cloudflare Queues' automatic retry and dead-letter queue features</li><li><a href="https://fedify.dev/manual/mq#amqpmessagequeue" rel="nofollow noopener" target="_blank"><code>AmqpMessageQueue</code></a> — can now be configured to use AMQP broker's native retry mechanisms</li>
</ul><p>The <a href="https://fedify.dev/manual/mq#inprocessmessagequeue" rel="nofollow noopener" target="_blank"><code>InProcessMessageQueue</code></a> continues to use Fedify's internal retry mechanism, while <a href="https://fedify.dev/manual/mq#parallel-message-processing" rel="nofollow noopener" target="_blank"><code>ParallelMessageQueue</code></a> inherits the retry behavior from its wrapped queue.</p><p><strong>AMQP message queue improvements</strong></p><p>Alongside Fedify 1.7.0, we have also released <a href="https://github.com/fedify-dev/amqp" rel="nofollow noopener" target="_blank">@fedify/amqp</a> 0.3.0. This release adds the <code>nativeRetrial</code> option to <code>AmqpMessageQueueOptions</code>, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.</p><p><strong>Configurable double-knocking</strong></p><p>The new <a href="https://fedify.dev/manual/federation#firstknock" rel="nofollow noopener" target="_blank"><code>FederationOptions.firstKnock</code></a> option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.</p><p>Previously, the first knock for newly encountered servers always used <a href="https://datatracker.ietf.org/doc/html/rfc9421" rel="nofollow noopener" target="_blank">RFC 9421</a> (HTTP Message Signatures), falling back to <a href="https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12" rel="nofollow noopener" target="_blank">draft-cavage-http-signatures-12</a> if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.</p><p><strong>Summary</strong></p><p>This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.</p><p>For detailed technical information about these changes, please refer to the <a href="https://github.com/fedify-dev/fedify/blob/1.7.0/CHANGES.md#version-170" rel="nofollow noopener" target="_blank">changelog</a> in the repository.</p><p><a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/fedidev" target="_blank">#<span>fedidev</span></a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/fediverse" target="_blank">#<span>fediverse</span></a></p>