[Federation]: Relay subscription stuck in pending; no Accept from relay or loops.video after successful actor fetch

[diegosgithub1]

Description

Outbound Follow activities from my instance are never answered with Accept or
Reject by Loops-operated servers. The same code path completes successfully
against Mastodon, so this does not appear to be a signing or reachability
problem on my end.

Two cases:

1. Official relay. Subscribed to https://relay.loopsplatform.com/actor. The
   Follow was delivered and the HTTP request succeeded. The subscription has
   been pending since 2026-08-29 10:47:26 UTC. No Accept, no Reject, and no
   inbound request of any kind from the relay.

2. Direct user follow. Followed dansup@loops.video at 11:42:30 UTC. Two seconds
   later loops.video resolved my instance successfully:

   11:42:32Z  GET /.well-known/webfinger  -> 200
   11:42:32Z  GET /ap/actor               -> 200
   11:42:34Z  GET /.well-known/nodeinfo   -> 200
   11:42:34Z  GET /nodeinfo/2.1           -> 200
   from 64.225.4.82, UA: Loops/1.0.0-beta.14 (Laravel/13.x; +https://loops.video)
   

   So the Follow arrived and discovery completed, four requests, all 200. Then
   nothing. following_state is still 0 and no Accept was ever delivered.

Because a normal user follow is affected as well as the relay, this looks like
inbound Follow handling rather than anything relay-specific.

Expected: the Follow is answered with Accept (or Reject), and the relay
subscription moves from pending to active.

Actual: the remote completes discovery, then the Follow is silently dropped. No
Accept, no Reject, no error surfaced to the sending instance. The admin UI shows
"Awaiting acceptance" indefinitely, which is indistinguishable from the request
never having been processed.

Ruled out on my side:

• Instance keypair matches the published publicKeyPem
• Instance-actor key signature accepted 202 by mastodon.social (this is the key
  RelayService::deliverActivityAsInstance signs relay Follows with)
• User key signature accepted 202 by mastodon.social, and Mastodon's Accept was
  delivered back to my inbox and processed 202
• Signature format: (request-target) host date digest, rsa-sha256, Digest present
• /ap/actor valid, correct inbox / sharedInbox / publicKey
• /ap/actor/inbox and /ap/inbox reachable, correctly 401 unsigned POSTs
• nodeinfo valid, reports "name": "loops", "version": "1.0.0-beta.14"
• Reverse proxy access logging is enabled, so the absence of an Accept is
  measured, not inferred

Full round trip with Mastodon works in both directions. Only Loops-operated
endpoints are silent.

Searched existing issues. #583, #527, #392 and #60 are related but all closed,
and none covers a Follow to the official relay staying pending after a
successful actor fetch.

Deployment: Docker, Caddy reverse proxy, Horizon running, federation enabled.
Instance: loops.dembo.io (single user, no local posts yet).
Reverse proxy access logs available on request.

Running the latest release (v1.0.0-beta.14, 2026-08-03). loops.video reports the
same version via nodeinfo, so both ends of the failing follow are on identical code.

Steps to reproduce

1. Stand up a fresh Loops instance (1.0.0-beta.14) with federation enabled and
   a valid instance actor.
2. Subscribe to the official relay: RelayService::subscribe('https://relay.loopsplatform.com/actor')
3. Observe the Follow is delivered and the subscription row is created with
   status pending.
4. Wait. No Accept or Reject is received; status stays Awaiting Acceptance indefinitely.
5. Separately, follow any loops.video account (e.g. dansup@loops.video) from a
   local user.
6. Check reverse proxy access logs: loops.video fetches webfinger, /ap/actor and
   nodeinfo, all 200.
7. Observe that no Accept is ever delivered and following_state remains 0.

Loops version

1.0.0-beta.14

Acknowledgements

Yes

[netherwraith]

I can independently reproduce this with a different Loops instance and a different target account on loops.video.

Environment (my individual examples):

• Local instance: https://loops.fedi.one
• Local account: @oliver@loops.fedi.one
• Remote target: @pallenberg@loops.video
• loops.video User-Agent observed during discovery: Loops/1.0.0-beta.14 (Laravel/13.x; +https://loops.video)
• loops.fedi.one User-Agent observed during discovery (same version): Loops/1.0.0-beta.14 (Laravel/13.x; +https://loops.fedi.one)

Reproduction:

1. Follow @pallenberg@loops.video from @oliver@loops.fedi.one.
2. Local API call POST /api/v1/account/follow/323338605601374276 returns HTTP 200.
3. The generated Follow activity uses:
   • actor: https://loops.fedi.one/ap/users/323261695143075841
   • object: https://loops.video/ap/users/107283960063398377
   • keyId: https://loops.fedi.one/ap/users/323261695143075841#main-key
4. Sending the exact same signed Follow activity manually through the current Loops HttpSignatureService / SigningService returns from loops.video:

HTTP 202
{"status":"accepted"}

5. Immediately after a real follow attempt, loops.video reaches back to my instance and successfully performs:

GET /.well-known/webfinger?resource=acct%3Aloops.fedi.one%40loops.fedi.one
User-Agent: Loops/1.0.0-beta.14 (Laravel/13.x; +https://loops.video)
HTTP 200

6. After that, there is no POST /ap/inbox from loops.video and therefore no Accept(Follow) or Reject(Follow) is received. The follow remains pending indefinitely.

The same pattern occurred repeatedly. The public ActivityPub inbox itself is reachable and receives signed POSTs from other Fediverse software successfully, so this does not appear to be a reverse proxy / ingress issue.

This looks consistent with the original report: loops.video receives and accepts the outbound Follow at the HTTP level, performs instance discovery, but does not deliver an Accept(Follow) back to the originating instance.

Any ideas on that one?