Addressing confusion between `Create` and contained object

SorteKanin @SorteKanin@socialhub.activitypub.rocks

In section 6.2 of ActivityPub, there's this snippet:

A mismatch between addressing of the Create activity and its object is likely to lead to confusion. As such, a server SHOULD copy any recipients of the Create activity to its object upon initial distribution, and likewise with copying recipients from the object to the wrapping Create activity.

So as I understand it, a Create activity has addressing fields both on itself but also on its object, i.e. it has both the fields to, cc, bto, bcc but also the nested fields object.to, object.cc, object.bto and object.bcc. The snippet above suggest that these fields should be equal but this is not guaranteed. I suppose this also applies to other activities than Create.

Is there any guidance on what the behavior should be in the situation when the fields are not equal? I can think of a few possibilities:

  1. The addressing on the activity is used and the addressing on the object is ignored.
  2. The addressing on the object is used and the addressing on the activity is ignored.
  3. The addressing of the activity and object are combined, deduplicated and the resulting fields are used.

Option 3 is flexible but I'm worried it might introduce some weird edge cases, could be confusing and it also sounds more complicated to implement. My initial thought is that option 2 sounds most reasonable.

Any idea what approach some established implementations take, if they deal with this problem at all?

The Primer on addressing does not discuss this.

EDIT: A related question which probably has the same answer as the original question: What should happen if the actor of the Create is different than the attributedTo field of the object?

Read more →
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://socialhub.activitypub.rocks/ap/object/50bbcb81e20b313054460eef21fa2961 on your instance and quote it. (Note that quoting is not supported in Mastodon.)