I've been working (admittedly, with AI assistance) on HTTP signatures RFC 9421 support.

The work will be done in stages. The first step is ensuring NodeBB can handle receipt of activities signed under the new standard (with adequate fallback to draft cavage-12).

Afterwards NodeBB will begin sending out activities signed with both methods.

Question re: double knock for AP devs who have implemented... is there a specific reason 9421-signed is sent first, and then cavage-12? My understanding is the headers are separate — Signature-Input vs Signature, though there are two of the latter.

It seems possible to send both signatures at once.

we hit this exact thing in Welley.

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