Clarification re: Inbox Forwarding
-
I'm confused about a particular aspect of Inbox Forwarding as detailed in the ActivityPub spec:
... the server needs to forward these to recipients that the origin was unable to deliver them to. To do this, the server MUST target and deliver to the values of
to,cc, and/oraudience...... The server MUST only target the values of
to,cc, and/oraudienceon the original object being forwarded, and not pick up any new addressees whilst recursing through the linked objects (in case these addressees were purposefully amended by or via the client).Emphasis mine.
My reading suggests that only the values of
to,cc, andaudienceon the referenced object should be used, and not those values on the activity itself.But doing so would preclude the use of Inbox Forwarding in scenarios where the Activity wrapper contains additional addressees that the underlying object does not have.
e.g. A
NotebyAcontains a single addressee:as:Public. It is then Announced byBandC. Later,Aupdates theNote, and their server sends outUpdate(Note)with the following addressees:as:Public,B,B/followers,C,C/followers, but the object referenced still contains a single addressee:as:Public.In that case, when received by
BandC, should they forward the activity to their followers? -
areplied to julian on last edited by [email protected]the "object being forwarded" in this case is the activity. the language is indeed ambiguous. it should say "the original activity being forwarded". the goal of the language there is to prevent new recipients from being picked up during the recursive processing of other metadata fields -- for example, you may institute a policy that incoming activities to be forwarded must be relevant to some local object, and so you check inReplyTo, etc. but you MUST NOT add inReplyTo.attributedTo if they were initially omitted from delivery addressing. you must only check that they are a local user (or whatever your check is). EDIT: https://github.com/w3c/activitypub/issues/441
-
Thank you! That makes sense to me.
If the activity is the thing being forwarded, then an additional complication could arise in that I cannot simply re-sign the activity, as my instance key does not belong to the originating actor.
At least in NodeBB we do a cross-check to make sure the signer's key belongs to the activity actor...
-
areplied to julian on last edited by [email protected]julian: If the activity is the thing being forwarded, then an additional complication could arise in that I cannot simply re-sign the activity, as my instance key does not belong to the originating actor. this is indeed an issue that arises due to the following: ActivityPub does not specify any authentication/verification mechanism HTTP Signatures, which the current fediverse uses, are not replayable or relayable. If you're concluding that this makes inbox forwarding impossible with HTTP Signatures, then congratulations, you understand why LD Signatures ended up being used for this (and why FEP-8b32 proposes using Data Integrity Proofs at the LD level as well). It's either that, or find a way to replay entire HTTP messages (so that the HTTP Signature can be validated against the original HTTP interaction). Or otherwise rethink the fundamentals of the fediverse's entire security model.
