[thystra]

Summary

This closes two mixed-profile signed-fetch interoperability gaps found during the Activity-Relay 3.0 interoperability matrix:

• Retry a generic RFC 9421 400 Bad Request once with the legacy HTTP Signature profile for an unknown fetch destination, and cache legacy only after that fallback succeeds.
• Remove URI fragments before RFC 9421 request-target derivation so ActivityPub key IDs such as Mastodon's #main-key do not contaminate @target-uri.

Scope and safety

• Fetch requests only; delivery POST profile selection is unchanged.
• Fixed and already-cached destination plans are unchanged.
• The new legacy fallback is restricted to the characterized generic 400 case.
• Capability evidence remains explicit:
  • successful_legacy_fallback
  • successful_rfc9421
• URI fragments are removed only from the effective outbound HTTP request target.

Validation

• Full serialized tests and race tests
• go vet
• static-site and operations tests
• NodeBB first-contact fallback:
  • RFC 9421 400
  • legacy 200
  • legacy capability cached
• NodeBB cached-profile reuse:
  • four actor fetches, all 200
  • no new RFC 9421 probe
  • capability identity and evidence unchanged
  • delivery to Friendica and Mastodon
• Mastodon fragment-bearing key ID:
  • RFC 9421 with fragment 401
  • same URL normalized before signing 200
  • Mastodon-origin activity accepted and delivered to Friendica

Known downstream limitation

NodeBB currently performs an unauthenticated or otherwise unusable canonical-object fetch when processing a relayed Mastodon object under authorized-fetch mode. Mastodon returns 401, and NodeBB returns 424 Failed Dependency to the relay. This is downstream of Activity-Relay and will be investigated separately in a NodeBB fork.