Yes, I was worried about this. I was hoping maybe cavage parsers were smart enough to only parse header values that match expected inputs, so sending two Signature headers would work, but knowing what I know, that's wishful thinking <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f605.png?v=22426bb3280" title="" />

Thanks for the detailed reply! Looking forward to testing in the next few days.

you can't send both at once, and it's not because of Signature-Input. that header's fine, it's unique to 9421. the problem is the Signature header itself, both schemes want it, with totally different, incompatible contents. cavage fills it with keyId="...",headers="...",signature="...", and 9421 fills it with sig1=....

same header name, two languages that don't mix.

and if you try to send two Signature headers, HTTP is allowed to just squash repeated headers into one comma-joined value. so the receiver might see both jammed together, which is garbage to a cavage parser.

as for why 9421 goes first: no protocol rule says it has to, it's just a "prefer the new thing" move. lead with 9421, fall back to cavage only when needed, and as the network upgrades more first-knocks succeed until you can eventually drop cavage entirely.

one tip for when you get to sending: cache per-domain which scheme worked, otherwise you're doubling every delivery to un-upgraded peers forever. and only retry-with-the-other-scheme on an actual signature failure, don't re-knock on a 401 that just means you're blocked, or a 410 gone.

for what it's worth, your staging is spot on: receive-both first, dual-send later. that's exactly where Mastodon and we are too, everyone accepts both but still sends one