alan/Activity-Relay
1
0
Fork 0
Code Issues Pull requests Projects Releases 4 Wiki Activity Actions
4 releases 17 tags
  • v3.0.1 9f07a2eab7

    v3.0.1
    All checks were successful
    Debian Package / Debian package validation (push) Successful in 1m33s
    Details
    Container / Container and Caddy validation (push) Successful in 1m58s
    Details
    Test / Go, Redis, and Python validation (push) Successful in 2m23s
    Details
    Stable

    alan released this 2026-09-30 19:16:22 +00:00 | 15 commits to master since this release

    Signed by alan
    SSH key fingerprint: SHA256:yvtkLe2vkdG0Y1CCxra56JR6gjOJFURf52LUTVpWqPw

    Activity-Relay v3.0.1

    • Application version: 3.0.1
    • Debian package version: 3.0.1-1
    • Release type: Patch reliability release
    • Stable outbound-signature default: dual

    Overview

    Activity-Relay 3.0.1 is a focused reliability release that hardens follower-state handling and relay fan-out.

    The release addresses a production failure mode in which an incomplete follower record could be recreated in Redis during a stale mutual-follow status update. That malformed record could contain no valid inbox URL and subsequently cause delivery planning to abort fan-out for otherwise healthy receivers.

    3.0.1 prevents that state from being created, excludes malformed follower records from live relay state, and isolates invalid delivery destinations so one bad receiver cannot block healthy fan-out.

    No configuration migration is required.

    Fixed

    Follower-state validation

    Follower registrations are now validated as complete state transitions before they are persisted.

    A valid follower record must include:

    • a valid follower domain;
    • a valid HTTP(S) actor ID;
    • a valid HTTP(S) inbox URL;
    • the originating Follow activity ID; and
    • a valid mutual-follow state.

    Incomplete follower records are not admitted into the relay's active receiving set.

    Existing one-way followers with:

    mutually_follow = 0

    remain valid and are unaffected.

    Race-safe mutual-follow updates

    Mutual-follow status changes now update follower state atomically.

    A delayed or stale Accept/Reject response can no longer recreate a follower hash after that follower has already been removed.

    If a mutual-follow update encounters an incomplete persisted follower record, the invalid record is removed rather than extended into a partial hash.

    This closes the race that could previously produce records containing only:

    mutually_follow

    with no actor, inbox, or originating activity.

    Fan-out isolation

    Relay fan-out no longer fails globally because one destination is malformed or cannot be prepared for delivery.

    Delivery planning now:

    • validates each target independently;
    • skips invalid or unplannable destinations;
    • continues queuing healthy receivers;
    • reserves queue capacity only for deliveries that were actually planned; and
    • records remaining-delivery counts based on the successfully planned target set.

    A failed or malformed destination therefore cannot prevent delivery to otherwise healthy receiving instances.

    Follow acceptance ordering

    Follower acceptance now commits valid follower state before sending the remote ActivityPub Accept.

    If the follower cannot be stored as valid state, the relay does not acknowledge that registration as successful.

    Manual follow approval follows the same rule and preserves pending state when the transition cannot be completed.

    Build and CI maintenance

    Forgejo container validation was updated for Debian Trixie's split Docker packages.

    CI now installs the Docker client and Buildx components explicitly where required, while the canonical release workflow uses the client-only package with its isolated remote Docker engine.

    These changes affect build and release infrastructure only and do not change the Activity-Relay runtime container.

    Compatibility

    Activity-Relay 3.0.1 does not change:

    • the relay actor ID;
    • the #main-key identity;
    • ActivityPub endpoint URLs;
    • the configuration schema;
    • normal subscriber or publisher record formats;
    • the Redis instance or database layout;
    • queued task compatibility;
    • the Activity-Relay Directory protocol; or
    • the default dual outbound-signature policy introduced in 3.0.0.

    Existing 3.0.0 installations can upgrade directly to 3.0.1.

    As with any upgrade, operators should retain backups of the relay actor key, configuration, and Redis persistence.

    Production validation

    The 3.0.1 candidate was installed over 3.0.0 on the production relay.argentwolf.org deployment.

    Post-upgrade validation confirmed:

    • package version 3.0.1-1;
    • relay --version reports 3.0.1;
    • Redis, API server, and worker services restarted successfully;
    • /actor remained unchanged and valid;
    • /nodeinfo/2.1 reported Activity-Relay 3.0.1;
    • /status.json remained healthy with schema version 5;
    • persisted follower records contained the required actor, inbox, and activity fields;
    • a fresh public WordPress ActivityPub post was accepted for fan-out;
    • healthy Friendica and Mastodon receivers successfully received that activity; and
    • a separate receiver returning HTTP 503 continued through its own retry path without preventing successful delivery to the healthy receivers.

    This directly validates the primary 3.0.1 regression fix: failure of one destination no longer aborts otherwise healthy fan-out.

    Upgrade

    Debian / Ubuntu

    Install the 3.0.1 package over the existing installation:

    sudo dpkg -i activity-relay_3.0.1-1_amd64.deb

    The package preserves existing configuration, actor identity, Redis data, and operator-managed website content.

    Container

    After publication, update the configured image to:

    ghcr.io/thystra/activity-relay:3.0.1

    and recreate the relay containers using the normal deployment procedure.

    Release candidates and canonical validation artifacts should continue to use their complete immutable version tags.

    Release artifacts

    The canonical Forgejo release workflow produces the accepted release artifact set from the exact reviewed release commit, including:

    • Ubuntu amd64 Debian package;
    • CycloneDX SBOM;
    • multi-architecture linux/amd64 + linux/arm64 OCI archive;
    • BUILD-METADATA.txt;
    • RELEASE-NOTES.md; and
    • SHA256SUMS.

    The canonical accepted bytes are the release bytes. Publishing the Forgejo release, registry images, and downstream GitHub mirror must not rebuild or replace the already-validated artifacts.

    Summary

    Activity-Relay 3.0.1 is recommended for all 3.0.0 operators.

    The release specifically improves resilience around follower lifecycle races and malformed receiver state while preserving the existing ActivityPub identity, configuration, storage, and delivery semantics of the 3.0 stable line.

    Downloads