v2.5.0-rc1

Activity-Relay v2.5.0

Important

These notes are prepared for the v2.5.0-rc1 release candidate. Until the
annotated tag and release assets are published and independently validated,
they are not evidence that the candidate is available or deployed.

Activity-Relay v2.5.0 strengthens federation interoperability, receiver
operability, observability, and asynchronous delivery durability.

Highlights

• Relay-signed remote actor and object fetches for Mastodon authorized-fetch and
  secure-mode compatibility.
• An Application-typed relay actor profile recognized by current Friendica
  discovery without rotating the actor key or changing relay endpoints.
• One shared exact-authority HTTP-signature implementation for authorized fetch
  and outbound delivery.
• Durable receiver delivery-health observations exposed through
  /status.json schema version 4.
• A separately bound private Prometheus, liveness, and Redis-readiness listener.
• Redis-backed operational metrics shared by API and worker processes without
  unbounded or private labels.
• Migration from Machinery v1 to the maintained Redis-only Machinery v2 fork.
• Leased in-flight Redis claims with at-least-once recovery after abrupt worker
  or host failure.

Reliable task delivery

The go-redis broker moves each ready task atomically into an in-flight payload
hash and lease set. The active worker renews the lease and acknowledges the
claim only after successful processing. If the worker terminates first, another
worker returns the expired claim to its original ready queue.

This closes the previously observed silent-loss window after claim. It does not
provide exactly-once execution. A remote server may receive a duplicate when it
accepts the first request and the local worker dies before completion and
acknowledgement are persisted. Operators and integrations should tolerate or
deduplicate repeated externally visible operations.

The migration preserves the existing ready queue, delayed retries, task JSON,
result state, Redis database selection, and tested v1/v2 producer/consumer
compatibility. Redis Cluster mode remains unsupported for reliable claims.

Status and observability

/status.json schema version 4 includes delivery-health timestamps and counters
for current receiving domains while excluding inbox URLs, actor IDs, error text,
and departed receiver history.

When OBSERVABILITY_BIND is configured, the API process starts a separate
listener exposing only /metrics, /-/healthy, and /-/ready. Liveness is
process-only; readiness performs a bounded Redis check. The listener should
remain on loopback or another trusted interface and must not be forwarded by the
public ActivityPub reverse proxy.

Validation completed during development

• Full serialized unit and integration tests, full serialized race tests, and
  go vet.
• Focused repeated HTTP-signature, delivery, receiver-health, metrics, and
  shared-Redis regression tests.
• Machinery fork tests covering Redis compatibility, groups, retries, TLS, ACL,
  database selection, Unix sockets, and v1/v2 queue and result formats.
• Container integration with preserved actor identity and reverse-proxy state.
• Worker interruption testing before claim, during active delivery, during
  outbound HTTP, after remote HTTP success, and across delayed retry.
• Expected at-least-once duplicate behavior after remote success, with no silent
  loss or stranded final claims.
• Bidirectional NodeBB and Mastodon delivery through an isolated test relay.
• Real Mastodon 4.6.4 secure-mode validation using the deployed relay identity:
  the unsigned canonical-object control returned HTTP 401, while the same GET
  signed by Activity-Relay returned HTTP 200 ActivityPub JSON.
• Fresh Friendica 2026.05 discovery and follow/accept registration using the
  corrected Application actor profile, followed by successful Mastodon post,
  media, hashtag, canonical-object, and final presentation validation.

Known interoperability limitation

NodeBB 4.14.2 can return HTTP 424 when a relay-delivered object is hosted by a
server requiring signed GET requests. The relay delivery itself is signed, but
that NodeBB version performs its application-context canonical-object fetch
without an HTTP signature. This downstream limitation is being reported to the
NodeBB project and is not classified as an Activity-Relay release blocker.

Compatibility

No actor-key rotation, endpoint change, configuration rename, task-format
migration, or Redis data conversion is required for the tested upgrade path.
The relay actor changes classification from Service to Application; its
actor ID, inbox, collections, public-key ID, and underlying key remain stable.
The exact release-candidate package and artifact validation remains a release
gate until recorded separately.

Remaining release gates

Before publication:

• complete the native-package install, upgrade, reinstall, rollback, identity,
  persistence, and removal matrix;
• repeat applicable final Redis outage and transport checks through the exact
  release-candidate binary or package;
• run final GitHub Actions, package lint, checksum, and container-manifest
  validation; and
• publish and independently validate the release candidate before production
  deployment.