Activity-Relay Directory 1.3.0

Activity-Relay Directory 1.3.0

The 1.3 release adds reviewed relay profiles, bounded CSV exchange, lifecycle Protocol v2/v3 support, participating-site telemetry, improved public presentation, and stronger operator workflows while preserving the separation between descriptive metadata and Directory-observed operational state.

Highlights

Relay profiles

ARD now stores source-scoped descriptive relay profile assertions with private append-only history.

Effective values are resolved independently per field using:

override > relay > csv

Profiles may describe registration policy, relay type, languages, countries, regions, topics, operator contact information, participation URLs, availability, and notes.

Descriptive profile data does not determine heartbeat state, reachability, moderation, enrollment, pruning, tier placement, or public eligibility.

CSV import and export

ARD 1.3 adds bounded profile-aware CSV import/export with spreadsheet formula-injection protection and deterministic list escaping.

CSV imports preview field-level changes before confirmation.

An exact relay actor already retained as an active lifecycle or discovery identity may now receive CSV metadata updates even when that relay is currently unreachable. This makes it possible to maintain descriptive information for unavailable or Graveyard relays already legitimately present in the Directory.

Unknown candidates still require the normal actor-validation path or explicit --add-dead-relays retention.

CSV profile updates never fabricate heartbeat or reachability evidence.

For 1.3.0, participation_mode values are case-sensitive and should use exact lowercase:

open
restricted
closed

or be left empty.

Lifecycle Protocol v2 and v3

Protocol v2 adds authenticated relay-profile synchronization while keeping heartbeat and unregister identity-only.

Protocol v3 extends the lifecycle contract with optional bounded participating_instance_count telemetry.

Protocol v1 remains supported for compatibility.

Schema 12 stores Protocol-v3 participating-instance telemetry separately from the earlier receiving-instance telemetry. Public Sites prefers the v3 value and falls back to the older value during rolling upgrades.

Telemetry is descriptive only and cannot affect Directory tiering or eligibility.

Registration is current liveness evidence

Every successful authenticated registration now counts as current relay liveness.

Create, unchanged/profile-sync, and restore registration outcomes update both lifecycle last-seen state and the retained heartbeat/liveness timestamp. Explicit heartbeat does the same.

CSV, discovery, moderation, presentation, and independent reachability changes do not fabricate authenticated liveness.

Production RC4 validation with Activity-Relay confirmed that a normal relay restart generated a fresh authenticated heartbeat and returned the relay to Tier 1 without requiring a configuration change.

Richer public Directory

/v2/relays schema 5 publishes the reviewed effective profile together with bounded telemetry and independent operational evidence.

The human Directory can display and filter registration status as:

• Open
• Restricted
• Closed
• Not reported

The existing four operational tiers remain unchanged:

1. Tier 1 — Heartbeat + Online
2. Tier 2 — Online, no current heartbeat
3. Tier 3 — Offline / Unreachable
4. Tier 4 — Graveyard

Profiles and self-reported telemetry cannot move a relay between tiers.

Operator presentation

ARD now supports optional presentation settings including:

• Directory title;
• HTTPS banner;
• operator contact information; and
• support links or plain-text support values.

The package-managed configuration reference is:

/etc/activity-relay-directory/config.yml.example

The live configuration remains operator-owned:

/etc/activity-relay-directory/config.yml

and is not created or overwritten by the package.

Documentation and release packaging

The project README has been reduced to a concise overview and operator entry point. Detailed installation, administration, configuration, discovery, profile, storage, moderation, retention, and development material now lives in focused documents.

Canonical release artifacts are transported inside the deterministic activity-relay-directory-canonical.tar carrier, preserving expected Unix modes and deterministic release timestamps across Forgejo artifact transport.

Compatibility and upgrade

• Application version: 1.3.0
• Debian package version: 1.3.0-1
• SQLite schema: 12
• Supported lifecycle protocols: 1, 2, and 3
• Previous stable release: 1.2.0

Existing schema-9 through schema-11 databases upgrade in place through the reviewed migrations to schema 12.

The frozen /v1/relays compatibility API and Lifecycle Protocol v1 remain supported.

In-place SQLite downgrade is not supported. Restore the backup associated with the older release before starting an older binary.

Unavailable and Graveyard relays remain retained for recovery by default. Reversible soft pruning remains separate from destructive hard retention, and hard retention remains disabled by default.

Release lineage

• Stable release: v1.3.0
• Accepted release-candidate baseline: v1.3.0-rc4
• Debian package version: 1.3.0-1