RFC 9421 HTTP signatures in 2026

Thanks again. :slight_smile: I had the conversion reversed in some refactored code for resolving actor IDs, and my tests didn’t catch it because the tests were wrong too. Hopefully fixed now.

If I’m reading that right, it would only apply to normal actors. My server is only advertising capabilities through the server actor, and that one is an ā€œApplicationā€ so it follows the ā€œApplicationā€ section above.

That said, I’m not sure we need capabilities to advertise RFC 9421 signatures, since the RFC includes a way to advertise using headers. And that nicely disentangles signatures from capabilities (and AP in general), so we can spend more time figuring out things like capability registries without slowing down an RFC 9421 rollout.

1 Like

FEP-8b32 content signature (by author): no

How does it work? The proof was present in the activity, should it also be present in the embedded Note?

I’ve only seen one example in the wild (until the one you just sent), and it signed both the ā€œCreateā€ and ā€œNoteā€. The ā€œCreateā€ activity is handled by the server, and the bot only sees the ā€œNoteā€, so it couldn’t see that the activity itself was signed.

The server liked it though:

[20260129-18:16:59.253] DEB (šŸ¦‘3) Verified FEP-8b32 proof! (create)

I’ve just added code to pass activity proof information from the server to the bot’s web hook, so starting now, echobot should say whether the activity or the post (or both) were FEP-8b32 signed.

1 Like

No. OpenSSL and rbnacl both support Ed25519.