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.
On a related note, what do you think of SQIsign? I haven't tried it yet, but benchmarks show that its performance might acceptable for fediverse applications.
Is this work so that the HTTPS requirement can be dropped at some point? Having federation possible over plain HTTP and still maintaining integrity of the communication?
Sorry I’m new and I’m still catching up on the drafts and development.
You are technically correct, as it should be https, nowhere does the spec mention MUST.. What a weird situation. I mean it has nothing to do with Actors signing of Object properties, an entirely different question.
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.