RE: https://mastodon.social/@bagder/116359048796181736

Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.

On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.

Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?

#ActivityPub #FediDev #RFC9421

Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?

The last time I checked, Lemmy, GoToSocial, Friendica, and the ‘keys to name a few did not handle it. Mastodon didn’t if you included requiring ed25519. But I haven’t checked the code bases or my logs in a month or two, @julian. At that time there wasn’t much progress on peertube/http-signatures or superseriousbusiness/httpsig.

I should probably check again...

@[email protected] by "can't handle" do you mean "still reliant on cavage-12"?

🙋‍♂️

@[email protected] As I understand the migration path, it's like

1. Able to receive RFC 9421 in addition to draft-cavage
2. Able to send RFC 9421 in addition to draft-cavage
3. Send RFC 9421 by default, but be able to fall back to draft-cavage if needed

So by “can't handle” I meant step 1. 🙂 Although the unspoken step 4 is to remove draft-cavage support once everyone else has taken step 1, I'm ultimately also wondering when we'll get there.

@julian @[email protected] Honestly, I think it's going to be a while.

I think the term for step 3 is "double knocking", and it's called out in the HTTP Signature report for the Social CG:

https://swicg.github.io/activitypub-http-signature/

ActivityPub and HTTP Signatures

@evan @[email protected] @[email protected]  I think organizing a contribution event to refactor @peertube/http-signature and golang’s httpsig or gotosocial's fork of httpsig to support both cavage-12 and RFC9421 would go a long way to getting this done sooner as most of the software missing implementation depend on those libraries.

GitHub - Chocobozzz/node-http-signature: Reference implementation of Joyent's HTTP Signature Scheme

Reference implementation of Joyent's HTTP Signature Scheme - Chocobozzz/node-http-signature

GitHub
@mradcliffe The thing about double-knocking is that it requires two implementations (RFC 9421, draft-cavage-12). It also requires a persistent cache, so once you figure out which signature system the remote server supports, you only use that one -- you don't double-knock every time. It might not work as a library.

@evan Thanks for the response. I think how a given software does double-knocking is up to that software. It is not necessarily true that you have to store the result, but it is ideal. I am much too lazy to refactor a persistent cache and I just double-knock every time. :P

But to start, those libraries need to be able to support both signature implementations as those libraries are already in-use by the majority of software that has not implemented RFC 9421 yet.

@[email protected] ah, then no, NodeBB has no support yet. That's true though that there is a step-wise upgrade pattern.

Updating our HTTP Signature lib is part of our grant funded work so it'll get sorted out soon!

cc @[email protected] @[email protected]

@fedify @julian

I still cant! but I wonder, any example of a software in node/javascript that uses the new signature standard?

@gabboman @fedify Fedify does it in TypeScript, as for vanilla JavaScript I have no idea.

@[email protected] are you coding typescript?

NodeBB is plain js. C'mon you don't need type safety. Code like its the 2000s.

@gabboman @fedify @julian I'm adding it to activitypub-bot this week. I'll send a link when it's up.
GitHub - evanp/activitypub-bot: An ActivityPub server-side bot framework

An ActivityPub server-side bot framework. Contribute to evanp/activitypub-bot development by creating an account on GitHub.

GitHub

@julian @fedify @evan

If you send me the part of send signature code that would bee neat


#Thankss
activitypub-bot/lib/httpmessagesignature.js at main · evanp/activitypub-bot

An ActivityPub server-side bot framework. Contribute to evanp/activitypub-bot development by creating an account on GitHub.

GitHub

@gabboman @julian @fedify

Here's the code that does the double-knock. Between the caching, rate limit throttling, and double-knocking it's a real bear to read, though.

https://github.com/evanp/activitypub-bot/blob/main/lib%2Factivitypubclient.js#L90

activitypub-bot/lib/activitypubclient.js at main · evanp/activitypub-bot

An ActivityPub server-side bot framework. Contribute to evanp/activitypub-bot development by creating an account on GitHub.

GitHub

Speaking of RFC 9421, which notable fediverse implementations can’t handle it yet? Anyone keeping track?

@julian @fedify I’m honestly not aware of any that do support it yet…

@hazelnoot @fedify At the very least, Mastodon and Fedify (and by extension Hollo and Ghost) do. Outside of those I'm very unsure! I've seen @silverpill talk about it a bunch, so maybe Mitra supports it as well.

@julian @hazelnoot @fedify Mitra can verify RFC-9421 sigs.

I think all FEP-844e implementations support RFC-9421 in some capacity. The list of known implementations includes:

- Streams / Forte
- ActivityPub for WordPress
- tootik

fep/fep/844e/fep-844e.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org
@[email protected] how do I test against Mitra?

@julian Just send a request with RFC-9421 signature. It should return 401 on failure.

Mitra doesn't use RFC-9421 for signing outgoing requests.

we recently added RFC-9421 to @[email protected] : https://docs.bonfirenetworks.org/federation-interoperability.html#7-http-signatures-secure-fetch

