Plan removal of the Mastodon RFC 9421 5xx fallback

[dahlia]

Why

doubleKnock() currently treats most non-success responses, including 5xx, as a reason to retry with the other HTTP signature spec. The comment in packages/fedify/src/sig/http.ts says this was a temporary workaround for a Mastodon RFC 9421 implementation bug observed on 2025-06-19.

A temporary compatibility fallback is useful during rollout, but keeping it forever can hide real server errors and make delivery behavior harder to reason about.

Current code

The fallback branch lives in doubleKnockInternal() in packages/fedify/src/sig/http.ts. Existing tests in packages/fedify/src/sig/http.test.ts cover successful first attempts, draft-cavage fallback, redirects, transport errors, and Accept-Signature challenges.

Scope

Create a compatibility strategy that lets Fedify remove or narrow the 5xx fallback safely. A good implementation might include:

• a named option or spec determiner signal that decides whether 5xx responses should trigger legacy fallback;
• tests that distinguish 400/401 negotiation failures from ordinary 500 server errors;
• logging or metrics that make the Mastodon workaround visible when it is used;
• documentation in comments or changelog-ready wording that explains when the workaround can be removed.

If the current behavior must remain the default for now, make that decision explicit in code and tests.

Non-goals

Do not remove draft-cavage fallback for 400 or 401. Do not break Accept-Signature challenge handling. Do not hard-code a list of Mastodon hosts.

Suggested checks

Add tests in packages/fedify/src/sig/http.test.ts for a plain 500 response, a Mastodon-style RFC 9421 failure, and a normal 401 negotiation path. The tests should make the planned removal path obvious.