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...

@julian@fietkau.social by "can't handle" do you mean "still reliant on cavage-12"?

‍️

@julian@activitypub.space 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@fietkau.social @julian@activitypub.space 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/

@fedify@hollo.social @julian@fietkau.social

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.

@fedify@hollo.social @julian@fietkau.social

excelent

@evan @julian@fietkau.social @julian@activitypub.space  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.

@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.

@gabboman@gabboman.xyz are you coding typescript?

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

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

@julian@fietkau.social @fedify@hollo.social I'm honestly not aware of any that do support it yet...

@julian@fietkau.social 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 @evan@cosocial.ca @gabboman@gabboman.xyz

@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.

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.

@gabboman @fedify @julian I'm adding it to activitypub-bot this week. I'll send a link when it's up.

@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

@silverpill@mitra.social 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 @bonfire@bonfire.cafe : 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):

1. Inbound signature caching: When a remote server sends us a signed request, we cache which format they used (cavage or RFC 9421)
2. 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
3. FEP-844e generator detection: Check remote actors' generator.implements or the instance service actor's implements property for RFC 9421 support URIs (see below)
4. 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)
5. Default: Fall back to draft-cavage