4 releases 17 tags

RSS feed

• v3.0.0-rc2 dd869fbba5

  Compare

  v3.0.0-rc2 Pre-release

  alan released this 2026-09-01 21:32:02 +00:00 | 26 commits to master since this release

  Activity-Relay v3.0.0-rc2

  • Application version: 3.0.0-rc2
  • Debian package version: 3.0.0~rc2-1

  Important

  This is the second Activity-Relay 3.0 release candidate. It carries one
  Directory status-compatibility correction discovered during RC1 integration
  acceptance. The omitted/default outbound signature profile remains legacy
  until the remaining mixed-profile interoperability gate is complete.

  Summary

  RC2 retains the complete Activity-Relay 3.0 RC1 feature set and changes the
  Directory public-status client so it interoperates with the RC-level Directory
  status schema actually deployed during acceptance.

  RC1 lifecycle registration, scheduler persistence, NodeBB 4.15.1
  authorized-fetch interoperability, relay identity, Redis state, and ordinary
  ActivityPub delivery all passed the exercised paths. RC1 exposed one
  non-lifecycle compatibility defect: relay directory status <origin> rejected
  the Directory RC4 public status document because the client accepted only status
  schema version 2 while Directory RC4 serves schema version 3.

  Directory status schema compatibility

  RC2 accepts Directory public status schema versions 2 and 3.

  Schema version 3 adds the public-listing state fields:

  • public_listing_enabled; and
  • public_listing_available.

  The client exposes those fields in its validated status model while continuing
  to use strict JSON decoding. This is an explicit schema addition rather than a
  relaxation of unknown-field or malformed-response handling.

  This correction affects only the Directory public GET /v1/status inspection
  path. The signed version 1 register, heartbeat, unregister, and synchronization
  lifecycle contract is unchanged.

  RC1 acceptance evidence carried forward

  The canonical RC1 container was deployed to the controlled test relay while
  preserving its actor key, Redis state, subscriptions, and delivery-health
  history.

  A fresh NodeBB 4.15.1 authorized-fetch regression test used the stock upstream
  NodeBB release and the canonical Activity-Relay RC1 image with
  OUTBOUND_SIGNATURE_PROFILE: dual. A new public Mastodon post traversed the
  relay, NodeBB completed the canonical-object fetch and displayed the post, the
  relay recorded another successful NodeBB delivery without another failure, and
  the corresponding logs contained no new 401, 403, or 424 failure. This verifies
  the upstream application-actor signing correction for that path.

  The same RC1 relay registered successfully with Activity-Relay Directory RC4.
  The Directory public projection listed it as healthy, and the relay's local
  scheduler state remained registered after API restart. Those results
  demonstrate that the RC1/RC4 signed lifecycle protocol itself was interoperable;
  the schema mismatch was isolated to the remote public-status inspection command.

  Compatibility and defaults

  RC2 does not rotate actor.pem, change the relay actor ID, change the
  #main-key key ID, require a Redis migration, or invalidate existing
  subscription, publisher, receiver-health, capability, or scheduler state.

  Existing configurations that omit OUTBOUND_SIGNATURE_PROFILE continue to use
  legacy. Existing configurations that omit
  PUBLIC_ADDRESS_DISTRIBUTION_POLICY continue to use public_and_unlisted.
  Directory configuration remains empty and its scheduler remains false by
  default.

  The full 3.0 feature and upgrade description remains in
  v3.0.0-rc1.

  RC2 build and tag gates

  Before creating tag v3.0.0-rc2:

  1. run the normal Forgejo source, race, Python, package, Caddy, and container
     validation on the exact RC2 preparation commit;
  2. run Canonical Release Candidate Artifacts with the exact full commit,
     version 3.0.0-rc2, and confirmation BUILD 3.0.0-rc2;
  3. inspect the retained Debian, CycloneDX SBOM, multi-architecture OCI,
     checksum, Lintian, build-metadata, and OCI-index evidence; and
  4. prove that the accepted artifact bytes can be published without rebuilding
     them.

  After tagging and publishing the accepted RC2 bytes:

  1. deploy the exact RC2 candidate to the controlled test relay;
  2. verify relay directory status <origin> succeeds against Directory RC4 and
     reports its schema-3 lifecycle, enrollment, and public-listing state;
  3. continue heartbeat aging and exercise unregister/re-register behavior;
  4. complete the remaining Mastodon, Friendica, WordPress, production-relay, and
     two-relay interoperability matrix; and
  5. select and document the stable 3.0 outbound-signature default only from that
     retained evidence.

  A new runtime/default-policy defect found during these checks requires another
  release candidate rather than stable promotion.

  Repository and release authority

  Forgejo at forgejo.argentwolf.org/alan/activity-relay remains the repository,
  CI, and release authority. GitHub remains a downstream public mirror and
  independent validation surface.

  The RC2 tag must not be created until the canonical Forgejo artifact gate has
  passed and the exact accepted artifact bytes have been identified. Passing the
  candidate build is not itself publication or deployment.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads

  ---

  • BUILD-METADATA.txt
    1 download · 2026-09-01 21:33:13 +00:00 · 776 B
  • RELEASE-NOTES.md
    1 download · 2026-09-01 21:33:13 +00:00 · 5 KiB
  • SHA256SUMS
    1 download · 2026-09-01 21:33:58 +00:00 · 494 B
  • activity-relay_3.0.0-rc2-1_amd64.deb
    0 downloads · 2026-09-01 21:33:13 +00:00 · 3.8 MiB
  • activity-relay_3.0.0-rc2_amd64.cdx.json
    1 download · 2026-09-01 21:33:13 +00:00 · 22 KiB
  • activity-relay_3.0.0-rc2_linux_amd64_arm64.oci.tar
    0 downloads · 2026-09-01 21:33:14 +00:00 · 49 MiB