Double-knock strategy for HTTP Signature

In the HTTP Signature Report we suggest a double-knock strategy for deploying RFC 9421. Basically, try RFC 9421 first, and if you get an error, downshift to draft-cavage-12 and try again. I just realised, in testing with Pixelfed, that this doesn't work if the remote server doesn't check signatures in the Web routes. Pixelfed returns a 200 response for POST requests signed with RFC 9421, but its backend workers reject the input because Pixelfed doesn't understand RFC 9421. So, it silently swallows activities with RFC 9421 signatures. I think there are a few other strategies to try. One is tit-for-tat: if a host sends you POST requests signed using RFC 9421, you should be able to send them back with RFC 9421. Another is checking for the Accept-Signature header. Finally, you can use an allowlist/denylist based on nodeinfo, the Server header, or the User-Agent header. Has anyone else figured out a good way around this?