[holos.social] Posts aren't fetchable after 5 hours #7

New issue

Closed

opened 2026-03-16 13:30:49 +00:00 by phnt · 3 comments

phnt commented

2026-03-16 13:30:49 +00:00

(Migrated from codeberg.org)

I'm not sure whether this is deliberate or a bug, so making an issue here.

As the title says, posts on the holos.social relay aren't fetchable after 5 hours or possibly less when the user isn't online. This creates large issues for federating with other Fediverse instances and results in broken threads where large parts of threads are completely missing due to a Holos user not being online and cache being stale, or broken threads completely detached from the original thread if a remote instance does not preserve context like Mitra and Misskey.

Other ActivityPub implementation also don't have to, and very likely won't try to, refetch a post when they originally received a 404 Not found when requesting it.

An example of a broken thread:

Thread on an instance where Holos pushed posts to, so they didn't need to be fetched, thus the thread is non-broken: https://mitra.social/objects/019ced04-9fd6-65e5-813f-001ff5595bf6
Same thread on an instance where Holos did not push posts to and a reply had to be fetched from Holos, which failed due to a missing cache, where also context is not preserved, so it is completely detached: https://fluffytail.org/notice/B4FizXUOPPIsZ7iBqC

Ideally Holos should preserve posts made by its tunneled users indefinitely, like any other major ActivityPub, so this does not happen. As a compromise posts should be cached for at least two weeks or a month to be comparable with Mastodon's post auto-delete feature, which would mostly prevent broken threads as the likelihood of a thread being active after 14 days or a month is unlikely enough. Or Holos should allow individual users to control the cache time, with a sensible default and only the hard cutoff and default being configurable to the admin.

Posts being this ephemeral unless a user is online does not work in the ActivityPub federation model.

I'm not sure whether this is deliberate or a bug, so making an issue here. As the title says, posts on the holos.social relay aren't fetchable after 5 hours or possibly less when the user isn't online. This creates large issues for federating with other Fediverse instances and results in broken threads where large parts of threads are completely missing due to a Holos user not being online and cache being stale, or broken threads completely detached from the original thread if a remote instance does not preserve `context` like Mitra and Misskey. Other ActivityPub implementation also don't have to, and very likely won't try to, refetch a post when they originally received a 404 Not found when requesting it. An example of a broken thread: - Thread on an instance where Holos pushed posts to, so they didn't need to be fetched, thus the thread is non-broken: https://mitra.social/objects/019ced04-9fd6-65e5-813f-001ff5595bf6 - Same thread on an instance where Holos did not push posts to and a reply had to be fetched from Holos, which failed due to a missing cache, where also `context` is not preserved, so it is completely detached: https://fluffytail.org/notice/B4FizXUOPPIsZ7iBqC Ideally Holos should preserve posts made by its tunneled users indefinitely, like any other major ActivityPub, so this does not happen. As a compromise posts should be cached for at least two weeks or a month to be comparable with Mastodon's post auto-delete feature, which would mostly prevent broken threads as the likelihood of a thread being active after 14 days or a month is unlikely enough. Or Holos should allow individual users to control the cache time, with a sensible default and only the hard cutoff and default being configurable to the admin. Posts being this ephemeral unless a user is online does not work in the ActivityPub federation model.

doesnm commented

2026-03-17 06:19:35 +00:00

(Migrated from codeberg.org)

I have 1 day configured

tom79 commented

2026-03-17 07:55:38 +00:00

(Migrated from codeberg.org)

The server-side cache max TTL is currently set to 117 hours (around 5 days). Each user can configure their own cache TTL in the app up to this limit.

The main issue I identified and fixed was the online/offline transition: when the mobile app disconnected (killed, network loss, etc.), the relay could still believe the user was online for up to 2 minutes (heartbeat timeout window).

During that window, instead of serving posts from cache, it tried to proxy requests through the dead tunnel, resulting in timeouts or 404.

The fix adds two things:

1- Server-side WebSocket ping/pong (every 30s) to detect dead connections quickly (network loss, battery death)

2- Immediate session invalidation when the tunnel WebSocket disconnects, so the relay serves from cache right away instead of trying to reach the mobile app. This should resolve the cases where posts were returning 404 shortly after a user went offline (app in the background for instance).

The server-side cache max TTL is currently set to 117 hours (around 5 days). Each user can configure their own cache TTL in the app up to this limit. The main issue I identified and fixed was the online/offline transition: when the mobile app disconnected (killed, network loss, etc.), the relay could still believe the user was online for up to 2 minutes (heartbeat timeout window). During that window, instead of serving posts from cache, it tried to proxy requests through the dead tunnel, resulting in timeouts or 404. The fix adds two things: 1- Server-side WebSocket ping/pong (every 30s) to detect dead connections quickly (network loss, battery death) 2- Immediate session invalidation when the tunnel WebSocket disconnects, so the relay serves from cache right away instead of trying to reach the mobile app. This should resolve the cases where posts were returning 404 shortly after a user went offline (app in the background for instance).

phnt commented

2026-03-18 20:50:15 +00:00

(Migrated from codeberg.org)

Thanks for the quick response! Feel free to close this issue, and I'll reopen it in the case I encounter this behavior again.