NodeBB and RFC 9421
2026-07-21 14:15 UTC
Replies (3)
-
@skavish@welley.social 2026-07-21 15:23
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
-
@dmathieu@fosstodon.org 2026-07-21 14:23
@julian because most implementations still default to cavage, so it's the fastest path?
-
@julian@activitypub.space 2026-07-23 18:39
The rfc-9421 branch has been merged into develop and will be released with NodeBB v4.15.0 At present it will handle receipt of RFC-9421-signed activities (in addition to legacy cavage-12). It will only send cavage-12 signed activities for now. That other half (with the double-knocking and caching of supported domains) will come later.