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