not doing double-knock but rather using different methods to try and discover what the other side supports (in priority order):

  • Inbound signature caching: When a remote server sends us a signed request, we cache which format they used (cavage or RFC 9421)
  • Accept-Signature header: When we receive an Accept-Signature response header from a remote server (on any response — WebFinger, object fetch, inbox POST), we cache RFC 9421 support for that host
  • FEP-844e generator detection: Check remote actors' generator.implements or the instance service actor's implements property for RFC 9421 support URIs (see below)
  • NodeInfo software version: Look up the remote's software name and version against a known-support map (e.g., Mastodon ≥ 4.5.0, Fedify ≥ 1.6.0, Hollo, Mitra)
  • Default: Fall back to draft-cavage
  • Bonfire Federation Interoperability Guide — Bonfire v1.0.3-social-alpha.21

    @mayel @Bonfire why not do double-knocking, especially if you're already caching signature policy by host?
    Hi @julian @fedify,
    #complexity benefits the big players. That's huge harm to diverse #federation. Challenge it, refuse it, stop it.
    @mro @julian @fedify everyone who wants to can park on draft-cavage-12 indefinitely. As long as others double-knock, you'll be fine. Then, when everyone else has converted, switch to RFC 9421 with no detection or fallback. That keep things simple.
    @mro @julian @fedify of course, the Postel principle is pro-network and pro-social; it keeps people and servers connected. Which is what we're here to do.

    Hi @evan
    regarding 'keeps things simple' - have you looked into #RFC9421?
    (Looking at you, Innerlist https://doi.org/10.17487/RFC9421)

    All this #complexity for what benefit?

    @julian @fedify

    P.S.: I don't consider #ActivityPub to be simple in the first place, so hard to keep it simple that way.

    Information on RFC 9421 » RFC Editor

    @mro @julian @fedify

    Yes, I just finished implementing it.

    I agree, HTTP Message Signatures aren't simple.

    Sticking with one spec as long as possible and swapping to the other when you need to is the simplest strategy to manage that transition.

    @mro @julian @fedify for server-to-server authentication, I think there are other mechanisms that could be simpler.

    My friend @blaine says that if you get to PKI, you've gone too far, and you need to look for other options.

    For pump.io, I used two-legged OAuth, which was pretty nice. I kick-started it with a dialback mechanism:

    https://datatracker.ietf.org/doc/html/draft-prodromou-dialback-00

    I also think mutual TLS would be a good option.

    HTTP Authentication: Dialback Access Authentication

    This specification defines the Dialback Access Authentication Scheme. It provides a way for HTTP clients to identify an Internet host or account responsible for an HTTP request, and for HTTP servers to verify that identity by sending a token to a declared dialback endpoint. The specification defines a new HTTP authentication scheme, "Dialback". It also defines a new link relation, "dialback", to specify the endpoint for the dialback verification. Finally, it defines the interface for the dialback endpoint.

    IETF Datatracker

    @mro @evan @julian @fedify

    P.P.S. My latest blog post about #ActivityPub fediverse contains a "Back to (potentially radical) simplicity" call-to-reflection (among other subject matters) .. https://social.coop/@smallcircles/116368803389082089

    Solution is.. difficult, but simple, yet not easy. 😝

    #SX #SocialCoding #ParadoxOfEmergence

    @smallcircles @mro @julian @fedify I'm glad you enjoy thinking through these issues. Good luck with your blog post!

    @evan @mro @julian @fedify

    Blog post is done already 😃 and you and @silverpill the first ones I made reference to :)

    Here's the announcement, and be sure to fill in the #poll if you want.. https://social.coop/@smallcircles/116379158584600016

    @julian @fedify tags.pub now accepts RFC 9421 and does double-knocking (with cached results) for outgoing requests.
    @evan Great work! 👍

    @julian I started a conversation on public-swicg about doing a new version of the HTTP Signature report.

    https://lists.w3.org/Archives/Public/public-swicg/2026Apr/0013.html

    RFC 9421 and the HTTP Signature report from Evan Prodromou on 2026-04-10 ([email protected] from April 2026)

    @evan while perusing the spec, I realized that an implementation doesn't really need double knocking at all.

    Any implementation can just stuff two Signature headers in there, one for the cavage v12 version, and one for RFC9421, and requests should still be valid.

    Can anyone trust cavage HTTP signature verifiers to not break on this: no, probably not... :(

    @julian

    @mariusor @julian probably not.
    @mariusor @julian you only have to double knock once, though. Or, rather, once in a while.

    @evan you mean, if you cache the one that worked? Sadly I don't have that available to me directly in GoActivityPub... Of course one might add support for that, but there isn't a straightforward way to introspect which knock worked for a specific request. Maybe something I need to add to my todo list...

    @julian

    @mariusor @julian yes, cache the one that worked. With a long but not infinite expiry, so if the host upgrades to a new version of the software that supports RFC 9421, eventually you try again.