Activity-Relay Server 2.5.0 RC 2 is now live at https://relay.argentwolf.org
Please help me out with connecting and testing! If you have any issues, please let me know! You can reach me at @alan, or open an issue on https://github.com/thystra/Activity-Relay
RC2 enhancements include:
- Reliable delivery retries: Each relay fan-out target now receives one initial attempt plus five delayed retries.
- Bounded Fibonacci backoff: Retry delays occur at approximately 8, 13, 21, 34, and 55 seconds.
- Longer activity retention: Shared activity bodies remain in Redis for 15 minutes, covering the full retry window with additional margin.
- Correct terminal accounting:
remain_countis reduced only after successful delivery or final retry exhaustion—not after every failed attempt. - Protection against premature payload deletion: A temporary failure from one receiver can no longer delete the activity needed by its own retry or other pending receivers.
- Structured delivery diagnostics: Logs now include task UUID, activity storage ID, activity/object/actor identifiers, origin domain, receiver domain, attempt number, remaining retries, and body SHA-256.
- Delivery timing details: Each attempt records elapsed processing time and the scheduled time or delay for the next retry.
- Improved HTTP failure evidence: Logs capture HTTP status codes, classified error types, and bounded response text from receivers, including useful errors such as
424 Failed Dependency. - Safer diagnostic logging: Raw activity bodies, HTTP signatures, private keys, and unbounded remote responses are not written to logs.
- At-least-once recovery: A receiver that finishes processing after the relay times out may receive the same activity again during retry, allowing recovery from ambiguous timeout outcomes.
- Receiver-health tracking across retries: Successful and failed attempts update per-receiver delivery statistics and consecutive-failure state.
- Regression coverage: New tests verify retriable failure retention, successful later delivery, terminal cleanup, retry timing, metadata extraction, and bounded response handling.
- Operational observability: RC2 supports private health, readiness, and Prometheus metrics endpoints, now enabled locally in production on
127.0.0.1:9090. - Preserved upgrade state: Deployment validation confirmed that the relay actor identity, private key, configuration, website settings, and all Redis logical data remained intact during the RC1-to-RC2 upgrade.
#activitypub #friendica #mastodon #fediverse #nodebb #relay #relayserver #relayservers #relaytest
Since you’re using AI to code this it may be worth exploring what aspects of Activity-Relay differ from what is detailed in the retrospective FEP ae0c
https://w3id.org/fep/ae0c
Remote Reply
Original Comment URL
Your Profile
Why do I need to enter my profile?
This site is part of the ⁂ open social web, a network of interconnected social platforms (like Mastodon, Pixelfed, Friendica, and others). Unlike centralized social media, your account lives on a platform of your choice, and you can interact with people across different platforms.
By entering your profile, we can send you to your account where you can complete this action.
I tried to reply from my Friendica instance, but it appears the post only went to my timeline, and not back to the post. Maybe I’m doing something wrong, but that wasn’t the intended behavior. – https://friendica.argentwolf.org/display/b285e3be-196a-6e54-fc63-afb575917494
Yes, I am using AI to update this project.
The Activity-Relay 3.0 roadmap regarding FEP-ae0c is here:
https://github.com/thystra/Activity-Relay/blob/master/docs/FEP-AE0C-COMPATIBILITY.md
I’d appreciate any comments on it you may have.
Thanks, I’m taking a look at it now!