I’ve been exploring the Mastodon relay behavior further. The LD signature support is difficult to implement. I’ve been trying to reverse-engineer the Mastodon implementation and rewrite the signing and verification login in Python, but I haven’t been successful so far. I am able to create and hash canonical JSON-LD/RDF documents for the signature data and the primary document (matching what Mastodon produces), but the message signature fails verification when Mastodon receives the message. I have tests that successfully sign and verify the documents locally, so there must be something different in Mastodon that I haven’t seen and/or understood yet.
The JSON LD context used by Mastodon for expansion of the signature document seems to be unresolvable (https://w3id.org/identity/v1). I don’t know how it works in the Mastodon code. For my experiments, I load the context from a local file with a custom context loader.
Apparently, the benefit of the LD Signatures is that the relayed document doesn’t need to be fetched from the authoritative server. When Announce is used, the Announced activity must be fetched, which might be significant if thousands of servers are doing it at about the same time when the relayed message is received (assuming a large relay, of course).
On the other hand, implementing the support for Announce wrapping is relatively easy. The pub-relay server does the wrapping automatically for certain activity types if there’s no LD Signature.
I did verify that relayed Announce objects are displayed (non-boosted) in the Federated timeline in Mastodon if one is careful with the recipient addressing (the public URI must be in the to and not in cc property of the object (or in both?), for example).
Note that I’m using “relayed” in the common sense of the word, not the pub-relay definition of it. In that context, I’m interpreting their terminology as “relay/forward” (send the message as-is, which they call a “rebroadcast”) and “relay/announce” (wrap the message in an Announce before publishing it, which they call “relaying”). I also think it’s confusing if we use the term “inbox forwarding” in a relay context. It doesn’t seem like it’s the same as AP “inbox forwarding” (expanding private collections recursively, prior to delivery).